Change default behavior of some commands that act on region?

Change default behavior of some commands that act on region?

[Drew Adams]

This is a follow-up to this post to help-gnu-emacs@gnu.org:

  https://lists.gnu.org/archive/html/help-gnu-emacs/2021-05/msg00762.html

I hesitate to suggest changing default behavior, but
maybe this is worth considering.

There are some commands, such as `downcase-region',
that act on the region regardless of whether it's
active.  Because `transient-mark-mode' has been on by
default for quite a while now, and because there are
few such commands, users can wonder what's going on.

Or worse, they can sometimes not notice that anything
happened until much later, and then not understand
what caused the change (whatever it is).

Would it be too shocking to change the default
behavior of some such commands, so that they would
do something "safer"?

For example, when invoked interactively, if the
region is not active, and if `transient-mark-mode'
is turned on, such commands could do something like:

* be a no-op
* raise an error
* prompt for confirmation first

Those conditions are important: There'd be no change
when invoked from code, or when `transient-mark-mode'
is off.  Anyone who leaves that mode off would see no
change in behavior, and the same for existing Lisp code.

Re: Change default behavior of some commands that act on region?

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Fri, 21 May 2021 20:58:48 +0000
> 
> Would it be too shocking to change the default
> behavior of some such commands, so that they would
> do something "safer"?

Yes, it would.  E.g., in my use of Emacs, region is almost never
active.  So you in effect propose making these important editing
commands be no-ops by default for me.

Re: Change default behavior of some commands that act on region?

[Clément Pit-Claudel]

On 5/22/21 2:04 AM, Eli Zaretskii wrote:
> E.g., in my use of Emacs, region is almost never
> active.

But you use transient-mark-mode?

Re: Change default behavior of some commands that act on region?

[Emanuel Berg via Emacs development discussions.]

Clément Pit-Claudel wrote:

> On 5/22/21 2:04 AM, Eli Zaretskii wrote:
>
>> E.g., in my use of Emacs, region is almost never
>> active.
>
> But you use transient-mark-mode?

`region-active-p'

also DWIM functions with optional arguments that defaults to
`point-min' and `point-max'...

and more

-- 
underground experts united
https://dataswamp.org/~incal

Re: Change default behavior of some commands that act on region?

[Clément Pit-Claudel]

On 5/22/21 2:36 AM, Emanuel Berg via Emacs development discussions. wrote:
> Clément Pit-Claudel wrote:
> 
>> On 5/22/21 2:04 AM, Eli Zaretskii wrote:
>>
>>> E.g., in my use of Emacs, region is almost never
>>> active.
>>
>> But you use transient-mark-mode?
> 
> `region-active-p'
> 
> also DWIM functions with optional arguments that defaults to
> `point-min' and `point-max'...

I don't understand your reply.

Re: Change default behavior of some commands that act on region?

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Sat, 22 May 2021 02:19:26 -0400
> 
> On 5/22/21 2:04 AM, Eli Zaretskii wrote:
> > E.g., in my use of Emacs, region is almost never
> > active.
> 
> But you use transient-mark-mode?

No, I turn it off.

Re: Change default behavior of some commands that act on region?

[Clément Pit-Claudel]

On 5/22/21 2:45 AM, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Sat, 22 May 2021 02:19:26 -0400
>>
>> On 5/22/21 2:04 AM, Eli Zaretskii wrote:
>>> E.g., in my use of Emacs, region is almost never
>>> active.
>>
>> But you use transient-mark-mode?
> 
> No, I turn it off.

Then you wouldn't be affected by the change, if I understand Drew's suggestion correctly.

Re: Change default behavior of some commands that act on region?

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Sat, 22 May 2021 03:00:17 -0400
> Cc: emacs-devel@gnu.org
> 
> On 5/22/21 2:45 AM, Eli Zaretskii wrote:
> >> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> >> Date: Sat, 22 May 2021 02:19:26 -0400
> >>
> >> On 5/22/21 2:04 AM, Eli Zaretskii wrote:
> >>> E.g., in my use of Emacs, region is almost never
> >>> active.
> >>
> >> But you use transient-mark-mode?
> > 
> > No, I turn it off.
> 
> Then you wouldn't be affected by the change, if I understand Drew's suggestion correctly.

Just wait for the discussion to continue, and you will see why I'm
worried already.

In any case, other uses who don't turn off Transient mark mode will be
affected.

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

[Drew Adams]

> >>> E.g., in my use of Emacs, region is almost never
> >>> active.
> >>
> >> But you use transient-mark-mode?
> >
> > No, I turn it off.
> 
> Then you wouldn't be affected by the change, 
> if I understand Drew's suggestion correctly.

Exactly.  To quote the proposal:

1.
> if the region is not active, and if `transient-mark-mode'
> is turned on, such commands could do something like...
  ^^^^^^^^^^^^

And I explicitly _emphasized_ it, adding:

2.
> Those conditions are important: There'd be no change
                                             ^^^^^^^^^
> when invoked from code, or when `transient-mark-mode'
  ^^^^^^^^^^^^^^^^^^^^^^     ^^^^^^^^^^^^^^^^^^^^^^^^^^
> is off.
  ^^^^^^

3.
> Anyone who leaves that mode off would see no
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> change in behavior, and the same for existing Lisp code.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That's 3 times I said it, at the outset.

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

[Drew Adams]

> > Would it be too shocking to change the default
> > behavior of some such commands, so that they would
> > do something "safer"?
> 
> Yes, it would.  E.g., in my use of Emacs, region is almost never
> active.  So you in effect propose making these important editing
> commands be no-ops by default for me.

It seems you didn't read the proposal well.  I invite
you to do so.

You say (in another message) that your "use of Emacs"
means leaving `transient-mark-mode' OFF.

In that case, there would be ZERO change for you.
"These important editing commands" would continue to
behave exactly the same as now.

The proposal explicitly has NO EFFECT either:

1. For Lisp code that invokes the command non-interactively.

or

2. When `transient-mark-mode' is turned OFF.

Re: Change default behavior of some commands that act on region?

[Stefan Monnier]

> There are some commands, such as `downcase-region',
> that act on the region regardless of whether it's
> active.  Because `transient-mark-mode' has been on by
> default for quite a while now, and because there are
> few such commands, users can wonder what's going on.

I see two sub-issues to this:

1- Breaking long-standing behavior.  I'll let others figure out how to
   minimize this (e.g. by testing for `transient-mark-mode` or something).

2- If we take a step back, I think we'll see there's a "better optimum"
   in this area when `transient-mark-mode` is in use.  E.g. we could
   combine `downcase-word` and `downcase-region` into a single command
   which will do either of the two depending on `use-region-p`.


-- Stefan

Re: Change default behavior of some commands that act on region?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Sat, 22 May 2021 10:03:07 -0400
> 
> > There are some commands, such as `downcase-region',
> > that act on the region regardless of whether it's
> > active.  Because `transient-mark-mode' has been on by
> > default for quite a while now, and because there are
> > few such commands, users can wonder what's going on.
> 
> I see two sub-issues to this:
> 
> 1- Breaking long-standing behavior.  I'll let others figure out how to
>    minimize this (e.g. by testing for `transient-mark-mode` or something).
> 
> 2- If we take a step back, I think we'll see there's a "better optimum"
>    in this area when `transient-mark-mode` is in use.  E.g. we could
>    combine `downcase-word` and `downcase-region` into a single command
>    which will do either of the two depending on `use-region-p`.

To remind us, this was triggered by someone's mistaken keypress.  I
don't think we should use such mistakes to justify significant changes
in long-established behavior.  I can easily come up with other
examples where mistakenly holding, e.g., the Ctrl key makes an
absolute mess of my editing (e.g., 's' becomes C-s, and the rest of
what I type more-or-less disappears into the void).  That doesn't mean
we should make over-reaching changes to save me from myself.  That way
lies madness, IMO.  We should stop before it's too late.

Re: Change default behavior of some commands that act on region?

[Stefan Monnier]

>> I see two sub-issues to this:
>> 
>> 1- Breaking long-standing behavior.  I'll let others figure out how to
>>    minimize this (e.g. by testing for `transient-mark-mode` or something).
>> 
>> 2- If we take a step back, I think we'll see there's a "better optimum"
>>    in this area when `transient-mark-mode` is in use.  E.g. we could
>>    combine `downcase-word` and `downcase-region` into a single command
>>    which will do either of the two depending on `use-region-p`.
>
> To remind us, this was triggered by someone's mistaken keypress.  I
> don't think we should use such mistakes to justify significant changes
> in long-established behavior.  I can easily come up with other
> examples where mistakenly holding, e.g., the Ctrl key makes an
> absolute mess of my editing (e.g., 's' becomes C-s, and the rest of
> what I type more-or-less disappears into the void).  That doesn't mean
> we should make over-reaching changes to save me from myself.  That way
> lies madness, IMO.  We should stop before it's too late.

I think you're referring to sub-issue (1) above.
That doesn't preclude improving our UI as in (2) above, which would free
up `C-x C-l` for those users who prefer to use "transient-mark-mode +
M-l".


        Stefan

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

[Drew Adams]

> > Breaking long-standing behavior.  I'll let others figure
> > out how to minimize this (e.g. by testing for
> > `transient-mark-mode` or something).

There's nothing to figure out.  The proposal said
clearly from the outset that it would have NO effect
when `transient-mark-mode' is turned OFF.

So yes, `transient-mark-mode' would be tested, and if
nil then the long-standing behavior would be UNCHANGED.

Similarly, the behavior of Lisp code that invokes the
command non-interactively would be UNCHANGED.

(if (or (not (called-interactively-p 'interactive))
        (not transient-mark-mode))
    (apply COMMAND ARGS) ; NO CHANGE FROM PAST BEHAVIOR

  ;; Do what user wants for such a command
  ;; when region is inactive.
  ...
  )

The only change in "long-standing behavior" would be for
interactive use when `transient-mark-mode' is turned ON.

And even that could be configurable.  E.g.:

* A list (defvar) of the commands that would be affected.
  Users could change this, but mostly would not bother.

* A defcustom to choose command behavior for inactive region:

  1. Do nothing (ignore - command is a no-op on inactive region).

  2. Prompt to confirm action.
     (e.g. "Region is inactive.  Invoke `foobar' on it anyway?")

  3. Raise an error.
     (e.g. "Cannot use `foobar' interactively with inactive region")

  A good default behavior would be to do nothing (#1),
  in keeping with the aim to use `transient-mark-mode'
  to govern things.  These are essentially commands that
  never learned about `transient-mark-mode' and active
  regions.  In general, there's little sense in turning
  on `transient-mark-mode' and wanting commands to act
  on the INactive region.

* For named commands at least, we could add an ability to
  override the defcustom behavior for particular commands:

  (put 'foobar 'inactive-region-command-action 'error)

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

[Drew Adams]

> If we take a step back, I think we'll see there's a "better optimum"
> in this area when `transient-mark-mode` is in use.  E.g. we could
> combine `downcase-word` and `downcase-region` into a single command
> which will do either of the two depending on `use-region-p`.

Sure, you can do something like that.  But the thread
is not particularly about down-casing.  It's about
some/most/all such commands.

Commands that don't distinguish an active region,
and that can surprise or make unnoticed changes when
`transient-mark-mode' is on and the region is not
active.

`transient-mark-mode' being on is the common case now.
Some commands haven't awakened to see that's the case.

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

[Stefan Monnier]

>> If we take a step back, I think we'll see there's a "better optimum"
>> in this area when `transient-mark-mode` is in use.  E.g. we could
>> combine `downcase-word` and `downcase-region` into a single command
>> which will do either of the two depending on `use-region-p`.
> Sure, you can do something like that.  But the thread
> is not particularly about down-casing.  It's about
> some/most/all such commands.

My comment above was not specific to downcasing either.


        Stefan

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

[Drew Adams]

> >> If we take a step back, I think we'll see there's a "better optimum"
> >> in this area when `transient-mark-mode` is in use.  E.g. we could
> >> combine `downcase-word` and `downcase-region` into a single command
> >> which will do either of the two depending on `use-region-p`.
> >
> > Sure, you can do something like that.  But the thread
> > is not particularly about down-casing.  It's about
> > some/most/all such commands.
> 
> My comment above was not specific to downcasing either.

Actually, your comment above _was_ specific to downcasing.
But maybe you meant something more general.

In that case, you're talking about substituting a bunch
of commands, presumably swapping in the new commands for
(some of) their bindings.

Would those key-binding changes be by default?  Some old
users might not appreciate the change in default behavior
(but of course they can always rebind the keys).

If you don't propose such key-binding changes, then users
not used to region-commands that act on an inactive region
will continue to be bitten.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Sat, 22 May 2021 19:26:02 +0000
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> `transient-mark-mode' being on is the common case now.
> Some commands haven't awakened to see that's the case.

That is your personal interpretation, but it is not true.

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

[Drew Adams]

> > `transient-mark-mode' being on is the common case now.
> 
> That is your personal interpretation, but it is not true.

Can you show evidence that it's _not true_, or is that
just  "your personal interpretation"?

I'm not counting cases of who turns it off (are you?),
but my guess (yes, a guess) is that more Emacs users
have it on than off.  Evidence to the contrary?

t-m-mode ON is the default, and it has been for years
now.  It should be enough to point that out, whether
or not its being left ON is the more common use case.

In any case, whether more have it on or off is, as
I've pointed out, irrelevant to this thread, which is
concerned _only_ with the case when it's on.

Changes proposed here have NO effect on the case when
it's off.  Dunno how many times this needs to be
repeated before you let go.  There really is no need
to go on about the case when t-m-mode is off.  That's
a digression, if not a diversion.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "monnier@iro.umontreal.ca" <monnier@iro.umontreal.ca>,
>         "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Sun, 23 May 2021 14:27:29 +0000
> Accept-Language: en-US
> 
> > > `transient-mark-mode' being on is the common case now.
> > 
> > That is your personal interpretation, but it is not true.
> 
> Can you show evidence that it's _not true_, or is that
> just  "your personal interpretation"?

You are now down to distorting what I write by removing parts of
whatever I respond to?

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

[Drew Adams]

> > > > `transient-mark-mode' being on is the common case now.
> > >
> > > That is your personal interpretation, but it is not true.
> >
> > Can you show evidence that it's _not true_, or is that
> > just  "your personal interpretation"?
> 
> You are now down to distorting what I write by removing
> parts of whatever I respond to?

Oh, please, stop the ad hominem.

Did you instead mean that the "personal interpretation"
which is "not true", was the second line I wrote, not
the first?  Here are the lines:

  > `transient-mark-mode' being on is the common case now.
  > Some commands haven't awakened to see that's the case.

I had to guess what it was you were claiming was personal
and untrue, and I spoke to that.  Apparently I guessed
wrong; sorry.  I thought you were trying to argue that
t-m-m ON is not so common.  Mea culpa.

If you meant the second line, then yes, it's a personal
opinion, and there's really no true or false possible.

By that second line, I meant that there are many commands
that don't take t-m-m into account.  When the mode is ON
they don't do anything different from when it's OFF.  And
when it's ON they don't make a difference for whether the
region is active or is empty.

Many commands predate the existence of t-m-m, let alone
its being turned ON by default.  Would you argue that
there are _no_ such commands that could benefit from
considering the t-m-m ON case?  I, yes, suggested that
"some" might benefit.  A personal opinion, yes.  There's
no true or false here.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "monnier@iro.umontreal.ca" <monnier@iro.umontreal.ca>,
>         "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Sun, 23 May 2021 17:50:39 +0000
> 
> By that second line, I meant that there are many commands
> that don't take t-m-m into account.

And rightfully so.  At least most of them.  To say that they do that
because they haven't "awakened" to transient-mark-mode is a
misrepresentation that hints at the Emacs developers' being obtuse or
worse.  You have no basis for such accusations, so don't.

> Would you argue that there are _no_ such commands that could benefit
> from considering the t-m-m ON case?

That's a far cry from what you actually wrote, to what I responded.  I
will take this as an apology.

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

[Drew Adams]

> > Would you argue that there are _no_ such commands that
> > could benefit from considering the t-m-m ON case?
> 
> That's a far cry from what you actually wrote, to
> what I responded.

No, it is what I actually wrote.  I suggested that
"some" (SOME) such commands "might" (MIGHT) "benefit".
And after your reactions I repeated that I suggested
exactly that, to make it crystal clear.

The opposite of accepting that SOME such commands
might benefit is to claim that NONE could benefit.

You haven't actually answered the question.  Is that
what you think: that none could possibly benefit from
such consideration?  If not, then you must agree with
me that _some_ could.

You often manage to take things personally, it seems.
Saying that some _commands_ haven't yet awakened to
handle taking t-m-m into account is only saying that
they haven't been updated to take t-m-m into account.

It says nothing about "the Emacs developers", and
certainly not that they are "obtuse or worse".  Is it
possible to point to areas of possible improvement
for Emacs without being accused of attacking you?

There are many such commands.  Maybe there are only
a few that, upon consideration, we would want to
update.  Who knows, without considering?  Anyway,
changing definitions of individual commands is, as
I said, outside the proposal of this thread.

The connection to this thread is that there are
commands that might well be doing something less
than ideal in t-m-m with an inactive region, and
the proposal is about a general way to handle some
of that.

(And to be clear, Alan, even actually updating a
command definition to take t-m-m into account
doesn't imply changing any behavior for when t-m-m
is OFF.)

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Sun, 23 May 2021 19:22:06 +0000
> Cc: "monnier@iro.umontreal.ca" <monnier@iro.umontreal.ca>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> No, it is what I actually wrote.  I suggested that
> "some" (SOME) such commands "might" (MIGHT) "benefit".

No, that's what you say now.

> Saying that some _commands_ haven't yet awakened to
> handle taking t-m-m into account is only saying that
> they haven't been updated to take t-m-m into account.
> 
> It says nothing about "the Emacs developers", and
> certainly not that they are "obtuse or worse".  Is it
> possible to point to areas of possible improvement
> for Emacs without being accused of attacking you?

Depends on the words you use.  May I suggest that you think about your
words some more next time?  You have been pointed out by several
people already that your style and attitude make it very unpleasant to
have useful conversations with you.

> There are many such commands.  Maybe there are only
> a few that, upon consideration, we would want to
> update.  Who knows, without considering?

Here we go again: you assume, almost by default, that no one has
considered that.  And of course, your opinion that clearly shows is
that if we DID consider it, we would have changed MANY commands.

> The connection to this thread is that there are
> commands that might well be doing something less
> than ideal in t-m-m with an inactive region, and
> the proposal is about a general way to handle some
> of that.

If you know about such commands (besides the two you mentioned), name
them.  Otherwise such vague claims aren't useful.

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

[Drew Adams]

Nevermind.  I give up.

Re: Change default behavior of some commands that act on region?

[Tim Cross]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> There are some commands, such as `downcase-region',
>> that act on the region regardless of whether it's
>> active.  Because `transient-mark-mode' has been on by
>> default for quite a while now, and because there are
>> few such commands, users can wonder what's going on.
>
> I see two sub-issues to this:
>
> 1- Breaking long-standing behavior.  I'll let others figure out how to
>    minimize this (e.g. by testing for `transient-mark-mode` or something).
>
> 2- If we take a step back, I think we'll see there's a "better optimum"
>    in this area when `transient-mark-mode` is in use.  E.g. we could
>    combine `downcase-word` and `downcase-region` into a single command
>    which will do either of the two depending on `use-region-p`.
>
>

Just to throw another point into the mix here for consideration.

From an accessibility perspective, transient mark mode can be a challenge.
For example, if your blind, you cannot see the highlighted region.
Therefore, packages like emacspeak turn off transient mark mode.

I raise this to highlight there is another 'group' of users who turn off
transient mark mode, so any changes to these long standing defaults
might want to consider impact on this group as well. Solutions, such as
telling people to turn on transient mark mode to get back some behaviour
is unlikely to help. If your blind, transient mark mode really just
causes confusion. 

Personally, I'm not sure there really is a need for this change. I've
seen few (none I can recall) complaints from users suggesting the
existing behaviour is confusing, but perhaps this isn't the sort of
question people ask?


-- 
Tim Cross

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

[Drew Adams]

> I raise this to highlight there is another 'group' of users who turn
> off transient mark mode, so any changes to these long standing defaults
> might want to consider impact on this group as well.

I repeat that anyone who turns OFF `transient-mark-mode'
would be _totally unaffected_ by what was proposed.

Likewise, Lisp code that invokes a command non-interactively
would be totally unaffected.

The effect would be only for _interactive_ use of a command,
and only when `transient-mark-mode' is turned ON.

This was quite clear from the beginning - please read what
I wrote.  I fear that perhaps Eli's quick reaction,
mischaracterizing the proposal as affecting users who turn
off `transient-mark-mode', may have affected others.

Re: Change default behavior of some commands that act on region?

[Stefan Monnier]

> From an accessibility perspective, transient mark mode can be a challenge.
> For example, if your blind, you cannot see the highlighted region.
> Therefore, packages like emacspeak turn off transient mark mode.

Indeed, it is important to keep full support for configs where
`transient-mark-mode` is disabled.  Not only many users prefer such
a config, but as you mention, there are also cases where such a config
is not just a question of taste.


        Stefan

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

[Drew Adams]

> > From an accessibility perspective, transient mark mode can be a
> > challenge.  For example, if your blind, you cannot see the
> > highlighted region.  Therefore, packages like emacspeak turn
> > off transient mark mode.
> 
> Indeed, it is important to keep full support for configs where
> `transient-mark-mode` is disabled.  Not only many users prefer such
> a config, but as you mention, there are also cases where such a config
> is not just a question of taste.

Yes, and this is irrelevant to this thread, as the
proposed change has no effect on users who disable
`transient-mark-mode'.  They continue to have "full
support".

But I suppose if the contrary gets repeated enough
then the thread can continue to be drowned out by
misrepresentation.  Of course, a misreading can be
an honest mistake...  Once.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Sun, 23 May 2021 01:37:41 +0000
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> > Indeed, it is important to keep full support for configs where
> > `transient-mark-mode` is disabled.  Not only many users prefer such
> > a config, but as you mention, there are also cases where such a config
> > is not just a question of taste.
> 
> Yes, and this is irrelevant to this thread, as the
> proposed change has no effect on users who disable
> `transient-mark-mode'.  They continue to have "full
> support".
> 
> But I suppose if the contrary gets repeated enough
> then the thread can continue to be drowned out by
> misrepresentation.  Of course, a misreading can be
> an honest mistake...  Once.

Please stop this disrespectful attitude towards the views of others.
Please also don't assume that people who disagree with you haven't
read what you wrote.

The issue you consider "irrelevant" is actually quite relevant,
because commands that behave differently depending on whether
transient-mark-mode is on or off are a source of confusion and
frustration.  We shouldn't enlarge the number of such commands
willy-nilly.

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

[Drew Adams]

> > > Indeed, it is important to keep full support for configs 
> > > where `transient-mark-mode` is disabled.  Not only many 
> > > users prefer such a config, but as you mention, there are 
> > > also cases where such a config is not just a question of 
> > > taste.
> >
> > Yes, and this is irrelevant to this thread, as the
                                ^^^^^^^^^^^^^^
> > proposed change has no effect on users who disable
> > `transient-mark-mode'.  They continue to have "full
> > support".
>
> The issue you consider "irrelevant" is actually quite relevant,

I didn't say that support for use of t-m-mode OFF is
irrelevant.  It's very relevant to Emacs.  But it's not
relevant to the proposal of this thread, which has NO
effect on that use case.  That's the point.  Please
don't twist what's been said.  You're arguing against
a straw man.

I've written carefully and clearly, from the outset, that
this proposal has NO effect on that use case.  Yet you've
insisted on pursuing it for supposedly ignoring, or even
inflicting damage, on that case.  Please stop.  There's
nothing relevant about insisting on needing to protect
the t-m-mode OFF case against this proposal, as there's
no threat to it.

> because commands that behave differently depending on whether
> transient-mark-mode is on or off are a source of confusion and
> frustration.  We shouldn't enlarge the number of such commands
> willy-nilly.

Every command that tests `use-region-p' and does something
different depending on the value does something different
depending on whether t-m-mode is on or off, simply because
when it's off there's no notion of active/inactive region
- there's just the region.

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.

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

[Alan Mackenzie]

Hello, Drew.

On Sun, May 23, 2021 at 14:28:35 +0000, Drew Adams wrote:
> > > > Indeed, it is important to keep full support for configs 
> > > > where `transient-mark-mode` is disabled.  Not only many 
> > > > users prefer such a config, but as you mention, there are 
> > > > also cases where such a config is not just a question of 
> > > > taste.

> > > Yes, and this is irrelevant to this thread, as 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.
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".

I am very wary of changes which balkanise Emacs.  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.)

> > The issue you consider "irrelevant" is actually quite relevant,

> I didn't say that support for use of t-m-mode OFF is
> irrelevant.  It's very relevant to Emacs.  But it's not
> relevant to the proposal of this thread, which has NO
> effect on that use case.  That's the point.  Please
> don't twist what's been said.  You're arguing against
> a straw man.

I think you're proposing to make some functions (have you said exactly
which ones, yet?) behave differently in t-m-m.  That _is_ of concern to
everybody, including those who run with t-m-m disabled.

> I've written carefully and clearly, from the outset, that
> this proposal has NO effect on that use case.  Yet you've
> insisted on pursuing it for supposedly ignoring, or even
> inflicting damage, on that case.  Please stop.  There's
> nothing relevant about insisting on needing to protect
> the t-m-mode OFF case against this proposal, as there's
> no threat to it.

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.

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.

> > because commands that behave differently depending on whether
> > transient-mark-mode is on or off are a source of confusion and
> > frustration.  We shouldn't enlarge the number of such commands
> > willy-nilly.

> Every command that tests `use-region-p' and does something
> different depending on the value does something different
> depending on whether t-m-mode is on or off, simply because
> when it's off there's no notion of active/inactive region
> - there's just the region.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

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

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

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 3939 bytes --]

Alan Mackenzie <acm@muc.de> writes:


Douglas Adams in HHG (a source of universal wisdom from my perspective):
If someone were to explain how the universe works, it'll immediately
disappear and be replaced by one that is even more inexplicable.

There are some who believe this has already happened.


> Hello, Drew.
>
> On Sun, May 23, 2021 at 14:28:35 +0000, Drew Adams wrote:
>> > > > Indeed, it is important to keep full support for configs 
>> > > > where `transient-mark-mode` is disabled.  Not only many 
>> > > > users prefer such a config, but as you mention, there are 
>> > > > also cases where such a config is not just a question of 
>> > > > taste.
>
>> > > Yes, and this is irrelevant to this thread, as 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.
> 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".
>
> I am very wary of changes which balkanise Emacs.  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.)
>
>> > The issue you consider "irrelevant" is actually quite relevant,
>
>> I didn't say that support for use of t-m-mode OFF is
>> irrelevant.  It's very relevant to Emacs.  But it's not
>> relevant to the proposal of this thread, which has NO
>> effect on that use case.  That's the point.  Please
>> don't twist what's been said.  You're arguing against
>> a straw man.
>
> I think you're proposing to make some functions (have you said exactly
> which ones, yet?) behave differently in t-m-m.  That _is_ of concern to
> everybody, including those who run with t-m-m disabled.
>
>> I've written carefully and clearly, from the outset, that
>> this proposal has NO effect on that use case.  Yet you've
>> insisted on pursuing it for supposedly ignoring, or even
>> inflicting damage, on that case.  Please stop.  There's
>> nothing relevant about insisting on needing to protect
>> the t-m-mode OFF case against this proposal, as there's
>> no threat to it.
>
> 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.
>
> 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.
>
>> > because commands that behave differently depending on whether
>> > transient-mark-mode is on or off are a source of confusion and
>> > frustration.  We shouldn't enlarge the number of such commands
>> > willy-nilly.
>
>> Every command that tests `use-region-p' and does something
>> different depending on the value does something different
>> depending on whether t-m-mode is on or off, simply because
>> when it's off there's no notion of active/inactive region
>> - there's just the region.
>
>> 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.

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Change default behavior of some commands that act on region?

[Juri Linkov]

> There are some commands, such as `downcase-region',
> that act on the region regardless of whether it's
> active.  Because `transient-mark-mode' has been on by
> default for quite a while now, and because there are
> few such commands, users can wonder what's going on.

I use such customization, problem solved:

#+begin_src emacs-lisp
(define-key esc-map "u" 'upcase-dwim)
(define-key esc-map "l" 'downcase-dwim)
(define-key esc-map "c" 'capitalize-dwim)
#+end_src

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

[Drew Adams]

> > There are some commands, such as `downcase-region',
> > that act on the region regardless of whether it's
> > active.  Because `transient-mark-mode' has been on by
> > default for quite a while now, and because there are
> > few such commands, users can wonder what's going on.
> 
> I use such customization, problem solved:
> 
> (define-key esc-map "u" 'upcase-dwim)
> (define-key esc-map "l" 'downcase-dwim)
> (define-key esc-map "c" 'capitalize-dwim)

1. Once again: the thread is about such commands in
   general - commands that affect the region whether
   or not it is active.

2. Proposing other commands and bindings doesn't
   take care of the problem.  Unless you are also
   proposing swapping alternative commands for each
   such problematic command, and giving them the
   key bindings of the old commands.  (And again,
   not just letter-case commands.)