>>>> "Karl" == Karl Kleinpaste
Karl> Martin Buchholz <martin(a)xemacs.org> writes:
> The current implementation may not be perfect, but we have to try
> achieve this goal. Perhaps you would like to help?
Karl> I'd love to help. My suggestion is, as I've said, to return to
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:
/* ### 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.
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...
> deletes backward (never enters help!) when hitting the key
> backspace, and deletes forward when hitting the key labelled delete.
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
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.