bug#51927: 27.2; Rename `highlight-nonselected-windows'

bug#51927: 27.2; Rename `highlight-nonselected-windows'

[Drew Adams]

This variable seems poorly named, in more ways than one.  Could we
consider renaming it (by aliasing and perhaps deprecating the old name)?

Maybe use a name such as `show-active-region-everywhere'.  I won't fight
over the name, but I think it should have "region" in it, and ideally
"active" as well.

Not only is the name poor, but the doc is also less than ideal.

1. This var has no effect if `transient-mark-mode' is disabled.  The doc
should say something about it being relevant only for t-m-mode.  It
should say that when that's disabled the region is never "active", and
so it is never highlighted anywhere.

2. This is not really about highlighting windows.  (Yes, the
highlighting occurs in windows, of course.  But it's the active region
that's highlighted.)

3. The name says nothing about what's most important: "region".  This is
about showing (highlighting) the _active region_ in _all_ windows.

4. The doc should explain the alternative behavior, when the var is nil:
the active region is highlighted only in the selected window.

In GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)
 of 2021-03-26 built on CIRROCUMULUS
Repository revision: deef5efafb70f4b171265b896505b92b6eef24e6
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.19042
System Description: Microsoft Windows 10 Pro (v10.0.2009.19042.1288)

bug#51927: 27.2; Rename `highlight-nonselected-windows'

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Wed, 17 Nov 2021 21:03:45 +0000
> 
> This variable seems poorly named, in more ways than one.  Could we
> consider renaming it (by aliasing and perhaps deprecating the old name)?

This variable exists since Emacs 19.  Renaming it after all that time
would make no sense at all.

> 1. This var has no effect if `transient-mark-mode' is disabled.

That is inaccurate: it has no effect if the region is inactive (you
can have an active region even with transient-mark-mode disabled).  I
added the caveat to the doc string.

> 2. This is not really about highlighting windows.  (Yes, the
> highlighting occurs in windows, of course.  But it's the active region
> that's highlighted.)

The doc string says that.

> 3. The name says nothing about what's most important: "region".  This is
> about showing (highlighting) the _active region_ in _all_ windows.

See above: that ship sailed long ago.

> 4. The doc should explain the alternative behavior, when the var is nil:
> the active region is highlighted only in the selected window.

Added.

And with that, I'm closing this bug.

bug#51927: [External] : Re: bug#51927: 27.2; Rename `highlight-nonselected-windows'

[Drew Adams]

> > This variable seems poorly named, in more ways than one.  Could we
> > consider renaming it (by aliasing and perhaps deprecating the old name)?
> 
> This variable exists since Emacs 19.  Renaming it after all that time
> would make no sense at all.

I'm aware that it's an old name.
Renaming it makes a lot of sense.
There's no problem letting the old
name remain as an alias.

> > 1. This var has no effect if `transient-mark-mode' is disabled.
> 
> That is inaccurate: it has no effect if the region is inactive (you
> can have an active region even with transient-mark-mode disabled).  I
> added the caveat to the doc string.

I disagree.  The notion of "active" mark
or region has no meaning outside of
transient-mark-mode.  It was (naturally)
introduced precisely to describe t-m-mode
behavior.  There was no need for it before
then, and there's no need (or use) now, to
refer to it outside t-m-mode.  It has no
meaning, no user-visible or code-visible
behavior outside t-m-mode.

> > 2. This is not really about highlighting windows.  (Yes, the
> > highlighting occurs in windows, of course.  But it's the active region
> > that's highlighted.)
> 
> The doc string says that.

The enhancement request / bug report is
about the poor, inaccurate, misleading
_option name_.  Look for the option that
does what this does, and you won't find it.
Apropos, etc. can't help, because the name
is so inappropriate.  You may know of the
option, but have forgotten its name, and
you just won't find it.

> > 3. The name says nothing about what's most important: "region".  This is
> > about showing (highlighting) the _active region_ in _all_ windows.
> 
> See above: that ship sailed long ago.

See above, and the bug report.  There's
no problem keeping the old name as well
as a new, helpful, name.

Almost any name with "region" in it would
be an improvement.

> > 4. The doc should explain the alternative behavior, when the var is nil:
> > the active region is highlighted only in the selected window.
> 
> Added.  And with that, I'm closing this bug.

Yet another won't-fix.

bug#51927: [External] : Re: bug#51927: 27.2; Rename `highlight-nonselected-windows'

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "51927-done@debbugs.gnu.org" <51927-done@debbugs.gnu.org>
> Date: Thu, 18 Nov 2021 16:44:42 +0000
> 
> > > 1. This var has no effect if `transient-mark-mode' is disabled.
> > 
> > That is inaccurate: it has no effect if the region is inactive (you
> > can have an active region even with transient-mark-mode disabled).  I
> > added the caveat to the doc string.
> 
> I disagree.  The notion of "active" mark
> or region has no meaning outside of
> transient-mark-mode.

Not true:

  emacs -Q
  M-x transient-mark-mode RET
  M-<
  C-SPC C-SPC

Observe the message "Mark activated" in the echo area.

  C-u 20 C-f

Observe active region highlighted.

> Yet another won't-fix.

Will you ever learn to accept the judgment of the maintainers without
attacking it?

bug#51927: [External] : Re: bug#51927: 27.2; Rename `highlight-nonselected-windows'

[Drew Adams]

> > > > 1. This var has no effect if `transient-mark-mode' is disabled.
> > >
> > > That is inaccurate: it has no effect if the region is inactive (you
> > > can have an active region even with transient-mark-mode disabled).  I
> > > added the caveat to the doc string.
> >
> > I disagree.  The notion of "active" mark
> > or region has no meaning outside of
> > transient-mark-mode.
> 
> Not true:
> 
>   emacs -Q
>   M-x transient-mark-mode RET
>   M-<
>   C-SPC C-SPC
> 
> Observe the message "Mark activated" in the echo area.
> 
>   C-u 20 C-f
> 
> Observe active region highlighted.

You're just confirming what I've said.
`C-h f C-SPC' tells you:

"When Transient Mark Mode is off, immediately repeating this
command activates 'transient-mark-mode' temporarily."
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

When t-m-mode is enabled, the notion of an
"active" mark/region has a meaning/effect.

When it's disabled, it has no meaning/effect.
The echoes you mention don't change this fact
(unless you consider those echoes to be the
only "meaning/effect).  Those echoes didn't
exist before we added t-m-mode, and in the
case you cite they're just useless, at best,
or at worst (a wee bit) misleading.

T-m-mode is the default now (and that's a
good thing).  And all of Emacs has pretty
much taken its behavior aboard, as a given.
That includes the echoing you cite, about
activation of the mark.

There was no such talk of mark activation
before t-m-mode was added.  (There was only
setting the mark.)  Why?  Because there was
no difference in behavior active/inactive.
There was just no such thing as being
"active".  And the same is true still, when
t-m-mode is disabled.

We can agree to disagree about this.  (Or we
can just disagree without agreement that we
disagree.)

bug#51927: [External] : Re: bug#51927: 27.2; Rename `highlight-nonselected-windows'

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "51927@debbugs.gnu.org" <51927@debbugs.gnu.org>
> Date: Thu, 18 Nov 2021 17:28:35 +0000
> 
> "When Transient Mark Mode is off, immediately repeating this
> command activates 'transient-mark-mode' temporarily."
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That's immaterial: from the user's POV the mode is still disabled,
once the region is deactivated.  That it is temporarily enabled is an
implementation detail.

So the important part is that the region is active, not whether
transient-mark-mode is on or off.  And that's what I made the doc
string to say.

> There was no such talk of mark activation
> before t-m-mode was added.

So what? the manual now is full of such talk, so denying its
importance is silly and doesn't help users.

bug#51927: 27.2; Rename `highlight-nonselected-windows'

[Juri Linkov]

> This variable seems poorly named, in more ways than one.  Could we
> consider renaming it (by aliasing and perhaps deprecating the old name)?

I agree that it's poorly named.  In bug#49844 we are developing a new feature
for which the most suitable name would be `highlight-nonselected-windows' -
it will highlight nonselected windows by changing their background color.
Unfortunately this name is already occupied by this unrelated variable.
But like Eli said it's too late to rename this variable.

bug#51927: [External] : Re: bug#51927: 27.2; Rename `highlight-nonselected-windows'

[Drew Adams]

> > This variable seems poorly named, in more ways than one.  Could we
> > consider renaming it (by aliasing and perhaps deprecating the old name)?
> 
> I agree that it's poorly named.  In bug#49844 we are
> developing a new feature for which the most suitable
> name would be `highlight-nonselected-windows' -
> it will highlight nonselected windows by changing
> their background color. Unfortunately this name is
> already occupied by this unrelated variable.

Use a less ideal name for it, e.g. something
like: change-window-backgrounds or
highlight-windows-not-selected.

> But like Eli said it's too late to rename this variable.

It's too late to remove that name from this option.
Which means it's not possible to use that same
name for some other option (e.g. your new one).

But it's not too late to alias the old option,
providing it another, better name.  And it's not
too late to favor that better name in doc, help,
apropos, etc.

It's fine to use "too late" for incompatible
changes, when it's really too late or impossible
to change something.

That really _doesn't_ apply, logically, to being
able to provide a better name by aliasing, and it
really _shouldn't_ be applied.