Re: delete-selection-mode as default

[hw]

Eli Zaretskii <address@hidden> writes:

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

What are these fundamental reasons?  Other programs, like joe, allow you
to use the selection for navigation without having a region.

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

Not to me.  The selection is what becomes highlighted when I make one.

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

I never use that, why would I?

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

Do you mean the one that solves some problems with delete-selection-mode
by "arming" the region instead of activating it?  I'd rather call it
"disarming" because disarming before killing makes more sense than
arming before killing :)

IIUC, your idea is to *generally* either "activate" a region or to
"disarm" it, depending on which behaviour a user wants.  I'm not sure
how this is different from delete-selection-mode, and I think it needs
more variations:

By setting mark-even-if-inactive to nil, I have "fortified" the region
because nothing can be done with it unless it is "active".

There are more variations, like disabling shift-selection and disabling
making a selection with the trackball.  That might make the region
"protected".  When it's also fortified, it would be "inert", unless it
has been disarmed, in which case it would be "content".

We'd have to find more funny names to designate all possible
combinations of the fundamental variations.  That would be the chance to
throw out "active" and to replace it with "limiting".  Then we could
also have "highlightable", but that kinda throws out the concept of "the
region" because we do not want the region to be highlighted all the
time.  Perhaps it could still be highlighted from starting to make the
selection until something has been done with it when "highlightable" is
desired.

I would also want "marked", meaning that the mark is displayed.

I like the idea because having a domain of fundamental region states
that can be combined with each other can lead to more consistency, and
the whole domain could be explained to users so they can get the
behaviour they prefer by picking any combination of states.  Currently,
all the modes and options involved appear to be unrelated, and users may
never find what suits them best because they don't know all the
available options.  Bringing them together in one domain would change
that.

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

They actually *are* two different things for me.  The selection is what
I make to work with and what becomes highlighted.  The region is
something unwanted always lurking in the background waiting for me to
make a mistake and making me feel uneasy.

The problem is that Emacs is unable to make this important distinction.
I could say that this confuses things.

However, with mark-even-if-inactive set to nil, this lurking daemon has
kinda been banished because it can only lurk and not do anything.

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

That's the problem ...

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

It is different because the end of the region is also being marked and
becomes independent from point.  Using the same key binding is only
intended to make it easy.

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

Navigating a buffer and making selections are two totally unrelated
things.  It doesn't make sense that the region be "navigating"
(especially when it is not "active").

I might understand limiting navigation to the active region when
transient-mark-mode is enabled --- but this doesn't come up because
unfortunately, point can not be disentangled from the region.

Besides, if a region was large enough that I would want to navigate it,
I probably wouldn't want it highlighted.  That would require "fortified"
to be independent of "highlightable", which is currently not possible.

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

That's the problem ...

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

Do you mean there is a big problem with delete-selection-mode when
transient-mark-mode is disabled because then there is "maybe sometimes"
a selection a user may want to replace by inserting characters?

This problem wouldn't exist if the region could be disentangled from
making selections.  I'm not sure if it does exist because nobody would
use d-s-m without t-m-m unless they wanted to do something that doesn't
make sense.

Other than that, Emacs would have to read the users` minds to figure out
what they want with each character they insert.

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

Upcase-region works without activating the region first though
transient-mark-mode says that commands should be limited to the "active"
region.  So for upcase-region to work when no region is "active", it is
as if the region is secretly activated so that upcase-region can work,
and this may be unexpected.

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

That's a difficult thing because it creates inconsistencies.  In this
case, one problem is that the region is changing all the time through
inserting characters (or files) and through navigation.  That is
actually always the problem, plus you can't even see the region and not
even the mark.

So MOTT, you have a region (which you call selection) that is entirely
random, unlike a selection which has explicitly been made to contain
what it is supposed to contain.  You really can't call the region a
selection.  Nothing in particular has been selected, and things merely
happen to have ended up the way they did and, because of technical
limitations, a region is randomly formed.

Now you have a mode the purpose of which is to limit commands to a
region that has been made active.  To make a region active, you have to
select it, so you're actually making a selection.  This mode is already
inconsistent because it allows commands to do things with a region even
when there is no active region, so these commands may do random things
because the region is a random thing.

You take that even further by having commands that imply doing something
only with a region.  Why would you expect a user who is working in a
mode that limits commands doing things with a region to doing them with
a selection to want to use commands implying they do something with a
region?  Why would you expect this user who wants to work with
selections rather than with regions to want to work with regions
instead?

At least there needs to be a replacement for upcase-region and the like
that work with the selection.  In case of upcase-region, it could be
called upcase.  That would bring more consistency.


BTW, upcase-dwim is flawed because it *extends* to the active region
*if* the region contains more than one word.  That contradicts
transient-mark-mode and requires another state besides "limiting":
"extending".  However, upcase-dwim is also limited to the active region,
so "limiting" together with "extending" can become a problem for region
states because it becomes unclear again what exactly is desired.

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

The two cases are the different results of the different behaviours
caused by transient-mark-mode either enabled or disabled, as
described. The same behaviour can be a bug or a design flaw, depending
on t-m-m. That refers to operations that imply doing something with a
region, like downcase-region.

The design flaw was probably never intended.

>> Or why would I want something like upcase-region to suddenly mess up
>> random parts of a buffer?
>
> Only they aren't random.

They are as random as the region, and the region is entirely 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.

That's the problem ...

> If you want Emacs to do something with text in the region, you will
> redefine the region before invoking the command

I always do that.  That's "making a selection", and it's the selection I
work with, not the region.  The only time the region is not random is
when it is a(n active) selection.

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

I work with selections, not with regions.  I can't even see the region.
Before I yank text, the selection is gone because it goes away when
copying.

> This is exactly why region and its integration with commands in Emacs
> is a very valuable feature.

How is this inflexibility a 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.

No, there is a big difference between a selection and a highlighted
region.

>> The problem is the region.  It's not needed for anything and keeps
>> getting in the way.
>
> Not in Emacs, it isn't.

It is *the* problem.