Re: Emacs learning curve

[Stephen J. Turnbull]

Teemu Likonen writes:
 > * 2010-07-17 15:28 (+0100), Uday S. Reddy wrote:

 > > In a supposedly configurable editor, it is pretty hard to change key
 > > bindings.

It's trivial to change key bindings.  M-x local-set-key RET
<keys-to-define> <command-name> RET and Bob's your uncle.  Or maybe
you want a swap-keys command that would have the UI M-x swap-keys RET
<keys1> <keys2>.  I don't have that function on the top of my head,
but I'm pretty sure it requires at most three lines to express.

What's hard to do is to do this in a way that maintains any
consistency.  That is the difference between Emacs and your average
editor designed for the below-average user: Emacs has a lot more
commands and real users with any amount of experience (often as little
as two or three months!) use enough of those bindings that they feel
pain upon remapping.  Of course many of the Emacs bindings are pretty
arbitrary (eg, P-N-U-D for previous-next-up-down would do just as well
as B-F-P-N for backward-forward-previous-next).  However, you need to
fix all of the related bindings for the different movement units.

 > places like the Emacs wiki. Currently the global minor mode approach
 > doesn't work very well because
 > 
 >   - modes use function substitute-key-definition which refer to the
 >     global-map directly. Key bindings in global minor modes won't be
 >     substituted.
 > 
 >   - modes overwrite global keys by hard-coding keys to commands.
 > 
 > If those both are changed to _command_ remapping, such as
 > 
 >     (define-key MAP [remap next-line] 'modes-custom-next-line)
 > 
 > then the minor mode approach would work and we would be quite far
 > already.
 > 
 > But do we agree that using substitute-key-definition with reference to
 > global-map is bad and should be replaced with command remapping (see
 > above)?

No.  I think you'll find that it's not used as frequently as you
think.  Many commands that *should* do slightly different things in
different modes already *do* do those things in the different modes,
by virtue of hooks in the commands.  If you rebind the command to a
different key, all the mode-dependent behavior goes with it.  I just
don't think this is the root of the problem.  And even if it is, I
think the right way to handle it is to make the command itself
configurable.

The problem is when modes bind completely different functions to the
keys.  If you decide to rearrange the mappings of core commands, users
of such mode will lose.  The mode programmer often has a rationale for
the key bindings chosen, such as mnemonic initials.