RE: Re: Ilisp FSF key binding changes

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

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

> > C-c C-q C-c	cltl2-lookup
> > C-c C-q C-h	hyperspec-lookup
> > C-c C-q C-o	documentation-lisp
> > C-c C-q C-a	arglist-lisp
> 
> Admittedly it is logical for C-a to be bound to arglist-lisp, 
> but there is also apropos, which in Emacs is bound to C-h a.  
> Perhaps one could consider C-c C-h a assuming the C-q -> C-h 
> change.  On the other hand, maybe ilisp-arglist-message-lisp 
> and eldoc kind of things are gradually making a binding for 
> arglist-lisp less used, which might suggest that even C-a 
> could be used for something else than arglist-lisp.  Then 
> again, perhaps not everyone likes to use eldoc sort of stuff...

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.

> > C-c C-q TAB	inspect-lisp
> > C-c C-q C-d	describe-lisp
> >
> > Buffer/Edit bindings (C-c C-g):
> 
> [Later discussion reveals that these have been moved to C-c C-f.]

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.

[snip]

> > Debug bindings (C-c C-b):
> > C-c C-b C-g	slow-lisp
> > C-c C-b C-f	fast-lisp
> > C-c C-b C-x	ild-trap-on-exit
> > C-c C-b C-r	ild-retry
> > C-c C-b RET	ild-return
> > C-c C-b C-l	ild-local
> > C-c C-b C-d	ild-locals
> > C-c C-b C-b	ild-backtrace
> > C-c C-b C-w	ild-bottom
> > C-c C-b C-v	ild-top
> > C-c C-b C-p	ild-previous
> > C-c C-b C-n	ild-next
> > C-c C-b C-s	ild-step
> > C-c C-b C-c	ild-continue
> > C-c C-b C-a	ild-abort
> > C-c C-b C-y	status-lisp
> > C-c C-b C-z	reset-ilisp
> > C-c C-b C-t	trace-defun-lisp
> > C-c C-b C-k	macroexpand-lisp
> > C-c C-b C-^	raw-keys-ilisp
> 
> 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?

[snip]

Thanks for your comments and suggestions. I think we are almost there
now and I appreciate the review work that everyone is doing to help get
these bindings right. 

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