Re: Emacs User Friendliness Question/Hope

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > I possible solution for this problem is to use `actions'. An action
 > is a generic concept like `fordward-line', or `undo', or `save', or
 > `yank' (`paste', if you prefer.)  `universal-argument',
 > `execute-extended-command' and `C-x' (whatever is officially called
 > on Emacs jargon) would be actions as well.
 > 
 > Currently a mode defines its keymap relating keys to functions.
 >
 > An action-aware mode relates actions to functions.

I hate to tell you this, but since the vast majority of Emacs keys are
bound to *named commands*, we already have one layer of configurable
actions available to the LISP programmer.  Now you're suggesting
another.  This isn't going to help.  (Not to mention that in Emacsen
on X there are already a bunch of other, hidden layers that you can
work with if you want.)

You see, the problem is not that commands aren't flexible enough.
It's that keymaps aren't, and can't be.  Consider the CUA problem.
People talk a lot about the C-x map and how CUA interferes with that.
But that's actually trivial!  C-x is actually bound to a keymap, and
so you can just move the whole thing elsewhere.  It's more annoying,
but almost algorithmic, to move all the mnemonic movement commands
elsewhere.  And almost all editing modes bind very few of the
Ctrl+<key> or Meta+<key> chords, instead using a sparse keymap with
fundamental as the parent.

So why do the long-timers think of this as cleaning the Augean
Stables?  Because there are scores of modes, and they differ widely on
on what the variant keys are, and what they do.

 > This can be extended to menus and buttons on the toolbar, so a button
 > that implements an action is useful for all modes that support that
 > action.

There simply aren't enough keys and toolbar real estate.  (Menus are a
different kettle of fish.)  To give you an idea,
/usr/include/X11/DECkeysym.h defines 1 action,
/usr/include/X11/HPkeysym.h defines 67 actions (perhaps 40 of these
are OSF actions designed to work exactly as you describe), and
/usr/include/X11/keysymdefs.h 289 actions.  As the Motif/OSF folks
found, you are still going to have conflicts across applications, and
adding one more layer of indirection to the hardware->keycode->keysym->
Emacs event->Emacs keysym->command keyboard handler stack just doesn't
help with that.

(Which is what Miles said, of course.  I'm just more long-winded, as
usual.)

Anyway, you or anybody else are welcome to try despite my misgivings.
But I'm convinced; I never liked sweeping slinging horse manure and
rotten hay, and I'm not going to start here.