Key bindings proposal [Was: Emacs learning curve]

[Stephen J. Turnbull]

Uday S Reddy writes:

 > Yidong asked for a specific proposal if there is one.  So, here is
 > mine:

This is not a specific proposal.  This is waving hands over an
enormous cowpie.  I'm sorry, but you've managed to get pretty much all
of the standard misunderstandings exhibited by the CUA-by-default
advocates into a single post.  I hope you don't feel too battered when
I'm done debunking them.

 > Stephen J. Turnbull writes:
 > 
 > > 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.
 > 
 > Hi Stephen, I was going to reply to this originally saying that
 > `local-set-key' and `global-set-key' are destructive change operations
 > which shouldn't be taken lightly.

In context of this thread, that's what was wanted: a permanent change
(to CUA by default).  I think you're missing the point, or perhaps
simply don't understand how keymapping works in Emacs if you think
that's an important criticism of my statement.

Bringing up broken ruby-related software, well, too bad for the rubes.
It's always possible to abuse flexibility, and you know that crap
would never get into Emacs as is.

If a safe change to the global keymap is wanted, do

(defvar saved-global-keymaps nil)
(push global-keymap saved-global-keymaps)
(setq global-keymap (copy-keymap global-keymap))

(In practice it would be simpler than that, but this shows the most
general pattern.)  Yes, it would be tedious to do this for a lot of
keymaps, but it could be done, and there are only about a half-dozen
important ones that more or less *must* be protected.  The reason
Emacs doesn't do this already is that it's not useful without a
concrete proposal ("concrete" is defined below).

 > If Emacs did take key binding customization seriously, it would have
 > provided a whole bunch of *declarative* methods for specifying key
 > bindings, along with rules for how they override each other or not
 > override, as the need may be.

I'm flabbergasted.  What do you think a keymap is, if it isn't
declarative?  What do you think the cascade of keymaps, inheritance,
and the like is, if not a set of rules for precedence?

 > If and when a set of key bindings needs to be installed (e.g., when
 > a mode is entered), it would go and compile the key bindings from
 > all the sources, detect conflicts if necessary, and install the
 > right set.  The user would be protected.

If you don't think Emacs has this feature already, what's your
explanation for the coexistence of CC-mode (in multiple variants!),
Gnus, VM, and AUCTeX in the same Emacs process?

 > The user wouldn't have to mess with mode-hooks or whatever.

Configurable commands are a separate problem from changing bindings of
keys to commands, although obviously they are closely related in the
user's experience.  That is out of context (it's about [remap command]
specifically, not the problem of keymap conflicts), anyway.

 > This is not an out-of-the-world idea.  Almost all customization
 > systems out there work this way.

What you imply here is nonsense.  First, an Emacs keymap has semantics
nearly identical to what you claim you want.  Second, almost all
customization systems deal with very sparse keymaps, which makes
collisions relatively unlikely.  (BTW, IME none of them work well in
practice; I have yet to find a GNOME-compatible WM whose stock
bindings don't conflict with some application (usually Emacs :-).)
Not so for Emacs, which gave up on "keymap wall-paper" when the
wallpaper exceeded the area available on the Great Wall of China,
ca. 1986.

Look up "whack-a-mole effect" on wikipedia.  That, not poor design, is
why default Emacs keymappings are hard to change.  If you don't need
the default bindings at all, you can go wild.  Cf. Gnus or viper.

 > Yidong asked for a specific proposal if there is one.  So, here is
 > mine:
 >
 >     Redesign Emacs so that key bindings can be designed by end users
 >     or third party customizers and exchanged with each other.

Don't you think you really ought to learn how Emacs works before
suggesting that a redesign is needed?

I'm really tired of hearing that Emacs is poorly designed in this
respect.  Sure, I disagree with the [remap command] feature, but
that's minor, micro, nano, pico.  Maybe even femto.

 >     It should be possible to change the entire set of key bindings
 >     in a running Emacs with the click of a button.

It is possible.  What do you think "M-x gnus" (or "M-x viper") does?

The problem is "to what?"  The "concrete" part of "concrete proposal"
is a request to exhibit a reasonably complete alternative keymap.
Without that, the whole exercise is pointless.

 >     If there are conflicts between different sets of key bindings
 >     that users import, there should be clear rules for what to do
 >     in such a case, an analysis of what goes wrong and gentle
 >     feedback given to the users.

This is not possible IMSEO.  The problem is the whack-a-mole effect.
You want to put something on C-x C-s, Emacs comes back with

    Please, be careful.  The old binding to `save-buffer' is very
    important.  If you really want to bind C-x C-s, you should put
    `save-buffer' on another key sequence.  I can do that for you.
    Choose a key sequence, or type C-g for none [C-x C-# C++ u r k]: _

After getting that warning for about seven commands in succession (the
suggested keysequence "C-x C-# C++ u r k" isn't very appetizing :-),
the user is not going to feel gently about the process of rebinding
commands.  And it's about three orders of magnitude worse if you're
trying to design a new keymap "for the rest of us", who are hardly a
group with homogeneous requirements.

Cf. also the wild popularity (not) of
http://www.jwz.org/software/xkeycaps.  Great program with an excellent
interface, but do Gentle Newbies use it?  Uh-uh.

The problem is that *nothing* goes *wrong*!  Keymaps, for all the
discussion spent on the colors of their bikesheds, are *arbitrary* (if
you start from scratch).  Even arbitrary alterations to the
traditional full keymap can be correct depending on the user's intent.
The whole problem here is specifying what users want, not implementing
a set of requirements once you've got them.

Specifying the requirements here involves, at a guess, thousands of
interrelated decisions.  If you want them made, maybe you should get
started instead of asking Emacs developers, who would rather do
something else, to do it.

 >     If you think that Emacs is alredy capable of doing all of this,
 >     then demonstrate it by implementing a radically different set of
 >     key bindings.  Show the users how it can be done.

Why should I reinvent the wheel?  It's been done, multiple times.
CUA, viper, Gnus, and hey, *you* are the maintainer of VM, no?  *You*
show them radically different keybindings, they're right there at your
fingertips.

If you want a permutation of the default bindings for fundamental and
the other "most common" modes, no, I don't think that's my job.  The
people who want that should produce it.  viper is a fairly good
example already, I should think.