emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Key bindings proposal


From: joakim
Subject: Re: Key bindings proposal
Date: Thu, 29 Jul 2010 14:21:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Uday S Reddy <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]