Jan Vroonhof wrote: Martin Buchholz wrote: I disagree. Even if the use of help-char can be fixed (e.g. removed; IMHO it ought to be help-keysym), I still don't think that 'backspace or 'delete should have an 'ascii-character property. Certainly some keys do have obvious ASCII characters associated with them, but I'm not so sure that Backspace or Delete are amongst them. Whilst the historical associations are: C-h -> \010 Backspace -> \010 Delete -> \177 there does seem to be a growing trend towards C-h -> \010 Backspace -> \177 Delete -> \E[3~ for the obvious reason that C-h and Backspace can be distinguished. Having followed the BS/DEL discussions for some time now, It seems to me that making Backspace and Delete `equivalent' to certain ASCII codes in a global sense has caused nothing but problems, and my gut feeling is that this will continue to be the case. Consider the case where a TTY sends \177, which is translated to 'backspace (because tty-erase-char == \177), which is then translated to \010 (via the 'ascii-character property). I would argue that the only keysyms which should have an 'ascii-character property are those for which its definition is absolutely unambigous, e.g. so that converting ASCII -> keysym -> ASCII is a subfunction of the identity function (i.e. it either returns its argument or signals an error, but doesn't translate e.g. \177 -> \010). The only thing that broke when I removed the 'ascii-character properties from 'backspace and 'delete was eterm. I submitted a patch to xemacs-patches: Date: Fri, 29 May 1998 05:38:25 +0100 (BST) Message-ID: <13678.15297.242866.718608(a)cerise.sensei.co.uk&gt; to make the translations customisable. IMHO, if 'backspace or 'delete need to be translated to an ASCII code, then the translation should be performed explicitly by the particular package, rather than being implicitly translated to some value which is (to all intents and purposes) hardcoded. -- Glynn Clements <glynn(a)sensei.co.uk&gt;