RE: Ilisp key binding changes - Please Review

Bob Rogers <[email protected]>
Newsgroups gmane.lisp.ilisp.devel
Message-ID <[email protected]>
   From: "Clementson, Bill" <[email protected]>
   Date: Sun, 27 Apr 2003 21:40:21 -0600

   Bob,

   From: Bob Rogers on Sunday, April 27, 2003 3:34 PM
   [snipped some comments]
   > My comments are appended; please do with them as you see fit.  You've
   > done a great job; this will be a big step forward for ilisp.  (Though
   > perhaps not as big a step if you should decide to pass on all of my
   > suggestions.  But that's just my viewpoint.  ;-)

   Thank you for reviewing the key bindings and providing such a 
   thorough set of comments on them.

Hey, thanks for the thorough canvassing of users.  That's the
time-consuming part of this project, I'll bet.

   >    I was somewhat surprised to learn that compile-defun-lisp is "C-c
   > C-c" in ilisp-mode under the current FSF-leaning scheme; how do people
   > manage to interrupt their Lisps in this case?  But since "C-c C-c" is
   > compliant and even easier to type than the classic "C-c c" for this
   > common lisp-mode command, maybe it would be simpler to avoid 
   > binding it in ilisp-mode, where it is not very useful?

   I'm not sure I understand this - in my proposed bindings, there is no 
   ilisp function bound to "C-c C-c", only the comint one. I have replaced 
   the binding to compile-defun-lisp with "C-c ESC c".

Oops; I rewrote that paragraph several times as I studied your proposal.
Seems I should have kept on rewriting.

   The confusion is probably due to the fact that I wasn't talking about
your proposal at that point, but about the old
ilisp-*use-fsf-compliant-keybindings* setting -- the surprise comes in
because I never use these bindings myself.  My suggestion is simply that
it would be better to avoid binding compile-defun-lisp to anything in
ilisp-mode so that we could retain the easier-to-type "C-c C-c" binding
in lisp-mode.  I think this is important because this is probably one of
the most frequently-used commands in lisp-mode, but I don't think I've
ever needed it in ilisp-mode.

   >    comint-mode binds "C-c C-w" to backward-kill-word as part 
   > of its TTY
   > driver emulation, but it hardly seems worth moving compile-region-lisp
   > in order to preserve this.  backward-kill-word is also bound as M-DEL,
   > so you're not losing anything.  At the very least, consider preserving
   > the lisp-mode binding, and omitting this in ilisp-mode.

   However, by moving the compile-region-lisp to "C-c ESC k" binding, that 
   improves the consistency of the bindings - most of the "compile" bindings 
   are now on the "k" key:

   "C-c C-k" compile-file-lisp 
   "C-c C-K" ilisp-compile-buffer 
   "C-c ESC" k compile-region-lisp 
   "C-c ESC" K compile-region-and-go-lisp 

   with the other "compile" bindings on the "c" key (mnemonically, a similar
   binding):

   "C-c ESC c" compile-defun-lisp 
   "C-c ESC C" compile-defun-and-go-lisp 
   "C-c 8 c" compile-changes-lisp 

   I thought that it was worthwhile moving the compile-region-lisp binding 
   even if just to promote consistency. However, since there was also a 
   comint mode binding conflict, this was even a better reason to move it.

The choice of mnemonic binding depends on whether you want to think of
compile-region-lisp as a compile command, or as a region command.  I had
thought of it as a region command, but I'm too lazy to propose a similar
alternative -- and I'm sure your proposal is at least as good as
anything I could come up with that used only a single key after the
"C-c".

   But, just for grins, here's an alternative that binds each command to
a sequence of three keys:

   "C-c C-k f" compile-file-lisp 
   "C-c C-k b" ilisp-compile-buffer 
   "C-c C-k r" compile-region-lisp
   "C-c C-k D" compile-defun-and-go-lisp
   "C-c C-k R" compile-region-and-go-lisp 

In all of these, the extra key allows "C-k" to be mnemonic for "compile"
For consistency, compile-defun-lisp could also be bound to "C-c C-k d",
but I think it should still be available as "C-c C-c" in lisp-mode only.
Similar changes could be made for the "eval-*" commands:

   "C-c C-e d" eval-defun-lisp
   "C-c C-e D" eval-defun-and-go-lisp
   "C-c C-e n" eval-next-sexp-lisp
   "C-c C-e N" eval-next-sexp-and-go-lisp
   "C-c C-e r" eval-region-lisp
   "C-c C-e R" eval-region-and-go-lisp

None of these commands (compile or eval) is really useful in ilisp-mode;
certainly, the "and-go" forms would be redundant.

   Happily, eval-changes-lisp and compile-changes-lisp already fit this
pattern.  Unhappily, they put the "noun key" before the "verb key",
which is the reverse of the "C-c C-e" and "C-c C-k" prefixes.  Not sure
if it would be worth tweaking the "changes" bindings, though "C-c 8" is
pretty poor for mnemonic value . . .

   Of course, if you are not persuaded, and nobody else chimes in to say
that they think this is a much better idea, you are probably better off
implementing what you have so that people (including me) can try it out.
And if anybody (including me) has a better idea, we can always suggest
them as changes to your scheme.

   >    I don't think it's really necessary to find keybindings for every
   > last ilisp command, though I do admire your zeal in carrying 
   > the process
   > forward to its logical conclusion.  For example, fast-lisp, slow-lisp,
   > and status-lisp are easy to type as M-x commands, or to mouse via the
   > command menus, so there's no real urgency to find them new 
   > keybindings.

   However, most of these bindings were available in the "standard" ilisp
   set of key bindings. This is what made the fsf ilisp bindings the "poor
   cousin" - there was more functionality available in the "standard" ilisp
   key bindings than there was in the fsf key bindings. I was attempting to 
   rectify this as part of this exercise. 

Yes, I realize that; what I was proposing is that fast-lisp, slow-lisp,
and status-lisp could be discontinued even in the "traditional" binding
set, for the sake of consistency.  But it seems that you have no other
use for the keys they are currently bound to anyway, so there would be
little point to it.

   . . .
   > Specifically, if slow-lisp is left
   > unbound, then "C-c C-L" can be used for ild-locals, which allows "C-c
   > C-D" to be used for documentation-lisp.

   But, don't you think it's better to have all of the "help" type functions
   bound to the "h" key? Since emacs provides "C-h <letter>" key bindings
   already, this is more consistent with standard emacs practice.

No, but that's because I think of the "C-h <letter>" key bindings as
part of "emacs help," which could certainly include "ilisp help," but I
think of documentation-lisp as providing "Lisp help" instead.  Of
course, that's just my mental furniture . . .

   >    I am a little concerned that many bindings require C-S- and M-S-
   > combinations for the second character.  These seem more likely to make
   > peoples' hands hurt than three-character sequences where each 
   > character
   > requires at most one modifier, with preference given to sequences that
   > tend to use the same modifier combinations.  But maybe I'm alone on
   > this; I know I've mentioned this before, and nobody piped up to agree.

   This bothered me a bit too. I tried to keep the most frequently used 
   commands on lower-shift key bindings. This wasn't always possible because
   comint mode grabs a lot of the available lower case bindings already.

Yes, and many of those bindings are useful, which is why I agree that
leaving them in place is a win.

   On the other hand (and here I'm playing devil's advocate), it would
be reasonable to maintain that Lisp sessions are sufficiently different
from shells, and the fact that ilisp uses comint-mode is now something
of a historical accident, so ilisp is justified in rebinding such things
as "C-c C-w", "C-c C-d", etc., that only make sense for a shell.  I'm
sure that's the original reasoning behind some of the rebindings.  (I'll
bet other rebindings are due to the fact that comint-mode added them
after ilisp.)

   > And I confess this is somewhat academic for me; I now use a Kinesis
   > keyboard with a foot pedal for most of my typing, so emacs is a breeze.
   > Control-Meta-Shift-Whatever.

   Neat - I didn't know that such a device was available! I've looked up 
   their web page now and will have to have a look at their products. Do you 
   find that you have trouble re-adjusting to a "normal" keyboard when 
   you use another person's machine?

Yes, to some degree; "standard" keyboards feel downright claustrophobic
by comparison!  The exceptions are keyboards like the Microsoft Natural
that have a bend in the middle so that you don't have to bash your
wrists together (that's what it feels like) to get the fingers on the
keys.  Strangely, I have not become dependent on the foot pedal for
"Control" and "Alt"; I'm faster with it, and it's easier to type emacs
commands, but it's no hardship going back to the standard "Ctrl" and
"Alt" keys when necessary.  (It is a truly wonderful thing, perhaps the
only good thing to come out of the MS hegemony, that keyboard layouts
are few in number now.  Twenty years ago, Hewlett Packard alone had a
handful of different places to put the control key, sometimes several
possibilities for products made by the same division.  I worked for them
at the time, so I had to deal with it.)

   >    It is probably too late to suggest that the bindings implemented by
   > ilisp-lispm-bindings be adopted with a "C-c" prefix . . .

   The lispm bindings are bound to "C-S-<letter>" and are not compatible
   with fsf keybindings . . .  I don't see the benefit.

OK, just thought I'd try that one on for size.

   Thank you very much for your comments and suggestions. Having someone
   propose some alternatives is good because it makes me re-think some
   of my assumptions.

   --
   Bill Clementson

I know what you mean.  Even if all of your critics are clueless,
responding to each one still forces extra brain cells to kick in.  ;-}

					-- Bob


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.