SL> My argument against is simple. The failure mode is catastrophic SL> in exactly the same way that we wanted to fix when we first got SL> into this. There are keyboards in the mule lab that XEmacs is SL> completely clueless to deal with[1]. With them, the big key SL> labeled "Delete" stops deleting backwards and in order to get a SL> delete backwards requires a shifted keystroke. What bugs me most about this argument is that Steve describes as `catastrophic' a situation where a user would have to use a modifier key (e.g. `Fn') to delete backwards, yet... a user who currently might want to delete forwards currently must ALWAYS use a modifier key, i.e. Ctrl+D. How exactly is this different? The number of keyboards where xemacs guesses wrong is very small. Steve's argument that xemacs should NEVER guess wrong is bogus, since there is no way we can ever control the labels actually physically inscribed on the keyboard keys by the manufacturer, or vendor mods to Xlib or the xmodmap setup. It is unfortunate that some versions of Linux start up with the keys labelled BackSpace and Delete both xmodmapped to the Delete keysym, although xemacs deals reasonably well with this situation by making the Delete keysym delete backwards in this case. Steve has suggested in personal communication[1] measuring the usage of Delete vs Backspace by users on xemacs-beta. I reject this suggestion, since: - the backspace/delete change is aimed at the novice users, not xemacs-beta denizens. - those folks willing to send in a usage report of their own keystrokes would hardly be a representative sample. Some (most?) would have an axe to grind[2]. - Even if the BackSpace key is used orders of magnitude more than the Delete key (I'll admit it *is* used more commonly - I don't know how much), it is still important that it does what the novice user would expect if he does use it. I use the `=' key much more rarely than the BackSpace key, yet I would be quite upset to lose it. An additional user interface argument for the Delete key deleting forwards is the fact that although (point) is really between characters, the visible indication of (point) is a modification of the *following* character[3]. So a novice user who wants to delete a single character would `select' it by making the cursor cover it, then pressing Delete. It is far less intuitive to delete a character by `select'ing the *following* character and then backspacing, although it is equally easy in some sense. Users expect to process data in the same order that they input it, so forward-deletion while holding down the Delete key is a very natural operation. Footnotes: [1] I don't think he'll mind me mentioning this in this forum. My apologies if I'm wrong about that. [2] Yes, I've got a bigger one than the rest of you. [3] On a non-tty device, we should probably fix this so that (point) is more visibly betweeen characters. The thin bar-cursor was a flawed attempt to implement this earlier.