Re: delete-selection-mode as default

[Eli Zaretskii]

> From: hw <address@hidden>
> Cc: Yuri Khan <address@hidden>,  address@hidden,  address@hidden,  
> address@hidden,  address@hidden,  address@hidden,  address@hidden,  
> address@hidden
> Date: Sun, 16 Sep 2018 00:37:43 +0200
> 
> Eli Zaretskii <address@hidden> 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.

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.

> > (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's a very similar idea, see below.

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

Once again: in Emacs, selection _is_ the region, and for some very
good reasons.

You can, of course, start inventing an Emacs that is based on
selections.  But if that Emacs will still support copy/paste inside
Emacs and vis-a-vis other apps, if it will support commands that
operate on the selected text and/or work different when some text is
selected -- then what you will have at the end is the same Emacs, just
one where the region is called "selection".  OK, maybe you will lose
the ability to do "C-x C-x" for navigation -- but to what purpose?

It should be possible to introduce a separate feature of "selection",
similar to what we already do with secondary-selection.  But if you
want commands and features to be sensitive to such a selection, you
will have to write a lot of code and change a lot of commands.  You
are, of course, welcome to work on that, but my idea was to try a much
simpler solution, one that doesn't need any significant changes in the
infrastructure or the implementation of the relevant commands.

If you do NOT entertain the possibility of introducing such a new kind
of "selections", then it is IMO best to remember that in Emacs
"selection" and 'region" are synonyms.  By using these terms as if
they were 2 different features you are just confusing this discussion.

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

Region and selection is the same thing in Emacs.

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

How is that different from typing C-SPC to start a region? it isn't.

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

No, it's also for "activating" the region (a.k.a. "selection"), which
causes some commands to "sense" the selected text.

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

You can't: selection in Emacs is the region.

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

You are missing the point.  The point is that sometimes the user
doesn't want a selection to be replaced by a character she types, and
other times she does.  The issue at hand is how to design a UI that
will allow both possibilities, without telling the users to turn on or
off delete-selection-mode for that purpose.

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

"Parse error".  Sorry, I don't understand what you meant here.

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

This flies in the face of a long tradition in Emacs to provide DWIMish
operation, whereby if something makes a lot of sense in some
specialized situation, Emacs should do that automatically, even if it
deviates from the "normal" operation.  A notable example is what C-t
does when point is at end of line.

So if some effect of a command would make sense when it is invoked
without any "selection", we program Emacs to do that, and that is not
a bug at all, it's why Emacs shines in many situations where other
editors don't.

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

"Parse error".  "One case"? "second case"?  What is this about?

> Or why would I want something like upcase-region to suddenly mess up
> random parts of a buffer?

Only they aren't random.

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

The region _is_ selection in Emacs.  If you want Emacs to do something
with text in the region, you will redefine the region before invoking
the command -- unless you know the region is already set up as you
want it, e.g. because you have just yanked the text to which you want
to apply the command.  This is exactly why region and its integration
with commands in Emacs is a very valuable feature.

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

Same thing.

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

Not in Emacs, it isn't.