RE: [External] : Re: Change default behavior of some commands that act on region?

[Drew Adams]

> > > > the proposed change has no effect on users who disable
> > > > `transient-mark-mode'.  They continue to have "full
> > > > support".
> 
> First of all, I haven't followed this thread in all its
> details, so far.

It should be enough to read the first message, the
proposal, which hasn't changed.

All the rest, except for Clement's pointing out what
the proposal actually says, has been distraction, if
not diversion.

> That said, I think your above point is a little naive.  I also have
> transient-mark-mode disabled, I run with "GUI disabled", and run with
> "minibuffer-only frames disabled".

Then the proposal is irrelevant to your use of Emacs.
It wouldn't affect your use in any way.  It has NO
effect when t-m-m is off, and it has no effect on
Lisp code that invokes a command non-interactively.

> I am very wary of changes which balkanise Emacs.

Please, let's not use hyperbole.  Nothing I suggested
balkanizes Emacs in any way.

> Every change which only works with some options, or which works
> differently depending on options which aren't specifically configuring
> that thing, makes Emacs more of a tangled mess.  (Not that I'm saying
> it already is such a mess, but we want to avoid making it so.)

I don't think anything I've proposed does _anything_
like that.

> I think you're proposing to make some functions (have you
> said exactly which ones, yet?)...

No, I haven't.  That remains to be decided, and IMO users
could be able themselves to decide that, if they want.
But I expect that a defvar (not a defcustom) is all that's
called for, and that few users would bother to change the
value.

The commands that motivated the idea were `upcase-region',
`downcase-region', and `capitalize-region', in case that
helps.

A user pointed out that large parts of his file got changed
to lowercase somehow, and he had no idea how/when/why that
happened.  I guessed that maybe he hit `C-x C-l' by accident,
and the inactive region was thus down-cased.

I have no idea if that was the real cause of his problem,
but it's easy enough to fall into that gotcha, IMO.  And
the text that gets modified can even be off-screen, so you
might not notice it right away.

[You might not judge that to be a gotcha, because you turn
t-m-m OFF.  But for the many users who leave it ON, the
gotcha is a real possibility.  They're used to _seeing_
the region of text that will be acted on stand out, as a
highlighted selection.]

Essentially, this is about commands that act on the region
and do not check whether it is active, that is, that act on
it even when t-m-m is enabled and the region is inactive.

Just which commands in that category should be under user
control this way is up for grabs.  Certainly there are
over 100 such commands.  MOST commands that act on the
region do not check whether it is inactive (in t-m-mode,
which is the only time "active/inactive" has any meaning).
The effect of many of them is pretty benign, however.

I have _not_ proposed that _any_ such commands be changed
to check whether the region is active and, if not, to do
nothing to it.  That's a separate, case-by-case question.
Maybe _some_ such commands should check `region-active-p'
or `use-region-p'.  But maybe _none_ of them should.  Not
the question at hand.  I'm not trying to extend t-m-m, as
you fear.

And in case someone's not aware, those two predicates
return nil whenever `transient-mark-mode' is OFF.  They're
used to decide what to do when that mode is ON, but they
generally have the effect of using the region _only_ when
t-m-mode is on (and the region is active).

But _if_ a command were changed to start checking for an
active region, it _could_ choose to do so only when t-m-m
is ON, so as not to affect the case when it's OFF, i.e.,
not to deprive the region from being acted on when it's
OFF.  Why not, in some cases?

E.g., instead of using those predicates, which return nil
when t-m-m is OFF, it could use a predicate that returns
`t' when t-m-m is OFF and only _otherwise_ checks whether
the region is active etc.

 (defun a-different-use-region-p ()
   "Return non-nil if the region is usable.
 It's always usable if `transient-mark-mode' is off.
 If on, it's usable when `use-region-p' returns non-nil."
   (or (not transient-mark-mode)  (use-region-p)))

You should maybe like such a consideration, no?
Those who've introduced `use-region-p' here and there
have essentially removed use of the region for the
given command, when t-m-m is off.  Why?  (But probably
more commonly, before introducing that, the command
had no use of the region, so nothing was taken away.)

Consider `m' in Dired.  When t-m-m is ON, `m' marks
all files in the active region (and just the file of
the current line if the region is inactive).  But
when t-m-m is OFF, `m' always marks only the file of
the current line.  Should it let you mark all files in
the region?  Dunno - maybe, maybe not, but you get the
point - why let only t-m-m users be able to act on the
files in the region here?

(This point is irrelevant to the proposal.  I mention
it only to suggest that I'm not encroaching on the use
of t-m-m being OFF.  In fact, I expect that users with
it OFF might be unnecessarily missing some features
that have been added and that affect only the active
region.  But I'm not proposing that t-m-m OFF should
encroach either.)

> [make some functions] behave differently in t-m-m.
> That _is_ of concern to everybody, including those who
> run with t-m-m disabled.

Of course anyone can be interested (or "concerned").  But
those who disable t-m-m need not be concerned about their
_own use_, i.e., with t-m-m disabled.  That's all I've
said, in response to multiple harangues about negatively
affecting such no-t-m-m use.

Regardless of one's own use case, yes, the proposal can
be of interest to anyone.  It's about Emacs behavior with
t-m-m ON and with an inactive region.  Ideas about what
should happen in _that_ case?  That's all that's relevant
here.

The proposal simply says that we'd give users an option,
to specify the behavior in that case for some commands.

> There have been features in the past introduced as "optional" into
> Emacs, followed some time later by pressure to conform with these
> "optional" features.  You can't blame people for feeling uneasy
> about this proposal.

I've only asked that people actually respond to what was
proposed, and not to some (repeated...) straw man about
screwing with the behavior when t-m-m is off.

> There might well have been an understanding in the past that
> t-m-m would not be forced any further into Emacs than it is
> already.  If that is the case, your proposal would be a
> violation of that understanding and an example of the
> pressure I refer to above.

This is incredible.  What do I have to say, to convince you
that this doesn't change at all the possibility of t-m-m
being on or off.  There's no forcing of t-m-m on anyone or
on Emacs.  There's no change to t-m-m mode at all.

> > t-m-mode's raison d'etre is to be able to do something
> > when the user sees the selected text highlighted and not
> > otherwise.  That distinction is what it's all about.
> 
> Yes.  But I think adding things into "something" to make it
> "something else as well" needs to be justified case by case.

Again, there's no proposal to add ANYTHING to (or subtract
anything from) t-m-m.  There's no proposal to increase (or
decrease) the scope of t-m-m.

All that's proposed is to give users an option to define,
for some set of commands that currently affect the inactive
region in t-m-mode, whether they should continue to do that,
and if not, what they should do (error, no-op, or act on
confirmation).