RE: Ilisp key binding changes (Option #2) - Please Review

   From: Edi Weitz <[email protected]>
   Date: 01 May 2003 20:19:26 +0200

   . . .

   But let me re-iterate what someone else has said on c.l.l: Some of
   these non-letter characters are very hard to type for localized
   keyboards, e.g. on my German keyboard {[]}\|@ can only be reached by
   pressing the right ALT key ("AltGr") together with another key. I
   guess this is about the same for most European keyboard variants.

Is this because the keyboard moves the non-letter ASCII characters in
order to make umlauted characters more prominent?  If so, then you might
be able to get some relief by setting up function-key-map "bindings"
that turn modified umlauted keys into modified special ASCII keys.  Here
is the first paragraph of the function-key-map C-h v documentation:

	Keymap mapping ASCII function key sequences onto their preferred forms.
	This allows Emacs to recognize function keys sent from ASCII
	terminals at any point in a key sequence.

Despite what it says about ASCII, the mechanism is quite general; the
default value (in emacs 20.7 anyway) has bindings for X11 keysyms such
as kp-insert and kp-5.  This remapping happens at a low enough level
that terminal characters are remapped even in the middle of bindings.
For example, if you were to do

	(define-key function-key-map [kp-5] "\C-f")

then typing "C-x kp-5" is equivalent to "C-x C-f".  So I imagine you
might be able to re-encode whatever #\control-umlaut-u (for example)
produces, some ISO-8859-* code byte I assume, into #\control-^, or
something else more useful to you when interacting with emacs.  [And I'm
using Lisp character syntax here because I don't know how to type
#\umlaut-u on my keyboard.  ;-]

   If you do try this, please let me know whether it works; I'm very
curious, and have no personal experience with European keyboards.

   From: "Clementson, Bill" <[email protected]>
   Date: Thu, 1 May 2003 12:43:27 -0600

   From: Edi Weitz on Thursday, May 01, 2003 12:19 PM

   [snip, snip]

   > So, I think you'll have to find a balance between the needs of
   > terminal users and the needs of users of localized keyboards. I,
   > personally, never use Emacs over a terminal line... :)

   Same for me; however, half of all the responses that I have received
   from c.l.l., the ilisp lists and via email have been from terminal
   users. So, (for some segment of the ilisp community at least) I 
   would like to provide bindings that work well on a dumb terminal. 

I'm surprised.  It's been years since I've used ilisp via a terminal,
and I had assumed that broadband/ssh/X11 had removed the need.  I still
use emacs on dumb console or xterm connections, but I no longer need
ilisp under those circumstances.  (Dealing with broken terminal
emulators is what led me to function-key-map, btw.)

   But the function-key-map mechanism has some potential to solve this
problem as well.  It contains a set of remappings that use the "C-x @"
prefix to apply modifier bits to subsequent "events" in the input
stream.  For example, "C-x @ c" is bound to
event-apply-control-modifier, which turns the next character into a
control character, even on a terminal, and regardless of whether ASCII
supports it.  Other "C-x @" bindings do the same for other modifiers.

   The only problem is that these remappings are unusable for key
sequences that start with "C-x".  You can try typing "C-x C-x @ c f",
which ought to remap to "C-x C-f", but the first two characters run
exchange-point-and-mark, since that is what is bound to "C-x C-x" by
default.  It is not clear to me how to fix this for two-character
sequences, and none of the three-character sequences seem to require
non-ASCII control characters in any position.  If these characters were
only needed for the third character in a three-key sequence, and we were
careful never to bind the third key to "C-x", then we could tell
terminal users to type "C-x C-k C-x @ c A" for "C-x C-k C-A".  And
regular terminal users should probably consider using a function key to
send the "C-x @ c" sequence in any case.

   But if we made three-character sequences out of the bindings that use
non-ASCII characters, which seem to be mostly ild commands, then we
probably wouldn't need to use non-ASCII characters at all.  Which leads
me back to an earlier suggestion:

	   * Alternatively, you might want to consider using simple
	three-character sequences for ild commands . . .  I would suggest "C-c
	C-d" as a prefix for mnemonic value, except that "C-c C-d" shadows
	comint-send-eof, alas.  However, "C-c C-d a" or "C-c C-d C-a" would be
	much more reasonable to type for ild-abort.  (But select-lisp,
	fast-lisp, and slow-lisp aren't specific to debugging, so shouldn't use
	such a debugging prefix.)

Since "C-c C-d" is out, I would pick another left-hand key for the
second character so that people don't have to switch control keys while
touch-typing.  How about "C-v", since I can't find anything more
mnemonic?  So ild-abort would become "C-c C-v a" (though "C-c C-v C-a"
might be even easier to type).

   > Thank you very very much for the enormous amount of work you put into
   > this. I'm one of those who use only a small percentage of what ILISP
   > has to offer and one of the reasons is that I haven't taken the time
   > yet to learn the keybindings. Your effort will be a very good reason
   > for me to finally do it!

Hear, hear!

   You're welcome. I'm quite looking forward to having the new bindings
   in place too. I found that I used only a relatively small subset of the
   ilisp bindings before I started this exercise. With more consistency 
   and bindings that are easier to remember, I think that will change 
   for a lot of people (myself included). Bob Rogers' suggestions regarding 
   the key bindings have made it a lot easier to achieve this consistency 
   and he should get a lot of the credit.

   --
   Bill Clementson

Thanks for the pat on the back, but I'd say you're still squarely in
charge of the hard parts.  ;-}  And I'm really glad you like the
suggestion.  I only wish I had been more concrete about it earlier; it
might have saved us both some effort.

					-- Bob Rogers
					   http://rgrjr.dyndns.org/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf