Re: delete-selection-mode as default

[hw <hw@adminart.net>]

Eli Zaretskii <eliz@gnu.org> writes:

> [...]
> The region is currently used for 3 purposes: navigation, invoking
> commands on a region of text, and delete-selection-mode.

You don't need a region for commands to work on, a selection is enough.

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.

> (If someone thinks that delete-selection-mode is a variant of
> "invoking commands on a region of text", they are mistaken, and this
> long discussion is one proof of that mistake.)

That's why I said it's misguided in that it is an entirely different
idea.

> It should be clear from this discussion that there are fundamental
> tensions between these 3 purposes.  The first two can be reconciled by
> using the "active" vs "inactive" region, something we already have.
> This distinction is needed because an Emacs buffer will almost always
> have a region, and therefore users need some knob to control whether a
> command should act on the region or on the entire buffer.  (It is
> possible that we need some new command to "activate" the region,
> because the current method are IMO unsatisfactory: they require
> navigation, which is totally gratuitous.)

Just use a selection for commands to work on?  There's no need to
particularly activate a selected part of a buffer; it's kinda what a
selection is for.  A region is not needed here, either.

> The third use of the region, the one needed for delete-selection-mode,
> is IMO impossible to reconcile with the other two.

I'll leave that aside because it's an entirely different idea which may
be served with its own independent implementation.  For such an
implementation, a region is not needed.  Perhaps it could be implemented
as an optional feature of selections.

> Instead of trying to reconcile them with some trick, we should
> consider introducing a new "state" of the region,

You mean like a selection? :)  Those do not require regions.

> which will be activated by a special command,

Since a region is obsolete, we could simply use C-spc to start making a
selection and another C-spc to finish it.

> or could be optionally activated by "C-x C-x" etc., given some
> optional setting.

That is for navigation.

A region is not needed for navigation between two points.  You only need
the two points, in this case, called mark and point.  Just decouple them
from selections.

Once decoupled, there could be a command to turn the "region" that can
be imagined between mark and point into a selection.  There is no need
for a region here, either.

> IOW, let the users "arm" the region for delete-selection type of
> commands, similarly to how they currently "activate" it for the other
> purpose.  Then the user could decide what exactly they want the region
> to provide, and the basic conundrum is gone.

Users preferring d-s-m could enable the deletion option of selections.
Then if they want to delete a selection, they can make one and overwrite
it.  This doesn't need to be complicated.

>> With transient-mark-mode being the Emacs default, I’m inclined to
>> consider it a bug that certain commands act on the inactive region
>> when t-m-m is enabled, and possibly a flaw that (interactive "r")
>> makes it so easy to define such commands.
>
> It's not a bug, it's a feature: commands that make no sense without
> the region, like "upcase-region", should not need me to activate the
> region for them to do what I expect them.

What when they implicitly and secretly activate something you wanted
deactivated and do something you didn't expect?

When a selection is required for a command that does something with a
selection, the command can not work when there is no selection, and it
is a bug when it does so nonetheless, like through Emacs assuming there
was a selection when there actually is none (because Emacs lacks the
ability to distinguish if something is selected or not because its
insistence on obsolete regions gets in the way).

It's a clash between transient-mark-mode enabled and disabled.  In one
case, the behaviour is a bug because the mode suggests that commands
doing something must not do it with regions but with selections (active
regions); in the other, it's fine because there is always something for
commands that do something with something to do what they do because
there's always a region, and the second case implies that it is
generally fine for software to make mistakes of the users worse rather
than protecting them from them.

Actually, the second case is merely a slip-up, like driving your car
into the wall at full throttle and no seat belts on, either just because
you can, or unintentionally.  For some reason, only with
transient-mark-mode enabled, this becomes obvious because it has been
overlooked at least for the unintentional variant.  It probably was
never wanted even without transient-mark-mode, i. e. the intentional
variant.

Or why would I want something like upcase-region to suddenly mess up
random parts of a buffer?  A region is not a selection, it's only a
random part of the buffer that has somehow gotten between mark and
point, perhaps when mark and point were used for navigation, or when I
moved around, or when the mark happened to be set somewhere last time I
yanked something, or when the cat stepped over the keyboard while I was
pressing Ctrl or when it hit the cursor keys ...

> Other commands, which make sense both when there is and there isn't a
> region, need an indication of what the user wants them to do, and
> whether the region is active is that indication.

The indication is whether there is a selection or not.  Isn't that the
idea behind transient-mark-mode, an idea that made this mode so
successful that it became the default?

When you do not want to limit a command to a region, you do not need a
region, and the region is not needed here.

When you want to limit or to extend a command, you can use a selection
to limit or extend it to, and you don't need a region, either.

> The problem is that we now want to introduce yet another, 3rd meaning
> of the region, which is not identical to either of the other two.

The problem is the region.  It's not needed for anything and keeps
getting in the way.