unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>
To: Noah Lavine <noah549@gmail.com>
Cc: u.s.reddy@cs.bham.ac.uk, emacs-devel@gnu.org
Subject: Re: Key bindings proposal [Was: Emacs learning curve]
Date: Thu, 29 Jul 2010 12:26:27 +0100	[thread overview]
Message-ID: <19537.25955.517000.314148@gargle.gargle.HOWL> (raw)
In-Reply-To: <E5CA6FE6-E28F-4DC2-9E9A-6D867E4D9428@gmail.com>

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




  reply	other threads:[~2010-07-29 11:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-29  0:08 Key bindings proposal [Was: Emacs learning curve] Noah Lavine
2010-07-29 11:26 ` Uday S Reddy [this message]
2010-07-29 12:21   ` Key bindings proposal joakim
2010-07-29 14:16     ` Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2010-07-26 22:01 Key bindings proposal [Was: Emacs learning curve] Uday S Reddy
2010-07-27  3:17 ` Stephen J. Turnbull

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19537.25955.517000.314148@gargle.gargle.HOWL \
    --to=u.s.reddy@cs.bham.ac.uk \
    --cc=emacs-devel@gnu.org \
    --cc=noah549@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).