Please, do it. At least for windows. Fabrice

Ben Wing <ben(a)xemacs.org&gt; writes: Not only do I find Pending Delete preferable, I don't even understand the reason it should ever being turned off. What's the point of having an active selection if not to operate on it with the following editing commands? -- Steven E. Harris

Eric Eide <eeide(a)cs.utah.edu&gt; writes: Do you map a key for delete-region, then, or maybe use kill-region (mapped to C-w here) instead? Or perhaps I'm doing something wrong; I typically use a marked region to replace text, either deleting it or typing over it. With Pending Delete disabled, that region is ignored by C-d, which I use to remove almost anything from a buffer. Is there a better way? I do know about kill-word, kill-sentence, and friends, but they're more context-dependent than C-d. -- Steven E. Harris

[Note: Possibly useful suggestion at the end] On Tue, 01 Feb 2005, Steven E. Harris announced authoritatively: I despise pending-del and zmacs-regions both for the same reason: I use regions interchangeably as indications that something should be done to some hunk of text, and as navigation. I hit C-u C-SPC, C-x C-SPC and C-x C-x so often that I wore out the control and space keys on one keyboard doing it. I find it really annoying to have this great glaring thing pop up merely because I've navigated around. I have a hacked-up package under development (should be usable by sometime this weekend) that adds a classification, prioritization, and auto-dropping scheme which means you never even need to drop the mark, it drops itself for you, literally whenever you move the cursor (although it only hits the `real' mark ring if you move more than a screenful at once). This would be *disgusting* in conjuction with zmacs-regions, but it's really useful in conjunction with C-u C-SPC. But I entirely agree that the default should be changed: most people don't do what I do, and users can always change defaults. I can always flip the defaults back in auto-mark.el anyway. :) However, some menu item *must* identify changed defaults (not `recently changed': a history of all that were ever changed since we started tracking this sort of thing), because otherwise we're torpedoing those poor sods who do things like upgrade from 19.34 all the way to 21.x all at once. They've already got a hell of a shock coming: let's give them a transition plan. :) In fact, it seems easy enough to me to have a `defaults.el' package that keeps track of these things, so that an expert user who doesn't want any changing defaults to disturb him (like most of us) could say (defaults-as-at "2005-01-20") and the system snaps all its variables to the system-wide defaults as they were then. (Probably site maintainers would put this in site-start.el, to avoid shocking their users when they updated XEmacs.) It's easy to implement: we just teach the package about the old value of each default and the date we change it whenever we make the change. Probably we should do it in the place where the variable was declared, viz (defaults-changed-at "2005-02-03" 'pending-delete-mode nil) ;;;###autoload (defcustom pending-delete-mode t "Non-nil when Pending Delete mode is enabled. In Pending Delete mode, typed text replaces the selected region. Normally, you shouldn't modify this variable by hand, but use the function `pending-delete-mode' instead. However, you can customize the default value from the options menu (auto delete selection)." :type 'boolean :set (lambda (symbol value) (pending-delete-mode (or value 0))) :initialize 'custom-initialize-default :require 'pending-del :group 'keyboard) So then it becomes easy to remember: if you change a default, stick a call to `defaults-changed-at' and say what the default used to be and the current date. :) Downside: we'd probably need to provide a copy of defaults.el in the packages and require a package upgrade, or something like that, because this is something that both the packages and the core should really be using if it's to be of any use. With a package like that, we'd have total freedom to frob the defaults to make XEmacs more approachable for the average user, without disrupting the experts at all; they needn't even know the defaults have changed. (I'd say that the poor choice of defaults is undoubtedly XEmacs's largest problem...) I'll get writing `defaults.el' at once if anyone thinks it might get used. It's utterly trivial, really (little more than a fancy wrapper around `setq' and/or `custom-set-default'), and its benefits are too large to ignore. -- `Blish is clearly in love with language. Unfortunately, language dislikes him intensely.' --- Russ Allbery

On Thu, 3 Feb 2005, Aidan Kehoe stipulated: OK, I'll have a hack. It shouldn't be hard; the only vaguely nonportable bit is to set the `standard-value' property if it's already set, so that customize doesn't think the value has been changed from its default. The advantage of requiring the dates to be in that form is that I don't need to bother parsing them at all, I can just lexicographically sort :) If anyone would prefer RFC822 dates, please say; but since we're using ISO standard dates in the ChangeLog, I think we should use them here as well. Dates only for now, no times: so don't change the default for a single variable more than once per day if you're going to release more than once on that day as well ;) Hyperbole, sorry. Here, let me fix it: s/undoubtedly/doubtedly/:) -- `Blish is clearly in love with language. Unfortunately, language dislikes him intensely.' --- Russ Allbery

Ben> I'd like to get this resolved. I know that Mike Sperber doesn't like this, Ben> but I think we need to come to a vote. Well, you agreed to provide a file with stuff people can put into their .emacs to restore "historical" behavior. If this file is there, and it's prominently mentioned in NEWS, I won't object. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

Rafal Gazda <Rafal.Gazda(a)fuw.edu.pl&gt; writes: Hi Rafal, The current pre-released package version 1.46 (note, it's not 11.46, yet:-)) contains the sources of the upstream version 11.55. You can check this for yourself through M-x pui-list-packages. Go down to the auctex line and type 'i'. norbert.

Rafal Gazda <Rafal.Gazda(a)fuw.edu.pl&gt; writes: Hi! Yes, in the pre-release directory you only find packages since the last official release. norbert.