Re: delete-selection-mode as default

[Eli Zaretskii]

> From: hw <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden,  
> address@hidden,  address@hidden,  address@hidden,  address@hidden
> Date: Wed, 19 Sep 2018 04:26:45 +0200
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> From: hw <address@hidden>
> >> Cc: address@hidden, address@hidden, address@hidden,
> >> address@hidden, address@hidden, address@hidden,
> >> address@hidden, address@hidden
> >> Date: Tue, 18 Sep 2018 00:11:05 +0200
> >> 
> >> >> That would allow to decouple navigation from (making) selections, and
> >> >> the concept of a region becomes obsolete, removing all the entanglement
> >> >> and greatly simplifying things.
> >> >
> >> > You forget the kill-ring and the kill/yank commands.  Those are almost
> >> > exactly identical to what other apps give you with copy/paste, and the
> >> > latter use selections.  So the reasons Emacs implements selections
> >> > using the region are more fundamental than just navigation.
> >> 
> >> What are these fundamental reasons?
> >
> > They were just described above: the set of commands that copy/kill and
> > paste text.
> 
> I don't understand how being able to cut and paste selections becomes
> more fundamental than being able to navigate because all of those use
> the same fundamental concept.

It means if you lose the current meaning of the region, you also lose
the cut/copy/paste commands, and their history on the kill-ring.

> >> > Once again: in Emacs, selection _is_ the region, and for some very
> >> > good reasons.
> >> 
> >> Not to me.  The selection is what becomes highlighted when I make one.
> >
> > That's a minor detail in Emacs.  The underlying fundamental
> > functionality is the region.
> 
> The distinction between a (the) selection and a (the) region is
> important and not a minor detail.  For this distinction, it is pretty
> irrelevant how both are implemented.

This whole thread came to the existent because the underlying
implementation is NOT irrelevant.

> Do you mean the state to be general, like a default, or to be changed
> all the time depending on what a user wants and does?  I suppose there
> would have to be some kind of default, and if users needed to change it
> or to somehow work around it all the time, it wouldn't look like a good
> default to me.

That's the idea, but since the default should be OK most of the time,
the need to override it should be rare.

> You could consider transient-mark-mode as a state.  How would you deal
> with its variations, are they states on their own?

For transient-mark-mode, the states are active and inactive.  So a
command that toggles the state would be something I have in mind.

> > No, I mean delete-selection-mode changes the effects of some commands
> > in ways that could be very inconvenient in some situations, and
> > currently the only way for the user to deal with such conflicts is by
> > turning on or off delete-selection-mode.  There should be a better way
> > of temporarily enabling/disabling delete-selection-mode, similar to
> > what we have for transient-mark-mode.
> 
> What if the commands were automatically prevented from having
> inconvenient effects?

That'd be nice, but I don't believe there's a way to do that without
adversely affecting other important features.  Hence I propose to
place on the user the burden of preventing Emacs from having those
inconvenient effects, assuming that each user chooses their defaults
such that in most cases Emacs already does what the user expects.