Re: Key bindings proposal [Was: Emacs learning curve]

Re: Key bindings proposal [Was: Emacs learning curve]

[Noah Lavine]

Hello,

I am writing because I am trying to understand exactly what the keybindings proposal requires. As I understand it, this chain of events will produce an undesired result:

1. Global keymap says "C-y" -> yank
2. You map "C-z" -> yank and send "C-y" to something else
3. Gzip major mode says "C-z" -> compress and "C-y" -> gzip-special-yank

At this point typing "C-z" runs 'compress' and typing "C-y" runs 'gzip-special-yank', whereas the desired result was that "C-z" would be gzip-special-yank and "C-y" would be compress, because you have indicated your preference that "C-z" be used for yank instead of "C-y".

Remap would not accomplish this (at least not by itself), because there is no standard command analogous to 'compress' that gzip-mode should have remapped. However, as long as there is a command anywhere in the keymap that is analogous to yank, then "C-z" should have been mapped to that, and its keybinding moved as necessary (perhaps to "C-y").

Is this an accurate statement of the idea?

Noah

Re: Key bindings proposal [Was: Emacs learning curve]

[Uday S Reddy]

Noah Lavine writes:

> I am writing because I am trying to understand exactly what the
> keybindings proposal requires. As I understand it, this chain of
> events will produce an undesired result:
> 
> 1. Global keymap says "C-y" -> yank
> 2. You map "C-z" -> yank and send "C-y" to something else
> 3. Gzip major mode says "C-z" -> compress and "C-y" -> gzip-special-yank
> 
> At this point typing "C-z" runs 'compress' and typing "C-y" runs
> 'gzip-special-yank', whereas the desired result was that "C-z" would
> be gzip-special-yank and "C-y" would be compress, because you have
> indicated your preference that "C-z" be used for yank instead of
> "C-y".

Nice example!

If the Gzip major mode (is there such a thing?) defines direct key
bindings as in your line 3, then the user is stuck.  He has to alter
the Gzip mode map in addition to altering the global map.

The remapping idea is that the Gzip major mode can remap `yank' to
`gzip-special-yank' (and continue to bind "C-z" to `compress').  If it
does that, there will be a conflict when its keymap is constructed.
There are two competing bindings for "C-z".  My proposal says that
this conflict should be detected when the keymap is constructed and
there should be a rule about how to resolve the conflict.

If the rule says that remapped bindings should take priority, then
"C-z" should get bound to `gzip-special-yank' and there won't be a
key for `compress'.

If the rule says that direct key bindings should take priority, then
one gets the native key bindings of Gzip mode.  ("C-z" -> compress and
"C-y" -> gzip-special-yank).

The current remap implementation in Emacs 23 doesn't detect any
conflict when it constructs the keymap.  However, the semantics of
remap seems to have the effect that the direct key bindings take
priority.  (Working this out is a bit tricky.  The semantics is that,
when a key is pressed, if its binding happens to be `yank' then Gzip
will substitute it by `gzip-special-yank'.  But because of line 2,
there is no key you can press in Gzip mode to get `yank'.  So, you get
the native bindings.)  The remap semantics is a "call-by-name" feature
in an otherwise call-by-value programming language, which might be
confusing in itself but its effect is to give the least possible
priority to remap.

> Remap would not accomplish this (at least not by itself), because
> there is no standard command analogous to 'compress' that gzip-mode
> should have remapped.  However, as long as there is a command
> anywhere in the keymap that is analogous to yank, then "C-z" should
> have been mapped to that, and its keybinding moved as necessary
> (perhaps to "C-y").
> 
> Is this an accurate statement of the idea?

Yes, it is close enough a description of what remap needs to do to
satisfy my requirements.  Except that I am not requiring that Emacs
should invent a key binding for `compress' on its own!

Nobody would fault Emacs if "C-z" = `compress' is a binding specific
to Gzip.  But they would fault it for ignoring the user's preference
to bind "C-z" = yank.

Cheers,
Uday

Re: Key bindings proposal

[joakim]

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:

> Noah Lavine writes:
>
>> I am writing because I am trying to understand exactly what the
>> keybindings proposal requires. As I understand it, this chain of
>> events will produce an undesired result:
>> 
>> 1. Global keymap says "C-y" -> yank
>> 2. You map "C-z" -> yank and send "C-y" to something else
>> 3. Gzip major mode says "C-z" -> compress and "C-y" -> gzip-special-yank
>> 
>> At this point typing "C-z" runs 'compress' and typing "C-y" runs
>> 'gzip-special-yank', whereas the desired result was that "C-z" would
>> be gzip-special-yank and "C-y" would be compress, because you have
>> indicated your preference that "C-z" be used for yank instead of
>> "C-y".
>
> Nice example!
>
> If the Gzip major mode (is there such a thing?) defines direct key
> bindings as in your line 3, then the user is stuck.  He has to alter
> the Gzip mode map in addition to altering the global map.
>
> The remapping idea is that the Gzip major mode can remap `yank' to
> `gzip-special-yank' (and continue to bind "C-z" to `compress').  If it
> does that, there will be a conflict when its keymap is constructed.
> There are two competing bindings for "C-z".  My proposal says that
> this conflict should be detected when the keymap is constructed and
> there should be a rule about how to resolve the conflict.
>
> If the rule says that remapped bindings should take priority, then
> "C-z" should get bound to `gzip-special-yank' and there won't be a
> key for `compress'.
>
> If the rule says that direct key bindings should take priority, then
> one gets the native key bindings of Gzip mode.  ("C-z" -> compress and
> "C-y" -> gzip-special-yank).
>
> The current remap implementation in Emacs 23 doesn't detect any
> conflict when it constructs the keymap.  However, the semantics of
> remap seems to have the effect that the direct key bindings take
> priority.  (Working this out is a bit tricky.  The semantics is that,
> when a key is pressed, if its binding happens to be `yank' then Gzip
> will substitute it by `gzip-special-yank'.  But because of line 2,
> there is no key you can press in Gzip mode to get `yank'.  So, you get
> the native bindings.)  The remap semantics is a "call-by-name" feature
> in an otherwise call-by-value programming language, which might be
> confusing in itself but its effect is to give the least possible
> priority to remap.
>
>> Remap would not accomplish this (at least not by itself), because
>> there is no standard command analogous to 'compress' that gzip-mode
>> should have remapped.  However, as long as there is a command
>> anywhere in the keymap that is analogous to yank, then "C-z" should
>> have been mapped to that, and its keybinding moved as necessary
>> (perhaps to "C-y").
>> 
>> Is this an accurate statement of the idea?
>
> Yes, it is close enough a description of what remap needs to do to
> satisfy my requirements.  Except that I am not requiring that Emacs
> should invent a key binding for `compress' on its own!
>
> Nobody would fault Emacs if "C-z" = `compress' is a binding specific
> to Gzip.  But they would fault it for ignoring the user's preference
> to bind "C-z" = yank.

This particular sub-problem annoys me a bit as well. I offer a concrete
example:

- I like to bind <C-return> to other-window, because its more convenient
  than c-x o, and I've read that some Emacs über-hackers like this
  binding. <C-return> is normaly free. When I sit down at a new Emacs I
  just use global-set-key, because I'm too lazy to make a local
  .emacs. In the future I'd like to use the new package system to
  retrieve my favorite customizations rather than fiddling with a local
  .emacs

- In the pristine Emacs, I wind up in an xml-mode that for some reason
  binds <C-return> to completion, which is very annoying. (I dont have
  access to this Emacs atm)

Normally I find the default bindings ok, so I dont rebind too much. I
bind my own stuff to the keys that are defined to be free, so I dont get
much collisions.

I havent delved too deeply in the Emacs event binding machinery, so what
I say here might be totaly naive and uninformed, but heres some of my
observations of how I'd like stuff to work:

- If I bind a key globaly, I'd like to tell Emacs that thats what I want
  always. (my <C-return>  example above)

- I want global dispatch functions for certain common operations. These
  are "completion" and "symbol lookup".

As it is now, there are all manners of different completion systems. My
hope is that more of these systems will use Semantic, and the different
completion systems will use Semantic as a base, and I could bind
completion to a single key and have that always work as well as possible.

With symbol-lookup, there appears to be even less coherence. There is
C-h S that binds to info-lookup-symbol, but thats that. All other
symbol-lookup functions, gtk-lookup-symbol for instance, do things
differently. Again, I think Semantic should figure out the details about
the symbol at point, and then dispatch to whatever sub-symbol-help
system that claims to know something about the symbol. And while it
would be great if more API:s could provide info documentation, that is
not reasonable in a wider context. (For instance, I'm working on a "dna
debug" mode that looks up the SNP symbol at point on snpedia. There are
currently 13k symbols, that I'd like to look up immediately on
snpedia. Converting this rapidly changing information to info format
wouldnt be friendly to anyone.)
  

>
> Cheers,
> Uday
>
-- 
Joakim Verona

Re: Key bindings proposal

[Stefan Monnier]

> - If I bind a key globaly, I'd like to tell Emacs that thats what I want
>   always. (my <C-return>  example above)

You might want to use the emulation-mode-map-alists for that, then,
since global-map is the keymap with the lowest priority.

> - I want global dispatch functions for certain common operations. These
>   are "completion" and "symbol lookup".

For completion, we now have such a function/command, it's called
`completion-at-point' and dispatches on `completion-at-point-functions'.
For symbol-lookup we don't have it yet.  Patches welcome.

Note that we don't have a key binding for either (tho completion-at-point
can be available on TAB by setting tab-always-indent to `complete').


        Stefan

Key bindings proposal [Was: Emacs learning curve]

[Uday S Reddy]

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.  They are kind of heavy duty hammers
that are looking for nails to hit on and of course everything looks
like a nail.

I thought better of it because this thread had already been too long
and wandering.  But a post in the gnu.emacs.help newsgroup today
prompted me to come back to it.  The poster says:

> For example now I just installed ruby-tests.el from emacswiki, which (I
> saw too late) unfortunately has some "global-set-keys" with combinations
> that normally I use for other things.

> Is there any way to revert back to the last global state (it might be
> useful also in other cases of cours)?

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.  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.
The user wouldn't have to mess with mode-hooks or whatever.  

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

Instead, Emacs acts rather like a grumpy child that believes that it
has the best key bindings already cased.  And, local-set-key and
global-set-key are like "if you really must change a key binding,
well, go right ahead.  Go and change all the key bindings if you want.
I don't care."  A totally unhelpful attitude.

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.  It
    should be possible to change the entire set of key bindings in a
    running Emacs with the click of a button.  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.

    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.

Cheers,
Uday

PS: By the way, I sort of speak from experience here.  I had RSI some
15 years ago and explored a whole bunch of options for how to change
things, including going to Vim or Viper, using speech recognition,
hand-writing etc.

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.