From: Bob Rogers on Tuesday, April 29, 2003 10:14 AM
> The choice of mnemonic binding depends on whether you want to think of
> compile-region-lisp as a compile command, or as a region=20
> command. I had
> thought of it as a region command, but I'm too lazy to=20
> 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
> But, just for grins, here's an alternative that binds each=20
> command to
> a sequence of three keys:
> "C-c C-k f" compile-file-lisp=20
> "C-c C-k b" ilisp-compile-buffer=20
> "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=20
> In all of these, the extra key allows "C-k" to be mnemonic=20
> for "compile"
> For consistency, compile-defun-lisp could also be bound to=20
> "C-c C-k d",
> but I think it should still be available as "C-c C-c" in=20
> 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=20
> certainly, the "and-go" forms would be redundant.
> Happily, eval-changes-lisp and compile-changes-lisp=20
> 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.=20
> Not sure
> if it would be worth tweaking the "changes" bindings, though=20
> "C-c 8" is
> pretty poor for mnemonic value . . .
> Of course, if you are not persuaded, and nobody else=20
> chimes in to say
> that they think this is a much better idea, you are probably=20
> better off
> implementing what you have so that people (including me) can=20
> try it out.
> And if anybody (including me) has a better idea, we can always suggest
> them as changes to your scheme.
Hey, I really like your suggested approach! =20
It is almost immediately useable by newbies after just a cursory scan of =
the bindings and it allows for a consistent set of mnemonic key =
The only real con is that it requires an extra key press but I think=20
this would be offset by the greater consistency.
Incidentally, the "C-c C-e <letter>" binding doesn't work for the eval
functions because "C-c C-e" is already bound to =
in lisp mode. However, your suggested approach is valid and I would=20
probably bind the eval functions to a "C-c C-j <letter>" binding as "j"
is a convenient, easily accessible key and the eval functions are used a =
>>> I am a little concerned that many bindings require=20
>>> C-S- and M-S-
>>> combinations for the second character. These seem more=20
>>> likely to make
>>> peoples' hands hurt than three-character sequences where each=20
>>> requires at most one modifier, with preference given to=20
>>> sequences that
>>> tend to use the same modifier combinations. But maybe=20
>>> I'm alone on
>>> this; I know I've mentioned this before, and nobody=20
>>> piped up to agree.
>> This bothered me a bit too. I tried to keep the most=20
>> frequently used=20
>> commands on lower-shift key bindings. This wasn't always=20
>> possible because
>> comint mode grabs a lot of the available lower case=20
>> 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=20
> from shells, and the fact that ilisp uses comint-mode is now something
> of a historical accident, so ilisp is justified in rebinding=20
> 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=20
> rebindings. (I'll
> bet other rebindings are due to the fact that comint-mode added them
> after ilisp.)
I've received enough emails from people saying "please don't step on
existing emacs and comint bindings" that I would be very hesitant to=20
intentionally overlap existing bindings. If we adopt the alternative=20
binding suggestion that you made above, this shouldn't be an issue.
>> Thank you very much for your comments and suggestions.=20
>> Having someone
>> propose some alternatives is good because it makes me re-think =
>> of my assumptions.
> 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. ;-}
And, occasionally, the critics actually come up with some good ideas! =
I'll update the html page showing an alternative proposal that is based
on your suggestion. Let's get some feedback on it - my first take on it=20
is that I like it more, but I'd like some other feedback too. I'll send
out another notice once I've updated the web page.
Thanks for the suggestions/comments.