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

Rick Campbell wrote: True enough. However, with delete-key-deletes-forward set to nil, both 'delete and 'backspace delete backwards. This is really just masking any delete/backspace confusion, which may not be the best thing, at least in a beta. I don't actually know how many people really want separate delete and backspace keys but want them both to delete backwards, or whether people just like not having to worry about delete and backspace being confused. [NB: I'm not suggesting that anyone does fall into the latter category, but that we here *should* be concerning ourselves with getting delete and backspace correct to start with. For a very long time, anything that vaguely resembled deletion was lumped together into one big Gordian Knot which has taken much time and effort to untangle.] If there are a substantial number of people in the former category, then we need to seriously consider what the default should be, possibly by conducting a poll. I know that having delete-key-deletes-forward set to nil gives the traditional behaviour, but if a substantial majority of the userbase were to prefer the `Windows-style' behaviour, then I would argue that the time has come for tradition to give way. People who use Backspace to delete backwards and C-d to delete forwards shouldn't need to care what Delete does. If the problem is due to invalid configuration (either xmodmap or stty), then it isn't XEmacs' job to fix it (IMHO), even if it has always done so in the past. Except that having delete-key-deletes-forward set to t will demonstrate breakage, whereas setting it to t will hide it. All other thing being equal (I'm aware that this is an assumption, not a given), this favours t over nil. If the number of people who really want Delete (the real Delete, not Backspace masquerading as Delete) to delete backwards outweighs (or, in view of tradition, only marginally lags) the number who want it to delete forwards, then clearly nil should be the default for the release version at least. Having said that, I would guess that on MS-Windows there would be near unanimity in favour of it being t, so the choice is probably between either t or (eq window-system 'mswindows). -- Glynn Clements <glynn(a)sensei.co.uk&gt;