Re: Key bindings proposal

[Uday S Reddy]

Stephen J. Turnbull writes:

> IME, users just don't do this, or want to do it; I really don't
> understand what you're talking about.  Please be more specific about
> the use cases.

I refer you to Teemu Likonen's post on the July 17, especially his
comment that "there's not enough abstraction on that front [the key
bindings of modes".  In fact, a good part of the discussion in the
"Emacs learning curve" was about the difficulty of changing key
bindings, why the CUA mode can't be made the default etc.

At least one use case that seems to be implemented in Gnu Emacs is to
bind [remap undo] in modes that need it.  So, if a user binds C-z to
undo, he/she gets the appropriate undo in all modes (as long as they
use remap for the key).

I don't know if remap helps for rebinding C-c and C-x.  That seems
like too hard a problem for remap.

The current practice is not necessarily indicative of what the users
want to do.  Many of us expected the key bindings of Emacs to be
customizable, tried it, found it to be too hard and gave up.  Some
people persist because it is really important to them.  It is their
exasperation that keeps this debate alive.

> In any case, your claim is mostly false for the keys where any of the
> redesign vaporware could apply.  In most modes, the mode keymap is
> sparse; most of the shared bindings like self-insert-command, movement
> commands, file opening commands, and buffer-switching commands are
> *inherited* from the global map.  They don't need to be changed.

It might have been Barbara Liskov that said that the inheritance of
implementation is not all that interesting, but the inheritance of
interface is the interesting one.  A have heard the comment from a lot
of other people too.  So, let us take inheritance of implementation
for granted.  There is nothing in particular to be said about it.

remap allows you to inherit the interface (key-binding) and plug in a
new implementation.  

> Most of the remaining bindings are very specialized; it's likely
> that any replacements will also be idiosyncratic.  IOW, remap only
> helps if the user (or a minor mode) is already moving the command
> around in the map.  Sure, occasionally it's useful or perhaps
> necessary.  But how can that be a good idea on a regular basis?

It is most helpful for people who want to move commands around the
map, and they might want to do it on a regular basis.  

But I am proposing that "actions" should also be usable with the M-x
prefix (or some similar prefix, since people will complain if the
semantics of M-x is changed).  So, one should also be able to do `M-x
undo' in a dired buffer and get `dired-undo', and get `vm-undo' in a
VM buffer and so on.  This doesn't seem too hard to implement, but it
requires us to separate the idea of actions/interfaces from keymaps.

[Why allow this?  Some people, me included, prefer to use memorable
function names instead of remembering zillion key bindings.  At the
moment, the long names are made longer by the mode name prefixes like
"dired-", "vm-" etc.  It would be preferable to have simpler, general
action names.  

If one uses speech recognition, key bindings are basically useless and
actually get in the way.  One would unbind all plain keys, and utter
function names instead.  Having to utter "dired blah" for every dired
command is extremely cumbersome.  So, we end up creating an additional
layer of indirection at the speech level, translating "blah" into
"dired blah".  I don't yet see how the "action" idea can help with
that.  But I am hopeful.]

Thirdly, I am proposing that interface inheritance need not only be
from the global-keymap, but it could also be from generic
local-keymaps.  So, there could be, for instance, a
generic-quick-actions keymap, which normally binds `n' to a
`quick-next-line' action, `x' to a `quick-expunge' action etc.  Both
dired and VM could use this keymap, so that the user gets uniformity
of key bindings.  Moreove, the user can rebind keys in this generic
keymap, e.g., move `quick-expunge' to `#' and leave `x' unbound.  That
would take effect in all modes that implement the
generic-quick-actions keymap.  That is a big win.

You asked what "quick" actions are.  They are the things that one
would normally bind to plain keys.  For example, `n' would be bound to
`quick-next-line' whereas `C-n' is bound to `next-line'.  How
`quick-next-line' is performed is for the modes to determine.  Dired
might just do `next-line' in response, but VM Summary mode might
display the next email message.

> Sure, but we already have a concept of `action' (ie, a symbol denoting
> a function): most Emacs commands follow this pattern.  Most "generic"
> bindings are simple enough to just inherit from the global map
> *already*.  Complex generic bindings like "fill-paragraph" and
> "revert-buffer" provide hooks *already* so that modes can augment or
> even entirely replace default implementations.

Actions are *not* symbols denoting functions.  They are symbols that
sit on their own.  They are bits of interfaces.

It is possible, as you note, to make interfaces just be ordinary
functions with dummy implementations.  Smalltalk did that, but I think
they found that the take-up was sporadic.  Most developers just did
implementation-inheritance and didn't bother with interface
inheritance.  On the other hand, when Java added interfaces as a first
class concept, it had better success with the take-up.

> Uh, what's a "quick action"?  (I have no clue what you mean by that,
> except "like vm-summary-next", which leaves a host of possibilities.)
> Do you have a list of them?  Does your list agree with those of the
> maintainers of Gnus, Dired, buff-menu, and a host of other
> maintainers?  Do you all agree that you want these actions on the same
> keys?

I am not too fussed about the "quick" keyword.  It was just the first
thing that came to mind.  Perhaps "modal" to mean that it depends on
the mode.

I am hoping that we all don't have to agree on the keys.  The whole
idea is to empower the user to allow for his/her favorite key
bindings.  But the actions, we would have to agree on, as far as the
common actions go.  That seems nontrivial, but not insurmountable.

> If you can get definition, list, and agreement with *some* modes for
> *some* "actions", you can get started.  If you do actually make any
> progress, let me know; I'll port/implement [remap] in XEmacs (and
> SXEmacs if they don't have it yet).

Ok, we have a deal!

Cheers,
Uday