Re: XEmacs 21 /vs./ my keyboard: I want my DEL back

Karl> Martin Buchholz <martin(a)xemacs.org&gt; writes: Karl> I'd love to help. My suggestion is, as I've said, to return to 20.4's Karl> behavior, because It Just Worked, and the goal (from my perspective, Karl> where keymaps are currently broken) was already achieved. This would Karl> also require that the default setting of delete-key-deletes-forward be Karl> made nil again. Karl> Barring that, a configurable setting whereby one could choose the Karl> internal keysym to be generated when an actual \177 is hit in tty mode Karl> would be a godsend. I thought this is what keyboard-translate would Karl> be good for (I hadn't had to look at keyboard-translate-table since I Karl> did a Dvorak-ish thing for Emacs18), but as I said last time around, I Karl> haven't been able to convince keyboard-translate to do anything useful Karl> for me; suggestions most welcome. If hackery beyond k-t is needed to Karl> accomplish this bit of configurability, I'll tackle it, if someone Karl> will just point me to where the relevant code is, as I haven't been Karl> inside Emacs in years, and XEmacs never. Certainly this is supposed to be user-configurable. This is XEmacs, after all. If not, that needs to be fixed. Hmm. Here's some code in sysdep.c: /* after all those years... */ con->tty_erase_char = make_char (tty.main.c_cc[VERASE]); and in console.c: #ifdef HAVE_TTY /* ### Should this somehow go to TTY data? How do we make it accessible from Lisp, then? */ DEFVAR_CONSOLE_LOCAL ("tty-erase-char", tty_erase_char /* The ERASE character as set by the user with stty. When this value cannot be determined or would be meaningless (on non-TTY consoles, for example), it is set to nil. */ ); #endif So some degree of configurability should be achievable by setting tty-erase-char, after the tty is created. But I should shut up now, since others have implemented this, and I don't really know what I'm talking about. Hrvoje? Karl> I find myself wondering how many keymaps would have to be examined, in Karl> order to hunt down all the <delete> entries, in order to duplicate Karl> them into <backspace> entries. Doesn't this need for duplication, Karl> imposed out of a desire for a sense of keymap purity, seem a bit over Karl> the top to anyone but me? A mode should probably examine delete-key-deletes forward to know what to do. Is there a better mechanism to allow user configurability? (Of course there is. But what is it?) Karl> I have to admit that I am afraid that the intended, stated goal... Karl> ...is inherently an impossibility as long as "help" lives on Karl> `C-h', because that takes the needed binding out of availability Karl> entirely: The fact that some delete-ish, backspace-ish key will Karl> generate `C-h' in an xterm makes the "never enters help!" goal flatly Karl> unattainable -- one had best give up on that fantasy right away. When help conflicts with deleting backwards, deletion has to win, since it is the more important operation, and f1 is available on almost all ttys for getting help. Martin