From: Clementson, B. <Bil...@jd...> - 2003-04-26 20:56:09
|
Ok, I have completed a first pass over doing a complete overhaul of the ilisp fsf key bindings. I have created a web page covering the proposed changes in more detail: http://home.attbi.com/~bc19191/ilisp-keybindings.htm With these changes, I have attempted to remove incompatibilities and overlapped key bindings. I have also tried to make the key bindings more consistent. Some general consistencies that I have attempted to introduce/enforce are: 1. All key bindings are compliant with the FSF guidelines for major mode key bindings. In some cases, there is an overlap with a key binding that is defined in either standard Emacs or comint mode; however, in these cases, the overlap is consistent with the FSF guideline that "it is reasonable for a major mode to rebind a key sequence with a standard meaning, if it implements a command that does 'the same job' in a way that fits the major mode better". 2. For the most part, all of the debugging commands are of the form "C-c C-<capital letter>"). However, not all "C-c C-<capital letter>" bindings are debugging commands. 3. Similar functions are bound to variations on the same letter (i.e. -- compile-file-lisp is bound to "C-c C-k" and compile-region-lisp is bound to "C-c ESC k"). 4. All of the <action>-and-go-lisp functions are of the form "C-c ESC <capital letter>". The corresponding <action> functions are set up on the "C-c C-<letter>" or "C-c ESC <letter>" key. 5. All of the <help> related functions are set up on on "h" key bindings. 6. All of the <action>-changes-lisp functions are of the form "C-c 8 <letter>". 7. Where possible, mnemonic key bindings have been made to facilitate ease of learning and frequently-used commands have been assigned to a key binding that is easy to reach. 8. The FSF key bindings will be made the default key bindings for ILISP (replacing the "Standard" key bindings). I am posting this message to both the ilisp developers mailing list and comp.lang.lisp. Please review these proposed key bindings and either reply to the group or to me via email.=20 Thanks, -- Bill Clementson |
From: Clementson, B. <Bil...@jd...> - 2003-04-27 20:42:10
|
> My only comment is: great, thank you very much. Thanks - it was a bit more effort than what I had initially planned on = doing but I hope it will be worthwhile. Were you happy with the suggested bindings or did you feel that any of = the key bindings should be different? -- Bill Clementson |
From: Clementson, B. <Bil...@jd...> - 2003-04-28 03:40:55
|
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=20 thorough set of comments on them. > Even though binding indent-line-ilisp to TAB shadows > comint-dynamic-complete, I think that indentation is more useful than > completion in ilisp-mode. Besides, filename completion often fails in > ilisp-mode, because emacs loses track of the process CWD. In the end, I decided to not shadow any bindings (emacs or comint) = unless the shadowing conformed to the FSF guidelines for functionality that=20 does "the same job" as an existing binding. My rationale was that some user will always want the existing binding, so why make a shadowed binding if it wasn't really necessary. For individual users, there is always the option to create their own custom binding. My feeling is that new users are better off having a consistent, conformant set of = bindings. Experienced users know which bindings they don't ever need to use and=20 can make their own custom overrides. > Using "C-c {" for raw-keys-ilisp may be more mnemonic, as=20 > it suggests > that you are entering a new mode. (Pity that binding "C-c }" for > interactive-keys-ilisp would be pointless.) I'm open to "C-c {" for raw-keys-ilisp - anyone else feel strongly one way or the other? > 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=20 > 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=20 ilisp function bound to "C-c C-c", only the comint one. I have replaced=20 the binding to compile-defun-lisp with "C-c ESC c". > comint-mode binds "C-c C-w" to backward-kill-word as part=20 > 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=20 improves the consistency of the bindings - most of the "compile" = bindings=20 are now on the "k" key: "C-c C-k" compile-file-lisp=20 "C-c C-K" ilisp-compile-buffer=20 "C-c ESC" k compile-region-lisp=20 "C-c ESC" K compile-region-and-go-lisp=20 with the other "compile" bindings on the "c" key (mnemonically, a = similar binding): "C-c ESC c" compile-defun-lisp=20 "C-c ESC C" compile-defun-and-go-lisp=20 "C-c 8 c" compile-changes-lisp=20 I thought that it was worthwhile moving the compile-region-lisp binding=20 even if just to promote consistency. However, since there was also a=20 comint mode binding conflict, this was even a better reason to move it. > I don't think it's really necessary to find keybindings for every > last ilisp command, though I do admire your zeal in carrying=20 > 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=20 > 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.=20 > Also, it could be argued that reset-ilisp is somewhat risky, and > shouldn't be bound to any key. These "nonbindings" might free up more > mnemonic bindings for other uses. =20 I'm open to not binding reset-ilisp if others think this is a bad idea. > 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. =20 > 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=20 > 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=20 commands on lower-shift key bindings. This wasn't always possible = because comint mode grabs a lot of the available lower case bindings already. > And I confess this is somewhat academic for me; I now use a Kinesis > keyboard with a footpedal 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=20 their web page now and will have to have a look at their products. Do = you=20 find that you have trouble re-adjusting to a "normal" keyboard when=20 you use another person's machine? > It is probably too late to suggest that the bindings implemented by > ilisp-lispm-bindings be adopted with a "C-c" prefix, as a consistent > source of new bindings for compile-defun-lisp, eval-defun-lisp, > arglist-lisp, and documentation-lisp. That would conflict=20 > with four of > your proposed ild bindings, so is probably not feasible=20 > unless you also > choose to adopt my previous suggestion for the ild commands. The lispm bindings are bound to "C-S-<letter>" and are not compatible with fsf keybindings. For people who were lucky enough to use lispm's,=20 it probably makes most sense for them to select the keybinding set that=20 they're most comfortable with (either "standard" or "fsf") and to run=20 the ilisp-lispm-bindings function as well so that the standard lispm=20 keybindings are available. By adding "C-c" in front of the existing "C-S-<letter>" lispm binding, I don't know if that buys us much. On=20 the one hand, existing ex-lispm users will probably still manually change the bindings to the "C-S-<letter>" values. Newbies won't see any benefit over the alternatives. So, I don't see the benefit. 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 =20 |
From: Bob R. <rog...@rg...> - 2003-04-29 16:14:57
|
From: "Clementson, Bill" <Bil...@jd...> 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 |
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 |
From: Rudi S. <ru...@co...> - 2003-04-30 05:38:07
|
"Clementson, Bill" <Bil...@jd...> writes: > From: Bob Rogers on Tuesday, April 29, 2003 10:14 AM [snip Bob Rogers' three-key sequences proposal] > Hey, I really like your suggested approach! > > 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 > this would be offset by the greater consistency. > I like it, too. JDE (the Java development environment) uses three-key commands similar to the ones Bob proposed. I would be more comfortable with three-key sequences than two-key sequences that use more than one modifier per key. [huge snip] > 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 > 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. Count me as another vote in favor of it. Many thanks for your work--I really look forward to using the new command set! Rudi -- whois DRS1020334-NICAT http://constantly.at/pubkey.gpg.asc Key fingerprint = C182 F738 6B9A 83AF 9C25 62D9 EFAE 45A6 9A69 0867 |
From: Clementson, B. <Bil...@jd...> - 2003-04-30 14:47:42
|
From: Rudi Schlatte on Tuesday, April 29, 2003 11:38 PM > "Clementson, Bill" <Bil...@jd...> writes: [snip] > > I'll update the html page showing an alternative proposal=20 > that is based > > on your suggestion. Let's get some feedback on it - my=20 > first take on it=20 > > is that I like it more, but I'd like some other feedback=20 > too. I'll send > > out another notice once I've updated the web page. >=20 > Count me as another vote in favor of it. Great, that's 3 in favor, none opposed so far! And I haven't even=20 posted the updated web page yet! > Many thanks for your work--I really look forward to using the new > command set! You're welcome - and thanks for your comments. -- Bill Clementson |
From: Paolo A. <am...@mc...> - 2003-04-27 16:12:02
|
On Sat, 26 Apr 2003 14:52:08 -0600, Bill Clementson wrote: > Ok, I have completed a first pass over doing a complete overhaul of the > ilisp fsf key bindings. I have created a web page covering the proposed > changes in more detail: > > http://home.attbi.com/~bc19191/ilisp-keybindings.htm My only comment is: great, thank you very much. Paolo -- Paolo Amoroso <am...@mc...> |
From: Bob R. <rog...@rg...> - 2003-04-27 21:34:33
|
From: "Clementson, Bill" <Bil...@jd...> Date: Sat, 26 Apr 2003 14:52:08 -0600 Ok, I have completed a first pass over doing a complete overhaul of the ilisp fsf key bindings. I have created a web page covering the proposed changes in more detail . . . Please review these proposed key bindings and either reply to the group or to me via email. Thanks, -- Bill Clementson 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. ;-) From: "Clementson, Bill" <Bil...@jd...> Date: Sun, 27 Apr 2003 14:41:55 -0600 > My only comment is: great, thank you very much. Thanks - it was a bit more effort than what I had initially planned on doing . . . Funny how that is . . . -- Bob Rogers http://rgrjr.dyndns.org/ ------------------------------------------------------------------------ Comments on http://home.attbi.com/~bc19191/ilisp-keybindings.htm bindings: Even though binding indent-line-ilisp to TAB shadows comint-dynamic-complete, I think that indentation is more useful than completion in ilisp-mode. Besides, filename completion often fails in ilisp-mode, because emacs loses track of the process CWD. Using "C-c {" for raw-keys-ilisp may be more mnemonic, as it suggests that you are entering a new mode. (Pity that binding "C-c }" for interactive-keys-ilisp would be pointless.) 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? 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. 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. Also, it could be argued that reset-ilisp is somewhat risky, and shouldn't be bound to any key. These "nonbindings" might free up more mnemonic bindings for other uses. 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. 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. And I confess this is somewhat academic for me; I now use a Kinesis keyboard with a footpedal for most of my typing, so emacs is a breeze. Control-Meta-Shift-Whatever. It is probably too late to suggest that the bindings implemented by ilisp-lispm-bindings be adopted with a "C-c" prefix, as a consistent source of new bindings for compile-defun-lisp, eval-defun-lisp, arglist-lisp, and documentation-lisp. That would conflict with four of your proposed ild bindings, so is probably not feasible unless you also choose to adopt my previous suggestion for the ild commands. |