RE: Re: Ilisp FSF key binding changes

From: Hannu Koivisto on Wednesday, May 21, 2003 10:43 AM
[snip discussion on why "@" was used for "changes" commands]
> Ah, I didn't consider this.  Now that I have, I still think 
> C-c C-k C-c and C-c C-j C-c would be better bindings.  I 
> think consistency doesn't comfort much if the bindings are 
> very inconvenient.

Ok, you've convinced me - I'll change the call-defun-lisp binding to
"C-c C-v C-j" and use the "c" binding for the changes commands:

C-c C-k C-c	compile-changes-lisp
C-c C-j C-c	eval-changes-lisp
C-c C-v C-c	list-changes-lisp
C-c C-v c	clear-changes-lisp


[snip discussion about conforming to FSF coding conventions]

> There is always someone to whom something causes problems.  I 
> think it's silly to follow all the conventions just for 
> convetions' sake. Note the reasoning: "If you don't bind 
> `C-h', it is automatically available as a help character for 
> listing the subcommands of the prefix character."  This 
> doesn't even seem to be true, I couldn't find a single mode 
> where C-c C-h would have listed the subcommands of the prefix 
> character (something like C-c RET C-h does work for example 
> in message-mode, though.)  Not very surprising, there are 
> often oodles of commands behind C-c.  I'd expect that in this 
> case the user really wants C-h m.

In fact, "C-c C-h" in ilisp or lisp mode produces a very nice summary of
the C-c bindings. The "C-h m" binding produces a much more verbose
summary of the commands offered by the mode. I agree with Bob Rogers on
this one and feel that the "C-c C-h" binding should not be used for
ilisp bindings. 

> I can certainly appreciate that the choice to avoid C-h is 
> consistent with your aim to purity.  Purity is not a problem 
> for me, I can always change the bindings for myself.  But I 
> don't agree with it.  You chose consistency over convenience 
> in the "changes"-related commands -case and you chose to 
> avoid C-c C-f because in XEmacs it is bound by default to 
> something that I can't believe no one could possibly want to, 
> or even could, use in the case of ILISP.  Heck, even core 
> XEmacs modes seem to override it. Not exactly surprising, I 
> can't understand why they bind C-c C-f to such a command by 
> default to begin with.

The point is, the binding is already taken by comint mode. I have
received a number of emails from people who either use comint mode
extensively for other purposes or who have created their own modes based
on comint mode. These people have the comint key bindings "burned" into
their fingertips. If it is possible to avoid "shadowing" an existing
comint mode binding, I think that it is preferable to do so.

> > I have just received an email from Kevin Rosenberg 
> indicating that C-c 
> > C-f conflicts with a comint binding in xemacs. Therefore, I have 
> > changed the prefix (yet again) from C-c C-f to C-c C-v. The changes 
> > have now been posted to cvs.
> 
> As mentioned above, I disagree with this change.  But we can 
> agree to disagree.

Ok :)

[snip debug binding comments]
> That's not what I meant.  I meant that the current C-c C-b 
> -list lacks several commands that are provided by good 
> debuggers and it should be ensured that good keybindings can 
> be arranged for them. For example, the list does not contain 
> any commands for setting [temporary] breakpoints and 
> watchpoints, it contains only one step command, etc.  I think 
> that another prefix needs to be used for these, there simply 
> isn't room in C-c C-b map.

There is a scarcity of "free" prefix bindings available for the
ilisp/lisp modes. As I mentioned in my last email, only the "C-c C-t"
and the "C-c C-y" prefixes are left. At the moment, the "C-c C-b" prefix
has the alphabetic characters "e, h, i, j, o, q" not currently bound to
any commands. In addition, there would be the "C-c C-b <key>" commands
available in the event that some larger number of bindings was needed.
At this stage, I don't think it is worthwhile to split the commands in
the "C-c C-b" binding into 2 separate prefix sets.

Thanks again for the comments. I have committed the "changes" ("@" ->
"c") key binding mods listed above to cvs.

--
Bill Clementson


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge