The Modernization of Emacs: terminology buffer and keybinding

[Twisted]

On Jun 23, 10:36 am, Martin Gregorie <mar... at see.sig.for.address>
wrote:
> However, there's a case he missed, probably through never using a CAD
> system. All the good ones can be driven either by mouse, or by
> non-chorded key sequences or any combo the user likes. The essence of
> CAD is very accurate pointing but all too many mice move slightly when
> clicked. Fortunately a decent CAD system offers the possibility of
> purely pointing with the mouse and doing everything else with the other
> hand on the keyboard. The result is both fast and extremely accurate.

Actually, what I prefer in (2D and 3D) visual design apps is the
ability to snap to some kind of grid/existing vertices, and to zoom in
close. Then small imprecisions in mouse movement can be rendered
unimportant.

> An interface design point that nobody has yet mentioned here is that
> there are four different types of user that map onto a grid:
>
>                 casual  dedicated
> untrained       1       2
> expert          3       4
>
> I first ran across grid this in "Design of Man-Computer Dialogs" by
> James Martin and its been very useful in systems interface design.
>
> The problem with almost all current GUIs is that they are aimed at types
> 1 and 3 users - this certainly applies to Windows, OS X and Gnome
> desktops with the emphasis on type 1. vi and microEmacs, OTOH, are aimed
> at type 3 and 4 users.

The problem of course being the complete exclusion of type 1 users.
Everyone starts out as type 1, and I don't think type 2 occurs in
practise. You'd have to be some kind of religious nut to be
"dedicated" while still "untrained", rather than only as a result of
experience. Apps that provide no traction for a type 1 user will not
see much adoption except in an environment of immersion, mentoring, or
desperation. I wonder which of the three explains the majority of
emacs users, and of vi users, and whether those prove to be the same
one. :) (Actually, there'll be a single or a small number of class-2
users: the original developers, who presumably became dedicated before
having much experience *using* the tool. Their experiences are
atypical however, and their knowledge of the internals probably means
they're type 4 by the time they actually use it to do more than debug
it. Unsurprisingly, never experiencing it as a type 1 themselves they
tend to be inconsiderate of future type 1 users...this is normal, and
requires effort to avoid, in much the way blinkered views of stuff and
seeing what you want to see can be normal, and efforts like using
double-blind studies may be needed to avoid bias in evaluating, say, a
new drug. That such efforts are needed should not be seen as
disparaging the programmer or the drug-studier, but as merely
reflecting human nature, and as a simple pragmatic requirement if one
is to maximize utility.)

> Its very difficult indeed to design an interface that suits both
> untrained and expert users.

One with a bog-standard UI but also a "console" or command prompt,
scripting language, and customizable bindings?

Funnily enough I can count the software I've seen with that range of
capabilities (so able to satisfy type 1, 3, AND 4 users) on one hand.
Here's the list, in fact:

ROM BASICs and QBasic (on any really ancient microcomputer, and old
pre-Windows PCs, respectively; the former came with printed manuals
and you could just run prepackaged software from disks very easily;
QBasic had mouse and menu support, but an immediate mode command line.
You might not count ROM BASICS as as friendly, due to the lack of
menus and such, but then at that time in history NOTHING had menus and
such! And comprehensive introductory use manuals came with those, and
with pre-Windows PCs (DOS also had a decent and easy to navigate help
system). Most other BASICs and programming environments more generally
lack an integrated environment with an immediate mode prompt. Eclipse
actually sort of does, but the evaluate line can't be used really
arbitrarily and I've found it touchy, and rarely use it.

Hypercard (found commonly on old Macs; had a command prompt you could
access to directly communicate to an interpreter).

Fractint (fractal graphics making software for old pre-Windows PCs;
had a similar prompt, accessed by typing 'g', but also had extensive
help and menus readily controlled by stock keyboard commands such as
the arrow keys, and later a Windows port with menus and mouse
support).

Quake and descendants (yes, the games. Easy to just use the menus and
play the game. Advanced users could hit ~ to drop down a console and
do a few things. Really advanced ones made config files to rebind
weapons and make chat macros to fire off a taunting sentence with a
single keystroke -- no more embarrassment getting fragged while typing
it in longhand in mid-game. Super-advanced ones got at the QuakeC and
made bots, flag-capture mode mods, and other enhancements and
utilities. And sometimes cheats.)

There's probably some more out there, but I've yet to see such
desirable things as:

* The paint program with the usual interface, except you can also do
stuff like hit ~ and type "resample files:c:\foo\*.jpg width:640
height:480 preserveAspectRatio:true doNotEnlarge:false"
* The word processor with the usual interface, except you can also do
stuff like hit ~ and type "format leftIndent 2 where paragraph begins
'Quotation: '"
* The word processor with the usual interface where I can define
logical styles, then change them in only one place and affect every
pre-existing occurrence retroactively.
* The word processor with the usual interface where I can also view an
underlying markup representation and hand-hack that, and which likely
has the capabilities of the first two as a direct consequence of the
implied architecture. Only please, proper functional markup, not
macros like LaTeX or (shudder) winword. I don't want it to be possible
for documents of dubious origin to make it start sneezing, or any of
the general ugliness that follows TeX around like its shadow.
Documents that look as nice when displayed and printed, sure, but just
as nice under the hood if you please.
* Something as powerful as Mathematica, but with a more
straightforward basic-use interface as well as access to a fancy
interpreter.
* The operating system where you can do powerful stuff with a command
line and a script or two, but can also get by without either. (Windows
fails the former. Linux fails the latter.)
* For that matter, the operating system whose GUI takes the concept
behind OLE to its logical conclusion, and lets the user separately
choose and configure their text editing, this-editing, that-editing,
whosit-viewing, and the like components, and those components are used
in building more complex applications. All the alternatives would of
course adhere to a common interface for a particular sort of
component, of course. (An OO language like Java lends itself to this,
what with interfaces and inheritance and dynamic class loading!)
When I run my browser and go to GG to make a post I'd get a text entry
field that was actually my choice in a box, with the usual
capabilities such as spellchecking available, and its own little menu
bar at the top and suchlike. I'd be able to save the contents to disk
without futzing around with the clipboard and launching Notepad, and
later reload, in case the web site was prone to eating the odd
submission. My Jave IDE would display code in the same editor (the
interface should therefore support the using application externally
driving coloring/highlighting, as well as jump-to-line and similar
capabilities). Of course the editor wouldn't itself be Java-aware,
which might not be useful, for example composing a usenet post.
Instead it would provide a variety of abilities to the embedding
application, which may or may not use them. What it would provide
being its particular internal search, spell check, key bindings, etc.

> About the closest I've seen have been
> keyboard driven menu structures which have been designed so the user can
> build their own "command sequences" that traverse menu levels without
> showing the menus, as long as items are selected correctly from each
> level. Many CAD systems approximate to this but I've yet to see a
> graphical desktop, IDE, or editor menu structure that came close.

The bog-standard alt, this, that sequences on Windows "come close";
they do make the menus display, but otherwise they do exactly what you
want, and you can ignore the menus blinking around in your peripheral
vision. When I go to save a file with unsaved changes my first
inclination is ctrl+S; if the app doesn't support that the very next
thing I try is alt, f, s, before resorting to the mouse.