Re: delete-selection-mode as default

[hw]

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: 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.

They could just work with the selection instead.

>> >> > 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.

Is the implementation relevant for the distinction?  The distinction
between a region and a selection exists regardless of the implementation
of each.

>> 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.

ok

>> 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.

The meaning of these states can vary through different behaviour
resulting from changes to variables like delete-active-region and
mark-even-if-inactive.  These changes go so far as to make for different
defaults on their own.

A command that glides through all possible combinations of states and/or
all possible defaults may have so many combinations to glide through that it
would be troublesome to use.  But if states/defaults could be stored in
registers, users could quickly switch between those relevant for them.

>> > 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.

What would be an example for this?

> 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.