From: Clementson, B. <Bil...@jd...> - 2003-04-30 04:34:49
|
From: Bob Rogers on Tuesday, April 29, 2003 10:14 AM [snip] > 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 > "C-c". >=20 > But, just for grins, here's an alternative that binds each=20 > command to > a sequence of three keys: >=20 > "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 >=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: >=20 > "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 >=20 > None of these commands (compile or eval) is really useful in=20 > ilisp-mode; > certainly, the "and-go" forms would be redundant. >=20 > 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 . . . >=20 > 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 = bindings. 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 = comint-show-maximum-output 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 = lot. [snip] >>> 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 >>> character >>> 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. >>=20 >> 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. >=20 > Yes, and many of those bindings are useful, which is why I agree that > leaving them in place is a win. >=20 > On the other hand (and here I'm playing devil's advocate), it would > be reasonable to maintain that Lisp sessions are sufficiently=20 > different > 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. [snip] >> Thank you very much for your comments and suggestions.=20 >> Having someone >> propose some alternatives is good because it makes me re-think = some >> 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. - Bill |