bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11364: [debbugs-tracker] Processed: severity 11364 wishlist


From: Drew Adams
Subject: bug#11364: [debbugs-tracker] Processed: severity 11364 wishlist
Date: Thu, 12 Jul 2012 06:52:52 -0700

>> M-x delete-selection-mode ; turn it on
>> 
>> Double click a word, sexp, line, or what have you.  Or select 
>> the region some other way.  The point is to get an active region.
>> 
>> Use `left', `right', `up', or `down' cursor keys (or `C-f' 
>> etc. if you prefer). The region stays active and is extended
>> (or restricted).
>> 
>> This useful, standard Emacs feature was lost starting with 
>> Emacs 23.  Now, moving the cursor deactivates the region.
>> It should not, at least not in `delete-selection-mode'.
> 
> The behavior of Emacs 22 is an unintended and (AFAICT) undocumented
> consequence of the delete-selection-mode implementation---basically a
> bug, since it had nothing to do with deleting selections.  We might
> eventually re-implement this as an optional behavior, but 
> that would be a new feature (it will certainly not be the default
> behavior, since it is very non-standard for graphical applications).
> 
> So I do not regard this as a regression, or even a bug.  I'm 
> setting the severity to wishlist, because there are better things
> to work on.  Do not play with the severity---that will not increase
> the likelihood of this feature being implemented.

You are trying to rewrite history.  Simply stating something does not make it
true.

You claimed that this was NEVER the behavior in Emacs.  Now you admit OK, it
existed in Emacs 22, but that was just a fluke, not intended.  On what basis do
you claim that?

None given, except that there was no specific mention of this in the doc.  The
doc for `delete-selection' mode is minimal.  Have you found anything in the doc
that says that this behavior was NOT intended?

People have been using `delete-selection-mode' for decades.  Do you have ANY
evidence that anyone thought that the way it behaved in this regard was a BUG?
Quite the contrary - users have been taking advantage of this useful feature.
And a bug was filed when you broke it.

In fact, this has been the behavior not just in Emacs 22 but in ALL prior Emacs
versions as well (since `delete-selection-mode' was added).  And there is zero
evidence that this behavior was in any way a mistake, bug, or unintended.  You
give no argument to support your claims.

You play on words, saying that because the traditional behavior "had nothing to
do with deleting selections" it was a bug.  Shame.  Delete-selection mode is not
and has never been only about "deleting selections".

Do you even use `delete-selection-mode'?  I'd guess not, since you had no idea
that you broke this feature.  Did you take a poll of users of
`delete-selection-mode' before breaking it?  Or before retroactively deciding
now that its behavior was a bug that was happily "fixed" by your change that
unknowingly broke it?

Delete-selection mode is not, and was never intended to be, limited to what
might be "standard for graphical applications", any more than the Emacs mouse
was intended to be limited to what is "standard for graphical applications".  

Emacs has always felt free to offer more (or less) than what might currently be
"standard" elsewhere.  The aim has never been to limit Emacs to what is
"standard for graphical applications".  Richard has been very clear about this
from the beginning.  We use standards when, and to the degree that, they are
appropriate for Emacs; they do not use us.

Not to mention that similar behavior is and has always been _standard for Emacs_
in its keyboard handling of the region.  You can still set mark and
extend/restrict the active region by hitting cursor keys, thank goodness.  At
least you broke this Emacs standard behavior only for the case where the region
was made active by the mouse, in delete-selection mode.

Wrt your reclassification: The definition given by GNU for "wishlist" severity
is this:

  "for any feature request, and also for any bugs that are very
   difficult to fix due to major design considerations"

This is not a feature request, no matter what word games you play.  It is a
request to restore the traditional behavior, which you inadvertently broke.

Inadvertently?  Yes, since by your own admission you had no idea that you broke
it.  You even claimed that the traditional behavior never existed.

And you have made no argument that this is "very difficult to fix due to major
design considerations".

You are rewriting history, and apparently trying to redefine "wishlist" as well.
Shame.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]