Re: Re: Ilisp FSF key binding changes

"Clementson, Bill" <[email protected]> writes:

> From: Hannu Koivisto [mailto:[email protected]] 
>> These are starting to look usable but I must add a few 
>> comments below.  This is actually the first time I'm really 
>> taking a good look at these.  Great work in any case.
>> 
>> > Compile bindings (C-c C-k):
>> > C-c C-k C-f	compile-file-lisp
>> > C-c C-k C-@	compile-changes-lisp
>> 
>> Why C-@ instead of C-c?  C-@ involves pressing two modifiers 
>> on my keyboard :\  Not that I use compile-changes-lisp...
>
> I wanted a key that could be used consistently across the other prefixes
> to indicate "changes"-related commands. Unfortunately, there wasn't an
> alphabetic choice that worked well. My first choice was "*" but that
> character can't be used in a control key sequence while "@" can. The
> following commands are all "changes" commands and are on different
> prefix bindings:
> C-c C-k C-f	compile-file-lisp
> C-c C-j C-@	eval-changes-lisp
> C-c C-v C-@	list-changes-lisp
> C-c C-v @	clear-changes-lisp

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.

> [snip]
>
>> > Query bindings (C-c C-q):
>> 
>> I would have expected to find these under C-c C-h since C-h 
>> is the help prefix (under which are also things like describe 
>> and apropos) in Emacs.  A lot faster and easier to hands to 
>> type as well (the same issue as with C-e/C-j), IMO.  I'd like 
>> to suggest changing this.  YMMV.  (I'm aware of what Coding 
>> Conventions say about this, so no need to tell me that.)
>
> I had originally used C-c C-h but replaced it when it was pointed out to
> me that it conflicts with the FSF coding conventions. One of the
> objectives of this exercise was to create bindings that were compliant
> with the FSF major mode coding conventions and I didn't want to
> (knowingly) violate any of the standard conventions since this always
> causes problems for somebody.

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.

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.

> Even if you use the eldoc-like funcitonality when entering new code, the
> arglist-lisp binding is useful when you are examining existing code and
> want to know what the argument list is for a function.

Actually, if there was eldoc support, it would show arguments even
for existing code (eldoc is different from
ilisp-arglist-message-lisp-space in this respect).  But I agree,
C-a is a good choice for arglist-lisp.  apropos can be put to C-c
C-q a, for example.

> 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.

>> I'd almost call these Backtrace bindings and have C-c 
>> C-<something> for other debug bindings, when there is need.  
>> Or maybe just say that there are debug bindings under C-c C-b 
>> and C-c C-<something>, because there is overlap anyway.  It's 
>> just that most of these involve fiddling with the backtrace 
>> and they pretty much eat the bindings from any reasonable debugger.
>
> I don't understand this comment - what "reasonable debugger" for CL are
> you referring to that sets up its own emacs bindings?

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.

-- 
Hannu


-------------------------------------------------------
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