Re: delete-selection-mode as default

[Eli Zaretskii]

> Date: Sat, 15 Sep 2018 10:20:16 +0000
> Cc: Drew Adams <address@hidden>, address@hidden, address@hidden,
>   address@hidden, address@hidden, address@hidden,
>   address@hidden, address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> I can't help feeling that this isn't the right approach.  I feel that it
> will increase complexity which the new features won't justify.  I know
> I'm speaking as an "extremist" (i.e. no transient-mark-mode at all) here,
> but still: I think having to press a key sequence before d-s-m would work
> would take the purpose of d-s-m away - that key sequence might as well be
> C-w.

People who want delete-selection-mode enabled by default won't need to
type that additional key, because for them the region will already
have the correct state.  delete-selection-mode will take care of that.

It is those who do NO want delete-selection-mode turned on by default,
people like you and me, who will be ABLE to use delete-selection-mode
by typing an extra key.  Those users will also be capable of
"activating" and "deactivating" the region like transient-mark-mode
does with a single command, thus allowing them to invoke commands that
act on an "active" region without turning on transient-mark-mode
globally.

> You seem to be proposing to associate a three-value state with the
> region, which state users could change with key sequences.  I can see
> this being more confusing than the current two-value state (or is it
> 2.5?) we currently have.

It cannot be more confusing, because for those who already turn on
transient-mark-mode and/or delete-selection-mode it leaves the matters
exactly like they are.  It actually should _improve_ on that by
letting those users temporarily turn on/off those modes for the
purposes of processing a given region by one or more commands.

> It might well be that, having introduced transient-mark-mode as a
> default, a certain degree of confusion in Emacs is unavoidable.  If so,
> does it make sense to spend a lot of effort which might merely switch the
> confusion to somewhere else?  Assuming that we'd want to have options to
> retain all the "old" behaviour, I think it would be difficult to avoid
> increasing the confusion.

I hope you will now reconsider this remark.

> I've interacted somewhat with hw, who's been driving this thread, and
> come to the conclusion that he doesn't really want to use Emacs.

That's irrelevant for the purposes of my proposal.  I do want to use
Emacs, and so I hope do you.