RE: ilisp keybindings in emacs
Bob Rogers <[email protected]>
| Newsgroups | gmane.lisp.ilisp.devel |
|---|---|
| Message-ID | <[email protected]> |
From: "Clementson, Bill" <[email protected]> Date: Mon, 21 Apr 2003 13:51:37 -0600 From: Bob Rogers on Sunday, April 20, 2003 8:14 PM > I would like to add the suggestion that, at the very least, the > FSF-compliant bindings should become the default out of the > box. (This > may have been your intent, but I don't believe you ever said so out > loud.) We should probably also start to call the other set the > "traditional" bindings. This ought to make getting started with ilisp > easier. This was not my original intent; however, I am happy to make the necessary change if this is the consensus opinion. This (or course) has the potential to break other people's setups if the default is changed to be the fsf keybindings. Do we really want to subject ourselves to the gazillion emails that usually result from such a change? As long as backward compatibility is only a dot-emacs one-liner, and as long as the change of default is well advertised in release materials, I would imagine that this would be acceptable. Seems to me that the typical ilisp user is better equipped than most other emacs package users to deal with such incompatible changes, and would also appreciate the value of standards compliance. > . . . However, I note that there is a ilisp-lispm-bindings function > that installs the exact Zmacs bindings, e.g. "C-S-c" for > compile-defun-lisp where "S-" is shift. We might want to consider > using these instead of the traditional bindings; there's a comment > that says the LispM style bindings are not FSF-compliant, but that > wouldn't matter if FSF bindings became the default. But perhaps > this is too radical; it wouldn't help the newbies in any case. My own opinion is that this is too radical - any user who wants to use the lispm bindings can select them manually. True -- this sounded more reasonable when I started to write the paragraph than when I finished. But I thought I'd leave it in just to see what comments it elicited. On the one hand, I'm glad nobody jumped down my throat; on the other hand, maybe nobody's listening. ;-} In any case, there are only a few lispm bindings supported. I may be wrong, but I think ilisp-lispm-bindings pretty much defines all of the Zmacs bindings that make sense. Many of the commands in ilisp-mode-map don't have a Zmacs equivalent (e.g. switch-to-lisp, select-ilisp, and all of the ild commands), or were commonly invoked via "M-x" anyway (e.g. compile-file-lisp). You're right though; that still leaves too many orphaned bindings. One could still proceed along these lines to define more Lispm-style bindings, but there's probably no market for this. > * I note that most of your proposed bindings are of the form "C-c > M-something", but it seems to me that "C-c C-something" would be less > awkward to type. Or is this frowned on by the FSF keybinding rules? No, it is consistent with the FSF keybinding rules and would be easier to type. I'll change the proposed FSF ILD keybindings from "C-c M-something" to "C-c C-something" (where possible)if nobody sees any reason not to. Good; that will be a help. > * Seems to me that edit-definitions-lisp should probably stay on > "M-."; it shadows find-tag, but provides much the same > functionality in a more Lisp-aware way. If that isn't a good > enough reason to violate the rules, then I'm not sure what is. > > * next-definition-lisp (on "M-,") is less clear, as > next-definition-lisp is not really equivalent to tags-loop-continue > -- in any case, "C-u M-." invokes next-definition-lisp (in CVS). I've had a number of emails specifically about "M-." and "M-,". Some have indicated a preference for letting them override the "standard" tag functionality (since they perform the same type of functionality and the fsf standards permit that type of override) while others indicated that they don't think a major mode should step on "any" bindings. FWIW, I sometimes find myself typing "M-x find-tag" in an ilisp buffer, so I don't think the onus is great. But maybe that's just me. One alternative might be to have "C-c M-." and "C-c M-," as the FSF bindings but to have a variable "ilisp-*use-standard-keybindings-for-definitions*" that allows the user to override the FSF bindings and use "M-." and "M-," instead . . . That is reasonable, I think. However, I think there are far too many keybinding-related variables to begin with. How about using (eq ilisp-*use-fsf-compliant-keybindings* 'strict) to select "C-c M-." and "C-c M-," instead? Personally, I would probably set the new default to "t" rather than "strict", but have no strong opinions either way. -- Bill Clementson From: "Clementson, Bill" <[email protected]> Date: Mon, 21 Apr 2003 13:59:02 -0600 While we're on the subject of ilisp keybindings, I thought I should bring up a broader topic. A number of people on comp.lang.lisp and in private emails have suggested a complete rehaul of the fsf keybindings to eliminate the cases where they "step on" comint mode bindings and to make them more consistent. What do others think? I for one would appreciate an overhaul. I use M-x shell instead of xterm's (and even wrote a M-x ssh), and in fact reinstate some of the commands shadowed by newer ilisp-mode-map bindings (e.g. C-M-l) so that Lisp interaction buffers behave more like shell-mode. On the one hand, any major revision of existing fsf keybindings will have a major impact on existing users and will undoubtedly cause a rash of "HELP" emails when the changes are released. On the other hand, such a tidy-up would eliminate some of the issues with the current keybindings and provide a more consistent set of bindings. This sounds like The Right Thing to me. Should I just stick to adding the missing fsf keybindings as detailed in my earlier emails or should the scope be expanded to a general cleanup of all the fsf keybindings? -- Bill Clementson Again, barring howls of outrage on this list, I would assume that the ilisp community would be more willing to tolerate such changes than most emacs users, especially if the changes were well thought-out and well documented. Paradoxically, the wider you cast your net, the easier it should be to show that you are Doing The Right Thing, which should be sufficient. Of course, I can only speak for myself. As insurance, you might want to post your redesign via the same channels you sent your original query. I'll bet concrete lists of key bindings will generate more responses. It's not a small job, though. Out of curiousity, I snarfed the variation of the "traditional" ilisp-mode-map bindings that I use out of C-h m, and massaged them for sorting; the result is appended. Here are the totals: 64 lisp (incl. cltl2-lookup, hyperspec-lookup, complete) 24 comint 12 ild 1 misc (alternate backward-kill-word binding) === 101 total Hope this is useful (rather than tedious, or daunting), -- Bob ------------------------------------------------------------------------ C-z g abort-commands-lisp C-z a arglist-lisp C-c C-w backward-kill-word ESC C-a beginning-of-defun-lisp C-a bol-ilisp C-z y call-defun-lisp C-z * 0 clear-changes-lisp C-] close-and-send-lisp C-z L cltl2-lookup C-c SPC comint-accumulate C-c C-a comint-bol-or-process-mark C-c RET comint-copy-old-input C-c return comint-copy-old-input C-c C-l comint-dynamic-list-input-ring C-c C-x comint-get-next-from-history C-c C-u comint-kill-input C-c C-o comint-kill-output C-down comint-next-input ESC n comint-next-input ESC s comint-next-matching-input C-c ESC s comint-next-matching-input-from-input C-c C-n comint-next-prompt C-up comint-previous-input ESC p comint-previous-input ESC r comint-previous-matching-input C-c ESC r comint-previous-matching-input-from-input C-c C-p comint-previous-prompt C-c C-\ comint-quit-subjob C-c C-d comint-send-eof C-c C-e comint-show-maximum-output C-c C-r comint-show-output ESC C-l comint-show-output C-c C-z comint-stop-subjob C-z ; comment-region-lisp C-z * c compile-changes-lisp C-z c compile-defun-lisp C-z k compile-file-lisp C-z C-w compile-region-and-go-lisp C-z w compile-region-lisp ESC RET complete C-c TAB complete-lisp ESC TAB complete-lisp C-z ! default-directory-lisp C-d delete-char-or-pop-ilisp C-z i describe-lisp C-z d documentation-lisp C-z ^ edit-callers-lisp ESC . edit-definitions-lisp ESC C-e end-of-defun-lisp C-z * e eval-changes-lisp C-z C-e eval-defun-and-go-lisp C-z e eval-defun-lisp ESC C-x eval-defun-lisp C-z C-n eval-next-sexp-and-go-lisp C-z n eval-next-sexp-lisp C-z C-r eval-region-and-go-lisp C-z r eval-region-lisp C-z C-f fast-lisp C-x C-f find-file-lisp C-z ) find-unbalanced-lisp C-z H hyperspec-lookup ESC a ild-abort ESC b ild-backtrace C-c > ild-bottom ESC c ild-continue ESC C-d ild-locals ESC C-n ild-next ESC C-p ild-previous ESC C-r ild-retry C-c r ild-return ESC C-s ild-step C-c < ild-top C-x t ild-trap-on-exit SPC ilisp-arglist-message-lisp-space C-z 1 ilisp-bury-output C-z C-b ilisp-compile-buffer C-z v ilisp-scroll-output TAB indent-line-ilisp ESC C-q indent-sexp-ilisp C-z I inspect-lisp C-c C-c interrupt-subjob-ilisp C-z * l list-changes-lisp C-z l load-file-lisp C-z m macroexpand-1-lisp C-z M macroexpand-lisp C-z SPC mark-change-lisp C-j newline-and-indent-lisp ESC ` next-caller-lisp ESC , next-definition-lisp C-z # raw-keys-ilisp ESC " replace-lisp C-z z reset-ilisp RET return-ilisp ESC ? search-lisp C-z S select-ilisp C-z p set-buffer-package-lisp C-z P set-package-lisp C-z C-s slow-lisp C-z s status-lisp C-z b switch-to-lisp C-z t trace-defun-lisp ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf