Re: delete-selection-mode as default

[Eli Zaretskii]

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

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

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

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

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

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

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

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

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

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

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

> > 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.  And in some case, the region is already conveniently set to
what you might want to act upon.