I am curious as to what other people do with respect to keybindings
when using ilisp in emacs. When I originally created the CL Cookbook
page on setting up an Emacs IDE for Common Lisp, I thought that The
Right Thing was to use the fsf keybindings for ilisp. However, in
hindsight, I'm not sure if this is the best thing to recommend to
newbies. As I see it, there are a number of different alternatives -
each with it's own pros and cons. Here are the options as I see them:
1. Use the default keybindings that come with ilisp (setq
ilisp-*use-fsf-compliant-keybindings* nil). Pros: Maximum number of
ilisp functions have a keybinding associated with them. Cons: The
default bindings do not conform to the standard keybindings that
are recommended for emacs packages. This means that (although they
may be good mnemonic matches to the ilisp commands, they might
confuse emacs newbies (in the long term) as well as be harder for
experienced emacs users to become accustomed to.
2. Use the default keybindings that come with ilisp but change the
prefix from C-z to C-c (setq ilisp-*prefix* "\C-c"). Pros: Same as
#1 with closer conformance to emacs standards. Cons: This approach
uses up keys that are supposed to be reserved for user definition.
3. Use the fsf-recommended standard emacs mappings with ilisp (setq
ilisp-*use-fsf-compliant-keybindings* t). Pros: Conforms to emacs
standards for external packages and leaves available the greatest
number of user-definable keys. Cons: Not all the ilisp commands are
mapped if fsf-compliant bindings are selected (I'm not sure why not
as many functions are mapped when this option is selected - maybe
someone who is aware of the history of ilisp can comment).
4. Use a hybrid approach of #2 & #3, using fsf keybindings where
available but using the non-fsf keybindings when no fsf keybinding
has been defined. This could be achieved by making 2 changes to
ilisp:
a. Adding a custom variable that controls this option in
ilisp-def.el: (defvar ilisp-*use-default-if-no-fsf* t)
b. Modify a function in ilisp-key.el:
(defun ilisp-safe-define-key (keymap key command &optional fsf-key)
"In KEYMAP, bind KEY to COMMAND.
If optional fourth argument FSF-KEY is non-nil, then iff
`ilisp-*use-fsf-compliant-keybindings*' is non-nil, bind FSF-KEY
instead of KEY, unless FSF-KEY is a symbol, in which case do nothing."
;; Check boundp as well as nilp -- paranoia always pays, and this
;; code only gets run at setup time anyway:
(if (and fsf-key
(boundp 'ilisp-*use-fsf-compliant-keybindings*)
ilisp-*use-fsf-compliant-keybindings*
(boundp 'ilisp-*use-default-if-no-fsf*)
ilisp-*use-default-if-no-fsf*
(symbolp fsf-key))
(setq fsf-key key))
(if (and fsf-key
(boundp 'ilisp-*use-fsf-compliant-keybindings*)
ilisp-*use-fsf-compliant-keybindings*)
(setq key fsf-key))
(unless (symbolp key)
(define-key keymap key command)))
5. Add the missing commands to the fsf keybindings in
ilisp-key.el. Pros: Maximum number of ilisp commands have direct
keybindings set up "out of the box" and the keybindings are
(mostly) in conformance with fsf emacs conventions. Cons: Since
many of the mnemonic keybindings will not be available, it will be
necessary to use non-mnemonic keybindings - these will be harder
for newbies to get accustomed to.
Options #1-#3 do not require any source code changes to ilisp while
options #4 & #5 do require source code changes. As I said at the
beginning, my initial preference was to do #3. However, I no longer am
sure that is the right approach. Looking at Franz's ELI package, they
seem to use a combination of fsf & non-fsf keybindings (generally
using the keys that fsf has defined as reserved for user-defined
keybindings). I don't like option #1. I have been playing around with
options #2 & #4 over the last couple of weeks and my current
preference is for #2 (e.g. - just change the prefix to C-c and use the
default keybindings). However, option #5 may also be worth doing (just
to get a complete set of keybindings that can be used in the
fsf-compatibility mode). I know that I can use whatever I want to,
however, for the CL Cookbook page, what do other people feel is the
best recommendation to make to newbies? Also, what do you use
yourself?
I don't ususally cross-post; however, I am posting this to both
c.l.l. and the ilisp mailing list so that I can get a range of
opinions. TIA.
--
Bill Clementson
Bill Clementson <·······@attbi.com> writes:
> 3. Use the fsf-recommended standard emacs mappings with ilisp (setq
> ilisp-*use-fsf-compliant-keybindings* t). Pros: Conforms to emacs
> standards for external packages and leaves available the greatest
> number of user-definable keys. Cons: Not all the ilisp commands are
> mapped if fsf-compliant bindings are selected (I'm not sure why not
> as many functions are mapped when this option is selected - maybe
> someone who is aware of the history of ilisp can comment).
This "Con" is not advertised in the ilisp documentation and it took me
a while to discover what one misses out on with the FSF-compliant
bindings. Realizing this, I backed off on trying to learn the
FSF-compliant bindings and turned toward the more full-featured
default ilisp interface.
I will follow this discussion with great interest.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
According to Bill Clementson <·······@attbi.com>:
> I don't ususally cross-post; however, I am posting this to both
> c.l.l. and the ilisp mailing list so that I can get a range of
> opinions. TIA.
My 2cents: I started programming Lisp from absolute zero. I am a long-time
Vim user and installed/learned (enough) Emacs for the purpose of working
with Lisp.
I've done Lisp - mostly CMUCL with Emacs/ilisp on FreeBSD - for close to a
year now. I have a colo detachtty'ed Lisp server that I connect to over ssh
in Emacs.
I've never thought about key bindings. I just use what's there.
I did have some wrist/thumb problem with pressing all those ctrl and alt
keys which weren't necessary with Vim, but that went away when I moved
from my PC keyboard to my softer, smaller notebook keyboard.
--
Ng Pheng Siong <····@netmemetic.com>
http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes
http://www.post1.com/home/ngps -+- Open Source Python Crypto & SSL
Alain Picard <·······················@optushome.com.au> writes:
...
> My personal opinion is that a package which clobbers "normal"
> keybindings is _evil_. I use ilisp in fsf keybinding mode, and even
> then, it tries to clobber bindgings it shouldn't, (e.g. C-M-l,
> reposition-window) which irks me greatly.
>
> For experts, of course, none of this matters, as we can rebind
> whatever we want to whatever we want, but for novices, I'd recommend
> fsf keybindings. I'd also encourage the ilisp maintainers to switch
> to those keybindings by default, and to change the documentation
> accordingly, and to introduce mappings for the "missing" commands
> (e.g. edit-callers, etc.). Doing otherwise is just antisocial, in
> my view.
>
> One thing I feel strongly about, is no package should _EVER_ clobber
> the C-c <key> keymap. That's MY keymap! MINE!
>
You probably are well aware of this, but just in case: you can set the
keymap ilisp clobbers by setting ILISP-*PREFIX* in your
ILISP-LOAD-HOOK.
(add-hook 'ilisp-load-hook
'(lambda ()
;; Change default key prefix to C-z
(setq ilisp-*prefix* "\C-z")
;...
))
Thanks for C-M-l, BTW. That's a new one for me, but it looks like
it's here to stay. :)
-Tim
--
> 2. Use the default keybindings that come with ilisp but change the
> prefix from C-z to C-c (setq ilisp-*prefix* "\C-c"). Pros: Same as
> #1 with closer conformance to emacs standards. Cons: This approach
> uses up keys that are supposed to be reserved for user definition.
Just for the record, that's how I've always gone about things.
Cheers,
Marcus
Alain Picard <·······················@optushome.com.au> writes:
> My personal opinion is that a package which clobbers "normal" keybindings
> is _evil_. I use ilisp in fsf keybinding mode, and even then, it tries
> to clobber bindgings it shouldn't, (e.g. C-M-l, reposition-window) which
> irks me greatly.
Hm, at least the latest CVS version does not clobber C-M-l in my
system.
> For experts, of course, none of this matters, as we can rebind whatever
> we want to whatever we want, but for novices, I'd recommend fsf keybindings.
I agree.
> I'd also encourage the ilisp maintainers to switch to those keybindings by
> default, and to change the documentation accordingly, and to introduce mappings
> for the "missing" commands (e.g. edit-callers, etc.). Doing otherwise is just
Agreed. I also think that the existing FSF bindings are quite
unintuitive in some cases, so I'd redesign the entire FSF map. The
internal code that installs keybindings should be rewritten as
well; I can't remember all the problems anymore but I once
familiarized myself with it and found issues that make choosing
different bindings hard except in .emacs or something like that.
My Easter holiday is already screwed up thanks to an incompetent
bike mechanic so I'll consider taking a look at this.
> One thing I feel strongly about, is no package should _EVER_ clobber the C-c <key>
> keymap. That's MY keymap! MINE!
:) Personally, I never use C-c <key> bindings because there are
usually faster alternatives (for example {s,H}-<foo>) but C-c <key>
is indeed reserved for users according to Elisp coding standards.
--
Hannu
From: Bill Clementson
Subject: Re: ilisp keybindings in emacs
Date:
Message-ID: <wky9269j7t.fsf@attbi.com>
Ok, the general consensus that I received from people was that the
fsf keybindings were the best ones to introduce to newbies. (Note: I
received 0 replies on the ILISP mailing list, a few on c.l.l. and
a few more replies were sent directly to me by email). A few people
also used the standard keybindings but with a "C-c" prefix instead
of the standard "C-z" prefix.
The biggest problem with the fsf keybindings is that they are not
complete. Rather than just complain and hope that they will be fixed
at some stage, I would like to propose a set of fsf keybindings for
those commands that aren't covered by the current set of mappings and
volunteer to make the necessary changes myself. There are 2 possible
problems with this:
1. There may be good reasons not to use some of my suggested mappings.
I am posting my suggested mappings here for comment - let me know
if you feel that alternative mappings would be preferable.
2. I don't have CVS check-in authority. Either I can be given developer
access or I can email my changes to one of the developers with the
necessary access. Alternatively, someone with CVS authority could
make the changes. Marco or Paolo - could you please email me on this
to let me know how you want to proceed?
Here are the proposed fsf keybindings. The definitions are in 2 separate
ilisp files at present: ild.el and ilisp-key.el.
The following keys (for lisp debugging) are defined in ild.el.
Since all of these commands are debugging commands, I have given
them a keybinding that uses a shifted letter. There aren't any capital
letter fsf-binding commands at present, so this won't be a conflict
and should be easier for beginners to remember.
Non-fsf Command Proposed-fsf
========= ================ ============
"M-a" ild-abort "C-c M-A"
"M-c" ild-continue "C-c M-C"
"C-M-s" ild-step "C-c M-S"
"C-M-n" ild-next "C-c M-N"
"C-M-p" ild-previous "C-c M-P"
"C-c-<" ild-top "C-c M-<"
"C-c->" ild-bottom "C-c M->"
"M-b" ild-backtrace "C-c M-B"
"C-M-d" ild-locals "C-c M-D"
"C-M-l" ild-local "C-c M-O"
"C-CR" ild-return "C-c M-CR"
"C-M-r" ild-retry "C-c M-R"
"C-x-t" ild-trap-on-exit "C-c M-X"
"C-c-L" select-lisp "C-c M-L"
"C-c C-f" fast-lisp "C-c M-F"
"C-c C-s" slow-lisp "C-c M-S"
The following (general ilisp) keys are defined in ilisp-key.el.
I have tried to keep them consistent with the non-fsf keybindings
where possible (with the exception of reposition-window-lisp which
conflicted with an existing fsf keybinding).
Non-fsf Command Proposed-fsf
========= ================ ============
"C-c-TAB" complete-lisp "C-c C-TAB"
"C-]" close-and-send-lisp "C-c C-]"
"C-M-r" reposition-window-lisp "C-c M-P"
"M-," next-definition-lisp "C-c M-,"
"M-." edit-definitions-lisp "C-c M-."
"M-?" search-lisp "C-c M-?"
"M-\" replace-lisp "C-c M-\"
"C-c-^" edit-callers-lisp "C-c C-^"
"M-`" next-caller-lisp "C-c M-`"
"C-c-!" default-directory-lisp "C-c C-!"
"C-c-SPC" mark-change-lisp "C-c C-SPC"
"C-c-b" switch-to-lisp "C-c M-b"
Any comments on these proposed new mappings?
--
Bill Clementson
Bill Clementson <·······@attbi.com> writes:
> The biggest problem with the fsf keybindings is that they are not
> complete. Rather than just complain and hope that they will be fixed
> at some stage, I would like to propose a set of fsf keybindings for
> those commands that aren't covered by the current set of mappings and
> volunteer to make the necessary changes myself. There are 2 possible
> problems with this:
Thanks for doing this!
> Non-fsf Command Proposed-fsf
> ========= ================ ============
> "C-c-TAB" complete-lisp "C-c C-TAB"
I've never used this (one if the interesting things about reading
this artice was seeing a number of functions that I never use and
probably should adopt) but it has a problem in that TAB and C-TAB
are not distinguishable on an ascii-only terminal.
While I don't think many people are using real terminals to write Lisp
these days, there are probably quite a few using `screen' or similar
and thus limited to running emacs in non-windowing mode.
> "M-," next-definition-lisp "C-c M-,"
> "M-." edit-definitions-lisp "C-c M-."
These are just too convenient to really want to have to type two
keystrokes for. Are there no single-key bindings available?
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Bill Clementson
Subject: Re: ilisp keybindings in emacs
Date:
Message-ID: <wky925iv1i.fsf@attbi.com>
Daniel Barlow <···@telent.net> writes:
> Thanks for doing this!
You're welcome.
> > Non-fsf Command Proposed-fsf
> > ========= ================ ============
> > "C-c-TAB" complete-lisp "C-c C-TAB"
>
> I've never used this (one if the interesting things about reading
> this artice was seeing a number of functions that I never use and
> probably should adopt) but it has a problem in that TAB and C-TAB
> are not distinguishable on an ascii-only terminal.
>
> While I don't think many people are using real terminals to write Lisp
> these days, there are probably quite a few using `screen' or similar
> and thus limited to running emacs in non-windowing mode.
That's interesting, I didn't know that. On the other hand, I never use
emacs on a terminal (or equivalent emulation), so I'm not sure what TAB
alternatives might work. Any suggestions? Alternatively, a non-TAB key
could be used. One binding that isn't used which might be suitable is
"C-c C-/"
> > "M-," next-definition-lisp "C-c M-,"
> > "M-." edit-definitions-lisp "C-c M-."
>
> These are just too convenient to really want to have to type two
> keystrokes for. Are there no single-key bindings available?
I dithered a bit over this one too. Especially, since "M-." and "M-,"
are already used for tag files and the commands are just about directly
equivalent. In fact, the Elisp manual says 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. For example, a
major mode for editing a programming language might redefine
`C-M-a' to "move to the beginning of a function" in a way that
works better for that language."
So, it should be conformant with fsf standards to rebind those keys
under ilisp mode. An alternative possibility is to have the C-c
binding be the default but to have an ilisp variable that lets the user
override the fsf behaviour for the edit/next definitions commands
(perhaps called "ilisp-*use-standard-keybindings-for-definitions*").
That way, people who use tag files in lisp won't have their standard key
bindings replaced. Franz has something similar to this in their
keybindings in ELI (e.g. - they default to "C-c-." but allow the user to
override this to "M-.".
Thanks for your comments.
--
Bill Clementson
Bill Clementson <·······@attbi.com> writes:
> Daniel Barlow <···@telent.net> writes:
>
> > Thanks for doing this!
> You're welcome.
>
> > > Non-fsf Command Proposed-fsf
> > > ========= ================ ============
> > > "C-c-TAB" complete-lisp "C-c C-TAB"
> >
> > I've never used this (one if the interesting things about reading
> > this artice was seeing a number of functions that I never use and
> > probably should adopt) but it has a problem in that TAB and C-TAB
> > are not distinguishable on an ascii-only terminal.
> >
> > While I don't think many people are using real terminals to write Lisp
> > these days, there are probably quite a few using `screen' or similar
> > and thus limited to running emacs in non-windowing mode.
>
> That's interesting, I didn't know that. On the other hand, I never use
> emacs on a terminal (or equivalent emulation), so I'm not sure what TAB
> alternatives might work. Any suggestions? Alternatively, a non-TAB key
> could be used. One binding that isn't used which might be suitable is
> "C-c C-/"
IIRC, the GNU Emacs coding guidelines say that one should strive to
leave "C-c <letter>" to the user but feel free to bind to "C-c
C-<char>" and "C-c M-<char>". Since a TAB is *really* A C-i, I'd say
let it be "C-c TAB".
//Ingvar
--
(defun m (f)
(let ((db (make-hash-table :key #'equal)))
#'(lambda (&rest a)
(or (gethash a db) (setf (gethash a db) (apply f a))))))
From: Bill Clementson
Subject: Re: ilisp keybindings in emacs
Date:
Message-ID: <wksmsdp14u.fsf@attbi.com>
Ingvar Mattsson <······@cathouse.bofh.se> writes:
> Bill Clementson <·······@attbi.com> writes:
[snip various alternatives for "C-c TAB"]
> > That's interesting, I didn't know that. On the other hand, I never use
> > emacs on a terminal (or equivalent emulation), so I'm not sure what TAB
> > alternatives might work. Any suggestions? Alternatively, a non-TAB key
> > could be used. One binding that isn't used which might be suitable is
> > "C-c C-/"
>
> IIRC, the GNU Emacs coding guidelines say that one should strive to
> leave "C-c <letter>" to the user but feel free to bind to "C-c
> C-<char>" and "C-c M-<char>". Since a TAB is *really* A C-i, I'd say
> let it be "C-c TAB".
I agree, your suggestion would still be conformant to the fsf
guidelines. The binding should just stay as it is: "C-c TAB".
--
Bill Clementson
From: Bill Clementson
Subject: Re: ilisp keybindings in emacs
Date:
Message-ID: <wkznmjgw1h.fsf@attbi.com>
Alain Picard <·······················@optushome.com.au> writes:
> I don't know if I'm the only one doing this, but I find the multi key
> keystrokes (e.g. [C-c M-b] etc.) very slow and painful, so, instead,
> I define proper Super and Hyper modifiers, and bind commands to chords
> on those (e.g, [S-b] [C-H-b] etc).
>
> This opens up an enormous new amout of keyspace at your disposal. In
> addition to your current (sane, IMO) choices of FSF bindings, you could
> also create the Super-Hyper (or is that Super-Duper? :-) ilisp bindings,
> for those fortunate enough to have and insane enough to like gazillions
> of bucky bits.
The fsf keybindings are probably the ones most worth spending time on
and use of Super and Hyper modifiers isn't conformant with the fsf
recommendations for major mode bindings.
For personal bindings (assuming you map the Super and Hyper modifiers to
appropriate keys on your keyboard), the Super/Hyper alternative might
significantly reduce the number of key presses you need to make and
these are modifications that an individual might choose to make to his
own configuration. Interesting suggestion; but, you were joking anyhow,
weren't you? ;-)
Incidentally (and off-topic), does anyone know how to map a key to a
specific portion of a pre-defined mapping? For example, if a standard
binding is "C-c C-n", how would you define a particular key to represent
the "C-c C-" portion of the binding so that it is possible to substitute
<key>-n for the "C-c C-n" command? I can't see how this would be
possible with either Super/Hyper keys or other keymap alternatives, but
it would be useful to be able to do this.
--
Bill Clementson
Bill Clementson <·······@attbi.com> writes:
> Ok, the general consensus that I received from people was that the
> fsf keybindings were the best ones to introduce to newbies. (Note: I
> received 0 replies on the ILISP mailing list, a few on c.l.l. and a
> few more replies were sent directly to me by email). A few people
> also used the standard keybindings but with a "C-c" prefix instead
> of the standard "C-z" prefix.
Does anyone have a pointer to the canonical place where the FSF
keybinding guidelines are? I believe I've found it before but I can
never find my way back. Is it in the Emacs info files?
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
From: Bill Clementson
Subject: Re: ilisp keybindings in emacs
Date:
Message-ID: <wk3ckdkbch.fsf@attbi.com>
Peter Seibel <·····@javamonkey.com> writes:
> Does anyone have a pointer to the canonical place where the FSF
> keybinding guidelines are? I believe I've found it before but I can
> never find my way back. Is it in the Emacs info files?
I'm not sure where the "canonical" place for this is. However, in the Emacs
Elisp manual, under "Emacs Lisp Coding Conventions", it says:
" * Please do not define `C-c LETTER' as a key in your major modes.
These sequences are reserved for users; they are the *only*
sequences reserved for users, so do not block them.
Instead, define sequences consisting of `C-c' followed by a control
character, a digit, or certain punctuation characters. These
sequences are reserved for major modes."
Under the Major Mode Conventions section of the Elisp manual it also
says:
" * The key sequences bound in a major mode keymap should usually
start with `C-c', followed by a control character, a digit, or `{',
`}', `<', `>', `:' or `;'. The other punctuation characters are
reserved for minor modes, and ordinary letters are reserved for
users.
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. For example, a
major mode for editing a programming language might redefine
`C-M-a' to "move to the beginning of a function" in a way that
works better for that language."
There are additonal key binding recommendations in these sections of the
Elisp manual.
--
Bill Clementson
Bill Clementson <·······@attbi.com> writes:
> Any comments on these proposed new mappings?
So I didn't see anyhting about this in your proposal but one thing
that has always bugged me about the ilisp keybindings, at least with
(setq ilisp-*prefix* "\C-c") is that C-c C-r is bound to
eval-region-and-go-lisp, clobbering the normal comint-mode function
comint-show-output. This is I guess a different kind of keyspace
problem--comint is a major mode playing by the rules and so is ilisp.
But since ilisp extends comint it seems like it shouldn't steal
existing comint bindings. Looking through the output of C-h m I see
these bindings that seem to be replacing comint bindings with
functions that don't seem to be doing the "same" thing.
C-c C-e eval-defun-and-go-lisp (was comint-show-maximum-output)
C-c C-n eval-next-sexp-and-go-lisp (was comint-next-prompt)
C-c C-r eval-region-and-go-lisp (was comint-show-output)
C-c C-w compile-region-and-go-lisp (was backward-kill-word)
Might be nice to get these cleaned up too in the standard bindings, if
there's an obvious way to do it.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
From: Bill Clementson
Subject: Re: ilisp keybindings in emacs
Date:
Message-ID: <wkbrz1kmiw.fsf@attbi.com>
Peter Seibel <·····@javamonkey.com> writes:
> So I didn't see anyhting about this in your proposal but one thing
> that has always bugged me about the ilisp keybindings, at least with
> (setq ilisp-*prefix* "\C-c") is that C-c C-r is bound to
> eval-region-and-go-lisp, clobbering the normal comint-mode function
> comint-show-output. This is I guess a different kind of keyspace
> problem--comint is a major mode playing by the rules and so is ilisp.
> But since ilisp extends comint it seems like it shouldn't steal
> existing comint bindings. Looking through the output of C-h m I see
> these bindings that seem to be replacing comint bindings with
> functions that don't seem to be doing the "same" thing.
>
> C-c C-e eval-defun-and-go-lisp (was comint-show-maximum-output)
> C-c C-n eval-next-sexp-and-go-lisp (was comint-next-prompt)
> C-c C-r eval-region-and-go-lisp (was comint-show-output)
> C-c C-w compile-region-and-go-lisp (was backward-kill-word)
>
> Might be nice to get these cleaned up too in the standard bindings, if
> there's an obvious way to do it.
I would be hesitant to make changes to the existing fsf keybindings due
to the potential impact such changes might have on people who are
already using the ilisp fsf bindings. It is unfortunate that the comint
bindings were stepped on when the original ilisp fsf keybindings were
setup; however, I think we have a "legacy code" issue now and it might
cause more problems than it would fix to try to change things at this
stage.
--
Bill Clementson
Bill Clementson <·······@attbi.com> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > So I didn't see anyhting about this in your proposal but one thing
> > that has always bugged me about the ilisp keybindings, at least with
> > (setq ilisp-*prefix* "\C-c") is that C-c C-r is bound to
> > eval-region-and-go-lisp, clobbering the normal comint-mode function
> > comint-show-output. This is I guess a different kind of keyspace
> > problem--comint is a major mode playing by the rules and so is ilisp.
> > But since ilisp extends comint it seems like it shouldn't steal
> > existing comint bindings. Looking through the output of C-h m I see
> > these bindings that seem to be replacing comint bindings with
> > functions that don't seem to be doing the "same" thing.
> >
> > C-c C-e eval-defun-and-go-lisp (was comint-show-maximum-output)
> > C-c C-n eval-next-sexp-and-go-lisp (was comint-next-prompt)
> > C-c C-r eval-region-and-go-lisp (was comint-show-output)
> > C-c C-w compile-region-and-go-lisp (was backward-kill-word)
> >
> > Might be nice to get these cleaned up too in the standard bindings, if
> > there's an obvious way to do it.
>
> I would be hesitant to make changes to the existing fsf keybindings
> due to the potential impact such changes might have on people who
> are already using the ilisp fsf bindings. It is unfortunate that the
> comint bindings were stepped on when the original ilisp fsf
> keybindings were setup; however, I think we have a "legacy code"
> issue now and it might cause more problems than it would fix to try
> to change things at this stage.
Hmmm. I guess that's a reasonable point. On the other hand, it would
be nice to clean this up--and not just to be tidy; I run into this all
the time thanks to my existing comint-mode muscle memory. (Yes, I
could fix it for myself, but I'm probably not the only person who came
to ILISP after using shell-mode.)
How many different ilisp keybinding regimes are there. I can count:
- The old-school C-z bindings. Not FSF compatible.
- The semi-FSF compliant, change C-z to C-c, via
(setq ilisp-*prefix* "\C-c")
- The closer-to-FSF compliant bindings created by
(setq ilisp-*use-fsf-compliant-keybindings* t)
- Your proposed changes.
- A version of yours that also doesn't clobber the comint bindings.
I sort of shudden to suggest it but maybe another flag
ilisp-*do-not-clobber-comint* or something. Or, perhaps there could
just be one flag ilisp-*keybinding-style* that can take some indicator
of which style (from the above list) one wants. (That would certainly
clear things up for me--I'm still not exactly sure what the difference
between (setq ilisp-*prefix* "\C-c") and (setq
ilisp-*use-fsf-compliant-keybindings* t) is.
Assuming we had a FSF *and* comint-mode compatible keybinding, that
would be the one new users should use. The other modes could be
preserved for anyone who's already got *them* in their muscle memory.
I might further argue that the newbie compatible one should be the
default because anyone who's a long-time user might reasonably be
expected to understand how to put the right elisp in their .emacs to
switch back to their prefered scheme.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
From: Bill Clementson
Subject: Re: ilisp keybindings in emacs
Date:
Message-ID: <wkel3too9q.fsf@attbi.com>
Peter Seibel <·····@javamonkey.com> writes:
> Assuming we had a FSF *and* comint-mode compatible keybinding, that
> would be the one new users should use. The other modes could be
> preserved for anyone who's already got *them* in their muscle memory.
> I might further argue that the newbie compatible one should be the
> default because anyone who's a long-time user might reasonably be
> expected to understand how to put the right elisp in their .emacs to
> switch back to their prefered scheme.
Ok, I've been convinced. So far, based on the feedback that I've had on
c.l.l., the ilisp help/developer lists, and in private emails, it seems
like most people are in favor of a general clean-up of the ilisp FSF
keybindings as well as adding in missing keybindings. So, unless I start
to hear howls of protest about changing the existing FSF keybindings, I
am going to expand the scope of the changes to include a general tidy-up
of the existing keybindings.
Over the next few days, I will review all of the FSF keybindings and
will post on c.l.l. and the ilisp developer mailing list a complete
listing of ilisp FSF keybindings grouped into 3 categories:
1. New FSF keybindings for commands that are in the default ilisp
keybindings but not in the current FSF keybindings
2. Existing keybindings that need to be changed (with a reason for the
change and a suggested keybinding). Changes will be suggested for
existing keybindings that "step on" comint (or other standard
bindings) without providing equivalent functionality.
3. Existing FSF keybindings that don't need to be changed (so that
people can point out potential problems/conflicts that I might have
missed).
After I post this listing, I will ask for feedback on the
changes. If you are an ilisp user, please take the time to review the
proposed changes and the new keybindings.
--
Bill Clementson
Bill Clementson <·······@attbi.com> writes:
> Over the next few days, I will review all of the FSF keybindings and
> will post on c.l.l. and the ilisp developer mailing list a complete
> listing of ilisp FSF keybindings grouped into 3 categories:
>
> 1. New FSF keybindings for commands that are in the default ilisp
> keybindings but not in the current FSF keybindings
>
> 2. Existing keybindings that need to be changed (with a reason for the
> change and a suggested keybinding). Changes will be suggested for
> existing keybindings that "step on" comint (or other standard
> bindings) without providing equivalent functionality.
>
> 3. Existing FSF keybindings that don't need to be changed (so that
> people can point out potential problems/conflicts that I might have
> missed).
>
> After I post this listing, I will ask for feedback on the changes.
> If you are an ilisp user, please take the time to review the
> proposed changes and the new keybindings.
Awsome!
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Bill Clementson <·······@attbi.com> writes:
[snip]
> Over the next few days, I will review all of the FSF keybindings and
> will post on c.l.l. and the ilisp developer mailing list a complete
> listing of ilisp FSF keybindings
[snip]
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.
Thanks,
--
Bill Clementson
Bill Clementson <·······@attbi.com> writes:
> 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").
Is there a difference between C-c ESC k and C-c M-k, from emacs's
point of view?
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Peter Seibel <·····@javamonkey.com> writes:
> Bill Clementson <·······@attbi.com> writes:
>
> > 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").
>
> Is there a difference between C-c ESC k and C-c M-k, from emacs's
> point of view?
No, they're the same (for all practical purposes) for the ilisp bindings
that are defined.
--
Bill Clementson
Bill Clementson <·······@attbi.com> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > Is there a difference between C-c ESC k and C-c M-k, from emacs's
> > point of view?
>
> No, they're the same (for all practical purposes) for the ilisp bindings
> that are defined.
With the caveat that the latter does nasty things to your X Server,
while the former does not, on some platforms, IIRC.
Jacek Generowicz <················@cern.ch> writes:
> > Peter Seibel <·····@javamonkey.com> writes:
> >
> > > Is there a difference between C-c ESC k and C-c M-k,
> the latter does nasty things to your X Server,
Apologies, brain fart, I was referring to C-M-k.
Jacek Generowicz <················@cern.ch> writes:
> Jacek Generowicz <················@cern.ch> writes:
>
> > > Peter Seibel <·····@javamonkey.com> writes:
> > >
> > > > Is there a difference between C-c ESC k and C-c M-k,
>
> > the latter does nasty things to your X Server,
>
> Apologies, brain fart, I was referring to C-M-k.
Nope, you were referring to M-C-Backspace, which kills
badly-configured Xfree86 servers. You can fix it by setting No-Zap or
Dont-Zap, in your configuration file.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
>>>>> "Thomas" == Thomas F Burdick <···@famine.OCF.Berkeley.EDU> writes:
Thomas> You can fix it by setting No-Zap or Dont-Zap, in your
Thomas> configuration file.
I used to fix this on all machines I had the apropriate rights on but
I found myself constantly zapping my colleagues X sessions whenever I
was helping them out because M-C-Backspace was such a convenient
option that just sat i my fingers.
I have stopped fixing X configurations and is trying to teach myself
to use M-C-Delete instead which has the same effect.
------------------------+-----------------------------------------------------
Christian Lynbech | email: christian ··@ defun.dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Jacek Generowicz <················@cern.ch> writes:
>
> > Jacek Generowicz <················@cern.ch> writes:
> >
> > > does nasty things to your X Server,
> >
> > Apologies, brain fart, I was referring to C-M-k.
>
> Nope, you were referring to M-C-Backspace, which kills
> badly-configured Xfree86 servers.
Nope, I was most definitely NOT referring to M-C-Backspace; I'm well
aware of that one too, but I was talking about something else.
Maybe I dreamed it, and have subsequently been slave to a
superstition, but I religiously avoid C-M-k in its (M = Alt)
incarnation, and use its (M = Esc) version instead, because it did
something very nasty to some long running process that I cherish, the
first time I tried it ... it may have been Emacs, rather than the X
server.
OK, I suppressed my irrational fear and I tried it. It didn't kill
XEmacs, it failed to kill FSF Emacs ... in fact it failed to do
anything unpleasant.
What liberation !
I wonder what I'd been smoking when I dreamt that one up.
Maybe it was some feature of the configuration of the system I was
using at the time.
Jacek Generowicz <················@cern.ch> writes:
> What liberation !
>
> I wonder what I'd been smoking when I dreamt that one up.
If I were you, I'd fix your setup to make M-C-Backspace safe too, or
you'll probably end up accidentall hitting it. For a while I was
working on XFree86 systems without Dont-Zap, and tried just avoiding
M-C-Backspace. But using M-C-k conditions you to the M-C- meaning,
and sure enough, I found myself just after a sexp, and I'd kill X
instead of it. :-P
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> If I were you, I'd fix your setup to make M-C-Backspace safe too, or
> you'll probably end up accidentall hitting it.
I'm ambivalent about this for reasons similar to those mentioned by
someone upthread ... screwing things up when working in someone else's
environment. I've been bitten like this a few times before, and it
sure is a good way of pissing people off :-(
> > Might be nice to get these cleaned up too in the standard
> > bindings, if there's an obvious way to do it.
>
> I would be hesitant to make changes to the existing fsf keybindings
> due to the potential impact such changes might have on people who
> are already using the ilisp fsf bindings. It is unfortunate that the
> comint bindings were stepped on when the original ilisp fsf
> keybindings were setup; however, I think we have a "legacy code"
> issue now and it might cause more problems than it would fix to try
> to change things at this stage.
Oh, please do it. One should ALWAYS fix such problems as soon as they
are detected. There will be a brief instant of (possibly intense)
pain, but years of satisfaction to follow.
Remember the infamous Makefile bug, and how the author said that he
didn't want to fix the problem because he already had 5 users.
--
Fred Gilham ······@csl.sri.com
We have yet to find the Galileo who will question
our me-centred universe. --- Christina Odone
From: Bill Clementson
Subject: Re: ilisp keybindings in emacs
Date:
Message-ID: <wk7k9nibf0.fsf@attbi.com>
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> > > Might be nice to get these cleaned up too in the standard
> > > bindings, if there's an obvious way to do it.
> >
> > I would be hesitant to make changes to the existing fsf keybindings
> > due to the potential impact such changes might have on people who
> > are already using the ilisp fsf bindings. It is unfortunate that the
> > comint bindings were stepped on when the original ilisp fsf
> > keybindings were setup; however, I think we have a "legacy code"
> > issue now and it might cause more problems than it would fix to try
> > to change things at this stage.
>
> Oh, please do it. One should ALWAYS fix such problems as soon as they
> are detected. There will be a brief instant of (possibly intense)
> pain, but years of satisfaction to follow.
>
> Remember the infamous Makefile bug, and how the author said that he
> didn't want to fix the problem because he already had 5 users.
What do others think about a general tidy-up of the ilisp fsf bindings?
On the one hand, it would remove the cases where the ilisp fsf bindings
step on existing comint (or other) bindings and perhaps clean up some of
the mappings. On the other hand, it can break the setups of people who
already use the ilisp fsf bindings and some people are already
accustomed to the existing bindings.
How many votes for:
1. Keeping existing fsf bindings and only adding the missing ones
2. Adding the missing fsf bindings and replacing bindings that shadow
either standard or comint-mode bindings
--
Bill Clementson
Bill Clementson <·······@attbi.com> writes:
> How many votes for:
>
> 1. Keeping existing fsf bindings and only adding the missing ones
> 2. Adding the missing fsf bindings and replacing bindings that shadow
> either standard or comint-mode bindings
I vote for 2.
marc
Bill Clementson <·······@attbi.com> writes:
> How many votes for:
>
> 1. Keeping existing fsf bindings and only adding the missing ones
> 2. Adding the missing fsf bindings and replacing bindings that shadow
> either standard or comint-mode bindings
If we're voting, I vote for 2.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Option 2
Bill Clementson <·······@attbi.com> writes:
How many votes for:
1. Keeping existing fsf bindings and only adding the missing ones
2. Adding the missing fsf bindings and replacing bindings that shadow
either standard or comint-mode bindings