Martin Buchholz <martin(a)xemacs.org> writes:
> The current implementation may not be perfect, but we have to try to
> achieve this goal. Perhaps you would like to help?
I'd love to help. My suggestion is, as I've said, to return to 20.4's
behavior, because It Just Worked, and the goal (from my perspective,
where keymaps are currently broken) was already achieved. This would
also require that the default setting of delete-key-deletes-forward be
made nil again.
Barring that, a configurable setting whereby one could choose the
internal keysym to be generated when an actual \177 is hit in tty mode
would be a godsend. I thought this is what keyboard-translate would
be good for (I hadn't had to look at keyboard-translate-table since I
did a Dvorak-ish thing for Emacs18), but as I said last time around, I
haven't been able to convince keyboard-translate to do anything useful
for me; suggestions most welcome. If hackery beyond k-t is needed to
accomplish this bit of configurability, I'll tackle it, if someone
will just point me to where the relevant code is, as I haven't been
inside Emacs in years, and XEmacs never.
I find myself wondering how many keymaps would have to be examined, in
order to hunt down all the <delete> entries, in order to duplicate
them into <backspace> entries. Doesn't this need for duplication,
imposed out of a desire for a sense of keymap purity, seem a bit over
the top to anyone but me?
I have to admit that I am afraid that the intended, stated goal...
> deletes backward (never enters help!) when hitting the key labelled
> backspace, and deletes forward when hitting the key labelled delete.
...is inherently an impossibility as long as "help" lives on
`C-h', because that takes the needed binding out of availability
entirely: The fact that some delete-ish, backspace-ish key will
generate `C-h' in an xterm makes the "never enters help!" goal flatly
unattainable -- one had best give up on that fantasy right away.