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

>> Other programs, like joe, allow you to use the selection for
>> navigation without having a region.
>
> Once again, in Emacs region _is_ the selection.
>
>> > 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.

For practical usage, how both are implemented can be relevant.

>> > 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?
>
> Others do.  Emacs caters to many different workflows, and it is fine
> not to have to use some of its features for which you don't have a
> need.  But we cannot remove them just because you personally don't use
> them, can we?

I'm not suggesting to remove them.

>> 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".
>
> These word plays just muddy the waters.

It is sometimes an advantage when you can give something a name because
the name can make it easier to understand and to remember.  For example,
"fortified" may be easier to remember than "state 00000101" or "state 5".

> The basic point is to have more than just 2 states of the region, and
> allow various features behave differently by being sensitive to the
> current state of the region.
>
>> 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.
>
> Good, so we agree.

I'm not sure, it seems to me that your idea is much different from how I
thought it was.

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.

>> 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.
>
> Because in Emacs, selection _is_ the region.  Adding a state property
> could allow us to make the distinction nonetheless.

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

>> Navigating a buffer and making selections are two totally unrelated
>> things.
>
> No, they are closely related, because in general you need to navigate
> to a place to mark it as beginning/ending a selection.

There are many other reasons to navigate than making selections.  Having
to go somewhere to make one is a special case and might not even fall
under navigation because you can have navigated close to where you then
make a selection.  That means you're already there for other reasons and
just need to move a little.  There is a distinction between navigating
and making a selection.

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

>> Other than that, Emacs would have to read the users` minds to figure out
>> what they want with each character they insert.
>
> See above: I believe we can let the users speak their minds so that
> Emacs doesn't need to read them.

The amount of key bindings users are willing to learn and the number of
defaults they are willing to change or to work around may be limited.

>> 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.
>
> What do you want upcase-region to do when there's no active region,
> then?  Doing nothing or signaling an error would go against Emacs's
> tradition of DWIM-ish operation.

The equivalent of not having a region when `transient-mark-mode' is
disabled is not having an active region when `transient-mark-mode' is
enabled.  When `upcase-region' is called while the mark is nil, Emacs
signals an error.  Hence, when `transient-mark-mode' is enabled and the
region is not active, `upcase-region' should signal an error.

With transient-mark-mode enabled, the default should be
mark-even-if-inactive set to nil.  That would be more consistent: with
this, Emacs signals an error when `upcase-region' is called while the
region is not active.

It's quite the enhancement `transient-mark-mode' can provide: it allows
to actually fortify the region against accidental use.  How can that be
done when `transient-mark-mode' is disabled?


Maybe you could consider this as an example for the "state idea" because
it comes down to what the user wants.  It's a default the user does not
need to and will not want to work around, though.

>> > 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.
>
> If what Emacs does is what the user would expect, what makes sense,
> then the inconsistencies don't matter.

When the user starts thinking about things, they can suddenly start to
matter.  Upcase-region and mark-even-if-inactive non-nil by default is a
good example.

>> >> 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.
>
> I disagree.  IME, it is never random when I want to act on it.

When you want to act on it, you have probably taken care so that it
isn't random before you act.  How is that different from making a
selection to do something with before doing it?

I'm assuming you don't want to do something with random parts of a
buffer, and you seem to have confirmed that.

>> > 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.
>
> Which always happens before you invoke a command that works on a
> region.

The selection I want to do something with doesn't form itself because it
somehow just so happens.

> And in some case, the region is already conveniently set to what you
> might want to act upon.

And I don't know when this happens because there is no indication of it.
I might see it if the mark was visible and/or if point were to show the
imaginary tail.

I wouldn't mind writing something for it, but I have no idea where to
start.