The Modernization of Emacs: terminology buffer and keybinding

[Twisted]

On Jun 25, 8:40 am, Martin Gregorie <mar... at see.sig.for.address>
wrote:
> Twisted wrote:
> > The manuals came with the computers, at no additional charge. It was a
> > different time. This isn't going to be true of any separately-
> > purchased book or user-made printout concerning emacs. Also, the
> > manuals provided a basic introduction for the beginning user. A
> > traditional-unix-tool providing anything resembling that would
> > genuinely shock me.
>
> Oh, so manuals are OK and you'll read them if they are dead trees that
> came in the same box as the software, but not if they're HOWTOs, online
> documentation or O'Reilly books?

I think I need to clarify. What I expect is that I can have the
application and the documentation open side by side, a) without
needing to use the application's own navigation methods to navigate to/
from or within the documentation given that that can create a
catch-22, and b) without paying extra.

If a printed manual comes with the thing, without paying extra, then
it clearly qualifies as such documentation.

If I have to print it myself it doesn't, because ink doesn't grow on
trees. Paper does, but they still manage to charge money for that too.

If I have to purchase the manual separately it likewise doesn't.

So the options are: printed manual that ships with the software at no
extra charge, or online documentation I can read "the normal way".
Emacs in control of the console has neither. (Emacs relegated to a
single terminal window on a graphical workstation may not have such a
big problem.)

Regardless, having to reach for the help every two minutes doesn't
enamor me of an application unless there's a darn good reason for it,
such as it's actually rocket science. 3D modeling I expect to be
tricky at times. Text editing should be just-sit-down-crack-knuckles-
and-do-it obviously.

> > Oh, because the implementation (of "reveal codes" and of everything
> > else) was awful, not because of any intrinsic flaw in the idea itself.
>
> If a word processor, which by definition is provides a WYSIWYG user
> interface, can't produce perfectly formatted text by editing a
> representation of the finished result then its a deeply flawed program
> and not fit for purpose.

First, I didn't claim the ideal WP was necessarily perfectly WYSIWYG.
On the other hand, even so it might be that hand-hacking the
underlying representation might in some cases be a faster way to
achieve a particular goal than doing it "the WYSIWYG way". You'd still
have a WYSIWYG preview available either way of course.

> > Would you want to edit a Web page without being able to hand-hack the
> > HTML?
>
> Of course not, but HTML isn't anything to do with WYSIWYG and any system
> (Coldfusion, Front Page, HTML from Word) that pretends it is WYSIWG is
> both useless and perpetrating a fraud.

Your quiet change from discussing word processing to discussing
WYSIWYG is interesting. Is that how you generally go about fighting
your verbal battles, by quietly shifting the specific thing under
debate to whatever would have made your opponent blatantly wrong IF
they had been talking about that thing instead of what they really
were?

> > What happened to the guys that did all this stuff after it became
> > obsolete?
>
> It isn't obsolete despite going back a looong way. The hardware and
> software was originally developed as Future Series (intended S/360
> replacement), was canned in 1970 but resurfaced in the late 80s as
> System/38. A second generation appeared as AS/400, was renamed to (I
> think) Z-series and are now known as iSeries servers. Its good, reliable
> kit and easy to work with if you don't mind programming in RPG.

Programming in role-playing game? And I meant my roguelike-filesystem-
interface suggestion at least partly in jest...

Anyway, obsolete or merely obscure, it obviously failed to hit the big
time since us ordinary joes are still mostly using various forms of
Windoze and wishing for something more reliable and secure that didn't
also have gratuitous user interface weirdnesses.

> I know of no better "one size fits all" interface design than that
> provided by the OS/400 operating system. Its still called that. Its a
> pity the interface style hasn't been emulated by others.

If it's so great, why hasn't it, and why hasn't OS/400 managed to
escape from persistent obscurity?

> It was standard with Win 3.1 and 3.11 and it was bloody useless. Most
> people I know tried it once or twice before giving up and writing .BAT
> files or putting up with RSI. The problem was that it recorded
> keystrokes and mouse clicks. Even minor changes to the screen layout
> made it fail and the macros couldn't be edited or parameterised nor made
> to prompt for filenames, etc.

In other words, the implementation was a dog. That doesn't refute the
basic concept's validity. If it recorded mouse actions by noting the
keyboard equivalents (e.g. recorded a file menu drop down and file
open click as alt, f, o given that the application has the usual
keybindings in the file menu), and provided ways for advanced users to
edit them and such ...

In response to the other postings of the last 24 hours or so I have
just two things to say:

1. Regarding someone saying I had "no clue how to do things in Unix"
when I noted that the inability to copy and paste graphics or other
non-ascii data between applications caused awkwardness, I don't see
any grounds there for an insulting response. If desktop environments
do provide some mechanism suitable for generic clipboard actions (the
basic X clipboard is clearly inadequate) then they do so unobviously,
and probably all differently from one another. Being able to do
serious work with graphics requires being able to move snippets of
graphics around handily without all the mechanics of explicitly saving
them all to various temporary files, and later remembering to delete
the files. More generally, if a common Windows workflow isn't
supported, then even if an alternative workflow is that is as
effective and efficient it would take some getting used to.
Interface-wise, the world has standardized on how Windoze (and the
Mac) does things. Breaking such defacto standards makes software
harder to use by the vast majority of likely new users.

2. Regarding these graphical derivatives (apparently plural) of emacs,
has nobody considered that this means that Xah had already won before
he'd even fired his shot? :P Someone obviously felt the need for a
more usable emacs and delivered one. In that case it's a fait
accompli. Criticisms leveled at original-emacs shouldn't bother users
of the graphical versions regardless. The one complaint might be that
both of us had out of date information and were fighting a war our
side had already won years ago. :)

Unless of course these are all klunky bolted-on GUIs of the sort all
too common when porting unix software to Windows or the Mac or for use
under X, which don't work quite right or are clearly poorly integrated
with the application's internals...about which I currently have no
information. And no, I'm not about to spend hours downloading half a
gig of bloated who-knows-what just to find out, tyvm. :)