emacs-devel
[Top][All Lists]
Advanced

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

Re: Key bindings proposal


From: Stephen J. Turnbull
Subject: Re: Key bindings proposal
Date: Wed, 28 Jul 2010 14:57:29 +0900

Uday S Reddy writes:
 > Stephen J. Turnbull writes:
 > 
 > > I don't see how this use of remap helps Uday or the
 > > CUA-should-be-default crowd, since much of the time no such
 > > relationship applies.  
 > 
 > This is not a solution to the broad problem I posed.  I shouldn't
 > pretend that it is.  But it helps partially in the following sense.
 > 
 > The irritation for the user is that it is not enough to just rebind
 > keys at the global level, but he/she must go and rebind them for every
 > mode.

IME, users just don't do this, or want to do it; I really don't
understand what you're talking about.  Please be more specific about
the use cases.

In any case, your claim is mostly false for the keys where any of the
redesign vaporware could apply.  In most modes, the mode keymap is
sparse; most of the shared bindings like self-insert-command, movement
commands, file opening commands, and buffer-switching commands are
*inherited* from the global map.  They don't need to be changed.  Most
of the remaining bindings are very specialized; it's likely that any
replacements will also be idiosyncratic.  IOW, remap only helps if the
user (or a minor mode) is already moving the command around in the
map.  Sure, occasionally it's useful or perhaps necessary.  But how
can that be a good idea on a regular basis?

 > The remap idea helps in that the modes can piggy back on the global
 > bindings at least to some extent.

They already do in a big way, of course -- at least, I'd like to say
"of course", but evidently you don't know about it. :-(

 > But the applicability is limited.  I was just looking at dired-mode,
 > which seems to have some 100 odd key-bindings, but only 2 remap's.
 > Not much of a win.  To catch the majority of the other generic
 > bindings, something like the "action" idea seems necessary.

Sure, but we already have a concept of `action' (ie, a symbol denoting
a function): most Emacs commands follow this pattern.  Most "generic"
bindings are simple enough to just inherit from the global map
*already*.  Complex generic bindings like "fill-paragraph" and
"revert-buffer" provide hooks *already* so that modes can augment or
even entirely replace default implementations.

 > You are right.  But, if there were action-based bindings, I could do:
 > 
 > (define-key vm-summary-map [action quick-next-line] #'vm-summary-next)

This extra indirection is *useless*; its entire functionality is
already subsumed by `defun' and `remap'.  You *must* defun
`vm-summary-next', doing so creates no extra work.  For the generic
version,

(defun next-line-and-operate ()
  "Move to the next line in a buffer and operate on the line.

Useful in modes that use buffer lines as a menu-like device."
  (interactive)
  ;; do something intuitive and possibly useful
  (next-line))

and finally in `vm-mode' or whatever

(define-key ACTION-MAP [remap next-line-and-operate] #'vm-summary-next)

(where ACTION-MAP might be the global map or some sort of sharable
map, maybe a minor mode map would do).

However, it's not at all obvious to me that this is a better idea than

(defvar operate-on-line-function nil)
(make-variable-buffer-local 'operate-on-line-function)

(defun next-line-and-operate ()
  (interactive)
  (when operate-on-line-function
    (funcall operate-on-line-function)))

and in vm-summary.el

(unless operate-on-line-function
  (setq operate-on-line-function #'vm-summary-recenter))

(or whatever it is that `vm-summary-next' does after `next-line').
The point is that the `operate-on-line' function can be shared among
next-, previous-, and goto-line-and-operate.  Possibly others
(`incremental-search-and-operate-on-line', anyone?)

 > or `M-n' or whatever else the user might wish).  Gnus, Dired,
 > buff-menu and a host of other modes that need "quick" actions could
 > all share their key bindings without having to do anything.

Uh, what's a "quick action"?  (I have no clue what you mean by that,
except "like vm-summary-next", which leaves a host of possibilities.)
Do you have a list of them?  Does your list agree with those of the
maintainers of Gnus, Dired, buff-menu, and a host of other
maintainers?  Do you all agree that you want these actions on the same
keys?

If you can get definition, list, and agreement with *some* modes for
*some* "actions", you can get started.  If you do actually make any
progress, let me know; I'll port/implement [remap] in XEmacs (and
SXEmacs if they don't have it yet).




reply via email to

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