emacs-devel
[Top][All Lists]
Advanced

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

RE: delete-selection-mode


From: Drew Adams
Subject: RE: delete-selection-mode
Date: Fri, 19 Mar 2010 12:01:16 -0700

> I wrote
> 
>     > Is this true even when the region has been activated by 
>     > keyboard commands? If so, perhaps it is a bug.  Perhaps
>     > the feature should only apply when
>     > you make the region using the mouse.
> 
> You replied
> 
>     I think it would be a very bad idea to introduce an 
>     invisible state this way. (I agree with Klaus here -
>     if I do not misunderstand him.)
> 
> This distinction already exists.  Now that I've been reminded of it, I
> recall why I implemented it.

"Why I implemented it" is almost always important info. Thanks. It would be
great if such info were recorded more often, preferably at the time of the
change.

> Making DEL delete the whole region after a mouse selection did not
> affect experienced Emacs users, who edit mainly with the keyboard.  So
> I saw no reason not to do this by default.
> 
> Making DEL delete the region whenever it is active would be an
> incompatible change for us, so I rejected it as a default.
> 
> Some have claimed here that such an "invisible" distinction would be
> intolerable, but let's check the facts.  Have there been any
> complaints about it?  Would someone like to check the bug tracker?
> 
> Extending the region-deletion behavior to cover self-insertion as well
> as DEL is a natural change.  Extending it to shift-arrow selection
> makes sense too.  These can increase effective compatibility because
> the whole editing scenario (select a region and then operate on it) is
> compatible between Emacs and the other relevant programs.
> 
> In addition, neither of those two changes will affect experiencd Emacs
> users.  There is no practical argument against those changes.
> 
> The case that could very well be painful to change is that of marking
> the region with the traditional Emacs editing commands.  In addition,
> that change would give no effective increase in compatibility with
> other programs, because these Emacs commands are totally incompatible
> with those programs.
> 
> We should not break most every user's editing habits for a partial
> compatibility which is too partial to be of real use.  Such a change
> could lead to a rebellion of the users.

All well reasoned and clearly explained, IMO.

I disagree that it's a great idea to have the mouse behavior be different
(special, inconsistent, incompatible - whatever word you like), but I recognize
your reasons and they are _good_ ones.

I agree that many veteran Emacs users would not be affected by what you describe
because they do not use the mouse (this way) anyway. I disagree that this means
all or even perhaps most Emacs veterans (dunno). I am one who uses both the
mouse (this way) and the keyboard. But I don't claim to represent the majority.

As long as we have some clean way to get a consistent behavior between mouse and
keyboard, I'm OK with our also providing an inconsistent mix such as you
describe. And yes, it could even be the default behavior.

I'd argue against it in general because consistency often means simplicity and
lack of surprise. I like my selection using the mouse to behave the same as my
selection using keys. And I think it helps learners when the behavior is
consistent that way. But consistency is not the only consideration, ever.

Thanks for presenting the mouse-behavior history clearly, and especially for
providing the rationale behind the design decisions. We could use more such
explanation when changes are made, IMO.

> However, there remains the question of whether enabling
> delete-selection-mode would really break our habits.  Will it really
> bother experienced users like me?
> 
> How about if we find out empirically.
> 
> I have enabled delete-selection-mode, and I will try editing with it.
> I'll see if it is a real pain or not.  I suggest that others also try
> turning it on.  Then we will know whether it is a real pain in the
> neck, rather than arguing theoretically that it is or isn't.

Bonne initiative.





reply via email to

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