Karl> Martin Buchholz <martin(a)xemacs.org&gt; writes: Karl> Jesus. And I thought RMS had an attitude the size of Montana. Excuse me? There are many things about the default behavior of XEmacs that I don't like, and those things require effort on my part to customize. The other maintainers of XEmacs do the same thing. I think only rms himself uses Emacs in its raw hostile uncustomized state. Karl> You're entitled to any opinion you wish to hold, and I'm entitled to Karl> mine, but let's just make it bloody damn clear that it is *you* who Karl> are farting around with default behavior that has existed in Emacs for Karl> something like 15 years, all in the name of pseudo-"progress" embodied Karl> by the Keymap Purity Hit Squad. Absolutely. Farting around is what we do here in Free Software Land. Note that although I am strongly in favor of this change, I did not implement it. Many others have toiled for years to make the *new* behavior a reality, so I am certainly not alone. A totally fart-free version of Emacs is available at: ftp://prep.ai.mit.edu/pub/gnu/emacs-18.59.tar.gz (In particular, the above is free of any code written by myself. FSF Emacs 20.3 is not. Perhaps surprisingly, my first contribution to Emacs was to improve the handling of terminfo/termcap entries.) Karl> This really takes the cake. Karl> Spare me the crap -- I'm not lying to anything or anybody. I'm using Karl> the advertised features of the supplied program, precisely in the Karl> manner in which they are intended to be used -- I'm using the Karl> configurability of xterm to make my life easier, by changing its Karl> standardized behavior to something more personally palatable. Gee, Karl> howzabout that. If I then have to fart around with *XEmacs'* new Karl> misconceptions of standardized behavior to get corrected personalized Karl> behavior, am I "lying" to XEmacs? Karl> Of course not. What semantic nonsense. Of course not NOT. The sequences sent by keys on the keyboard are supposed to match the entries in the terminfo entry. If they don't, the application can't be expected to recognize them. If you change one without the other, then you should not be disappointed if your applications cannot recognize your function keys. This is why there's a -tn option to xterm, because `xterm' is not always the correct description of how a customized xterm behaves: -tn name TERM environment variable name Karl> This doesn't mean squat, because the problem is not casual use of Karl> forward and backward deletion, but rather complex keymaps which depend Karl> *specifically* on the availability of a DEL keysym. When I press the key labelled "Del" I get a DEL keysym. I agree with you that there is work left to be done here. Karl> Talk about "changing the subject," sheesh, the subject is those Karl> complex keymaps and their current failure modes. Nonetheless, let Karl> me tip my hat with considerable thanx to Kyle for pointing me to the Karl> correct incantation needed to eliminate the entirety of the Karl> misinterpretation of \177 as BS, using (setq tty-erase-char nil). Martin "Old Fart" Buchholz

From: Karl Kleinpaste <karl(a)justresearch.com&gt; Date: 03 Jan 1999 15:57:56 -0500 Martin Buchholz <martin(a)xemacs.org&gt; writes: Jesus. And I thought RMS had an attitude the size of Montana. You're entitled to any opinion you wish to hold, and I'm entitled to mine, but let's just make it bloody damn clear that it is *you* who are farting around with default behavior that has existed in Emacs for something like 15 years, all in the name of pseudo-"progress" embodied by the Keymap Purity Hit Squad. Amen. And, for what it's worth, it's more than 15 years. I'm pretty sure you could claim 20 without a problem although I can only vouch for about about 17 of them. Rick (Emacs geezer for 6334 days and counting :-)

Karl Kleinpaste wrote: Yep. Mainly because the upshot of that default behaviour has been to make `How do I get Delete and Backspace to work properly?' one of the most frequently asked questions on comp.emacs.xemacs (aka xemacs(a)xemacs.org). As it happens, the original reason why I subscribed to xemacs(a)xemacs.org a few years back was to ask that very question. The answer at that time was to use `(load-library "delbackspace")', which was basically a big kludge which did loads of stuff to various keymaps, and still only partially worked. I didn't particularly like this solution, questioned it, got flamed, still questioned it, tried to fix it, and discovered that some of the problems went far deeper than my understanding of XEmacs. The bulk of the actual fixing (which is present in 20.4) was done by Gary Foster, and involved systematically hunting down all of the places where backspace, delete, \177, C-h etc were being used (and often misused). As a result, the whole of delbackspace.el was obsoleted by the delete-key-deletes-forward variable, which generally seems to be considered an improvement. The problem which remained in 20.4 was that things were still less than perfect on a tty. If your <- key generated \177, then it was hardcoded to `delete', and thereafter became indistinguishable from the Delete key. You could always reconfigure things to use \010, but then you lose C-h. The changes to events.c involved a significant amount of (often heated) discussion, and certainly weren't made just because someone was bored, or because a few individuals didn't like a particular default setting. They were made primarily because the existing behaviour (which may have `existed in Emacs for something like 15 years') caused real problems for a significant number of people, and the problems couldn't be worked around by changing existing variables. The new behaviour should allow everyone to get the behaviour which they desire. As for the defaults: there is no setting which will please everyone. `Old timers' tend to have a quasi-religious belief that \010 is Backspace and \177 is Delete. Newcomers generally just want stuff to work right. AFAICT, the current behaviour of using whichever code corresponds to the erase character should satisfy everyone except those who have their erase character set incorrectly (and if you don't want the key which generates \177 to be treated as backspace, your erase character probably *shouldn't* be \177). Hardcoding \010 to backspace will annoy anyone whose backspace key generates \177. This seems to cover most current Linux distributions, which in turn probably accounts for more users than all other Unices combined. Furthermore, these users tend to be at the novice end of the scale when it comes to understanding such arcane concepts as character terminals. -- Glynn Clements <glynn(a)sensei.co.uk&gt;

From: Glynn Clements <glynn(a)sensei.co.uk&gt; Date: Thu, 7 Jan 1999 15:23:16 +0000 (GMT) `Old timers' tend to have a quasi-religious belief that \010 is Backspace and \177 is Delete. Newcomers generally just want stuff to work right. Yeah, old timers hate it when things work right :-) Seriously though, I have it working right. A new cleaner implementation of all of this sounds like a great idea . . . unless you're talking about changing the default behavior, i. e. breaking stuff for folks that already have things working right. For me personally, I don't need anything other than Control-D to delete forward and even with all the fuckage that RMS introduced with making C-h the help character, the problem was never one of having the key on the top right accidentally deleting *forwards*. Not in emacs. Not unless you were already customizing to try to make something other than Control-d delete forward. By changing the default, you're introducing a completely new problem for your existing user base. Seriously, why *isn't* anyone arguing for pending-delete being the default. Is the argument any different at all? Rick

From: Glynn Clements <glynn(a)sensei.co.uk&gt; Date: Fri, 8 Jan 1999 09:12:35 +0000 (GMT) `Breaking stuff for folks that already have things working right' isn't the worst thing that can be done. It certainly shouldn't be done gratuitously, but I don't believe that this is the case here. . . . I agree with virtually everything in your message. However, your message doesn't seem to address that, if you don't change the defaults to having a non-Control-D-delete-forward-binding, you avoid a huge class of `Breaking stuff for folks that already have things working right', i. e. you can fix what's broke without fixing what ain't broke. Rick