mark@cogent.UUCP (Captain Neptune) (08/04/87)
Lots of discussion goes on here regarding the problem of "XYZ" terminal that has some arrow keys or function keys that need to somehow be made useful under uEmacs. I have the same concerns. I like uEmacs a lot, but it's limited use of termcap (or terminfo depending on who you are) leaves keyboard definitions out of the picture. I do NOT like stretching fingers for ^P and ^N to go up and down. I have arrow keys for crying out loud! Well...several postings have shown this hack and that hack which let me get a few extra keys in via some funny bindings. I'll probably use one of the suggested hacks for now, but I'll feel uneasy having non-standard source code, and the hack will probably not be too elegant, and it most certainly will not cover all (or even most!) of the possibilities. To this end, I would like to see some discussion instigated regarding how uEmacs could be revised to support a greater variety of keyboard scenarios. An ideal arrangement would allow functions within termcap/terminfo to be detected (e.g. uEmacs says "Ahah! This is a 'kf1', which is 'terminfo' for function key 1!") and translated via a user-defined table (in a file) to some key binding (e.g. the 'kf1' is translated to M-Q, so Func.Key 1 adjusts paragraphs). This table could also allow a raw string to take the place of a termcap/terminfo item, so that oddball keys could be put to use, even if termcap/terminfo doesn't know about those keys (this would be a much more portable way to handle all those extra keys on a UnixPC without the end user having to hack the code and have a one-of-a-kind version of uEmacs. In summary, here's what such a file might look like: (field 1 = capability of raw string from kbd, field 2 = key binding to xlat into, field 3 = comment) kf1:M-Q: f1 = format paragraph kf2:^S: f2 = search kf3:^X-^S: f3 = save kf4:^X-^C: f4 = exit \033]A:^P: our unique UP arrow key \033]B:^N: our unique DOWN arrow key \033]C:^F: our unique FORWARD arrow key \033]D:^B: our unique BACKWARD arrow key Would this not be reasonably portable, yet allow the end user to set themselves up as needed? Probably a terminfo vs. termcap flag would be needed to decide, for example, whether 'kf1' or 'k1' should be used. It's just a rough idea for starters. I don't claim that it's the ultimate answer, but I hope it will stimulate discussions which would encourage the inclusion of such a feature in future versions. -- +----------------------------------------------------------------------------+ | Mark Steven Jeghers: the terrorist smuggling CIA weapons to Libya | | | | {ihnp4,cbosgd,lll-lcc,lll-crg}|{dual,ptsfa}!cogent!mark | | | | Standard Disclaimer: Contents may have settled during shipment. | +----------------------------------------------------------------------------+
josh@mit-vax.LCS.MIT.EDU (Joshua Marantz) (08/04/87)
Posting-Front-End: GNU Emacs 18.33.1 of Tue Dec 16 1986 on mit-vax (berkeley-unix) Gosling EMACS (and possibly GNU Emacs) had what I consider a cleaner solution, though it didn't use termcap or terminfo. The form of the bind command is: (bind-to-key "function-name" "character-sequence") If "character-sequence" is more than one character long, the first character gets bound to an "auto-generated" keymap, and the second character is the binding within the auto-generated keymap. This recursion can go on indefinitely, allowing for the binding of arbitrarily long escape sequences. For example: (bind-to-key "forward-character" "\^F") (bind-to-key "forward-word" "\ef") (bind-to-key "forward-character" "\e[C") (bind-to-key "backward-character" "\e[D") Would cause the following binding state to exist: Global Map: Control-F --> function "forward-character" Global Map: Escape --> keymap "auto-keymap-1" Auto-keymap-1: f --> function "forward-word" Auto-keymap-1: [ --> keymap "auto-keymap-2" Auto-keymap-2: C --> function "forward-character" Auto-keymap-2: D --> function "backward-character" To avoid "auto-keymap-*", you can first do (define-keymap "ESC-map") (bind-to-key "ESC-map" "\e") (define-keymap "ANSI-prefix-map") (bind-to-key "ANSI-prefix-map" "\e[") This is a good approach because no keyboard information has to be hardwired into the editor. You have to evaluate the tradeoff of whether you want to take advantage of the Unix terminfo/termcap facility, which may not have all you need, and probably won't be supported on other platforms. I vote for the portable, flexible approach described here. -Joshua Marantz Emacs Enthusiast