Re: delete-selection-mode as default

[Eli Zaretskii]

> Date: Fri, 14 Sep 2018 13:57:59 -0700 (PDT)
> From: Drew Adams <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden, address@hidden,
>         address@hidden, address@hidden, address@hidden,
>         address@hidden
> 
> > > Users can trivially control which of the 5 behaviors to use for
> > > a given command, just by putting a property on the command
> > > symbol.
> > 
> > Putting properties on symbols to change the behavior of a command is
> > not user-level customization.  IOW, we are miscommunicating.
> 
> There are users, and there are users. I didn't say that users
> will do that in general. Far from it.
> 
> I don't know anyone who has ever bothered to set the d-s-m
> behavior for a particular command, unless it's a new command
> that they themselves created.

Fine, then we agree.  The above issue is not relevant to what I
perceive as the main problem here: how to give us a way to allow
turning on delete-selection-mode without alienating users who have no
use for it and very much dislike its effects, in particular when those
effects are unintended.

> I disagree that there is a problem with d-s-m, or with
> turning it on by default. You tout irreconcilability but give
> no example.

There are plenty of examples in this thread, I see no need to repeat
them.

> That users can be confused about the region etc. does not
> stem from d-s-m - please don't scapegoat it.
> 
> Confusion comes primarily from the introduction of
> t-m-m and, especially, the coupling, in C-x C-x, of region
> activation with swapping point and mark. There was no
> confusion before that. And no confusion was introduced
> by adding d-s-m.

I didn't "scapegoat" anything.  It is immaterial which of the 3 uses
of the region is "to blame", because this is not about assigning
blame.  My description was following the time line: the other 2 uses
of the region are already turned on by default, whereas
delete-selection-mode is not.  It doesn't mean delete-selection-mode
is somehow "guilty".

> But normally a given user just knows what s?he uses,
> and doesn't try to know about and understand every
> possibility regarding point, mark, region, selection,
> activation, highlighting, action, deletion, etc.

My point is that even users who know what they are doing currently
have no good means to tell that to Emacs on a case by case basis.  If
they turn on transient-mark-mode, they get a whole slew of non-trivial
behaviors as a single package deal; if they turn on
delete-selection-mode, they have another package deal which
contradicts some of the one they get with transient-mark-mode.

My proposal is to give users a more fine-grained control of that, so
that users could control the "meaning" of the current region with
easily typed commands, and by that tell the next command(s) how to
interpret the region.  The implementation of this proposal could be
based on a new "state" of the region, which will be the 3rd state in
addition to the currently-available "active" and "inactive" states.
The 3rd state will have the semantics of supporting the behavior
provided by the commands that have the delete-selection property on
their symbols.  Or it could be based on something else.  The important
facet of the proposal is that we need to introduce easily typed
commands that will assign one of the 3 possible meanings to the
current region.

With that, users will have the capability of using delete-selection
features when they need them, without deciding up front that they
prefer those features to other commands that pay attention to active
regions.  We could also teach the commands which could support either
behavior to DTRT by default using some heuristics.  All of this and
more is currently impossible because the same state of the region is
interpreted differently by some commands given a global mode.

> This discussion, since it now deals with all possibilities
> (because people who take different approaches have
> widened the scope), has made apparent the complications.
> 
> But a given user normally doesn't sense how complicated
> this stuff can be. Mr X knows his way of using the region;
> Ms Y knows her way, and so on.

You assume that there's only one "way" for Mr X and Ms Y.  But that
assumption is not necessarily true, for experienced users.  They will
want each of those "ways" in some specific circumstances.  For
example, "C-x C-x" used as navigation tools doesn't need to activate
the region; only the user knows whether that is the case in each
specific use case.  Similarly, typing a character or DEL when the
region is active should replace/delete the region _sometimes_, but not
always, and only the user knows which is which.  As an experienced
user who sometimes needs each one of those features, I would like to
be able to control what happens in each case, and turning on and off
global modes is too blunt an instrument for that; in particular,
the relevant commands are too long and tedious to type.  So I'm
currently forced to choose just one of these 3 features, the one that
gets in my way the least.  I would like to be freed from this "one
fits all use cases" prison.

> You make it sound like things are crystal clear and simple
> with the status quo, and that defaulting to d-s-m would
> muddy the waters.

I said nothing of the kind.  See above.

> In fact, the waters are muddy now, if one bothers to look
> into them.

That's exactly what I'm saying.  I also suggested one way out of this
conundrum.

> What's not correct is to suggest that the complications come from
> d-s-m.

Nothing like that was suggested.  And even if it could be somehow
understood it was, discussing this particular aspect is a tangent that
gets us away from the real issues.  Let's not go there just because we
can.

> It's wrong to suggest that all is harmonious between
> your first two region "uses": navigation and invoking
> commands on a region, and that your third "use",
> delete-selection-mode, is the irreconcilable culprit that
> threatens to spit in the soup and turn harmony into discord.

There's no such suggestion.  Don't feel "offended" on behalf of
delete-selection-mode.  (And there's no need to say the same thing
time and again in so many different ways.)

> Defaulting to d-s-m would just make life simpler for
> most users (IMHO). And those who don't want d-s-m
> on can turn it off.

I believe this is a false dichotomy; there's a better solution that
would leave more users happy.

> You've decided that d-s-m won't be on by default
> anytime soon.

No such decision was made.