bug#64993: 29.1; scroll-other-window breaks global-hl-line-sticky-flag

bug#64993: 29.1; scroll-other-window breaks global-hl-line-sticky-flag

[Spencer Baugh]

1. emacs -Q
2. Eval
(setq global-hl-line-sticky-flag t)
(global-hl-line-mode)
3. C-h n  (to open up a buffer with lots of text for scrolling)
4. C-x 3
5. Note the line with point is highlighted in both windows
6. scroll-other-window
7. Note the line with point is no longer highlighted in the other window


In GNU Emacs 29.1 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2023-07-29 built on
 igm-qws-u22796a
Repository revision: cf24c7ac7608f41078fd2761c856892d5853b676
Repository branch: my-emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Rocky Linux 8.8 (Green Obsidian)

Configured using:
 'configure --config-cache --with-x-toolkit=lucid
 --with-gif=ifavailable'

Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM
XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr dabbrev emacsbug message mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date subr-x
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)

Memory information:
((conses 16 65049 9513)
 (symbols 48 9526 0)
 (strings 32 23879 1913)
 (string-bytes 1 700788)
 (vectors 16 9398)
 (vector-slots 8 149935 13318)
 (floats 8 37 28)
 (intervals 56 256 8)
 (buffers 976 11))

bug#64993: 29.1; scroll-other-window breaks global-hl-line-sticky-flag

[Eli Zaretskii]

tags 64993 notabug
thanks

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Tue, 01 Aug 2023 10:59:29 -0400
> 
> 
> 1. emacs -Q
> 2. Eval
> (setq global-hl-line-sticky-flag t)
> (global-hl-line-mode)
> 3. C-h n  (to open up a buffer with lots of text for scrolling)
> 4. C-x 3
> 5. Note the line with point is highlighted in both windows
> 6. scroll-other-window
> 7. Note the line with point is no longer highlighted in the other window

That's a feature, and you activated it by setting
global-hl-line-sticky-flag:

  (defcustom global-hl-line-sticky-flag nil
    "Non-nil means the Global HL-Line mode highlight appears in all windows.

  (define-minor-mode global-hl-line-mode
    "Toggle line highlighting in all buffers (Global Hl-Line mode).

  If `global-hl-line-sticky-flag' is non-nil, Global Hl-Line mode
  highlights the line about the current buffer's point in all live
  windows.

So what you describe as "the line with point is no longer highlighted
in the other window" actually happens before the point in the selected
window is no longer visible in the other window, and thus neither is
the highlighted line.

This is not a bug.

bug#64993: 29.1; scroll-other-window breaks global-hl-line-sticky-flag

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:
> tags 64993 notabug
> thanks
>
>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Tue, 01 Aug 2023 10:59:29 -0400
>> 
>> 
>> 1. emacs -Q
>> 2. Eval
>> (setq global-hl-line-sticky-flag t)
>> (global-hl-line-mode)
>> 3. C-h n  (to open up a buffer with lots of text for scrolling)
>> 4. C-x 3
>> 5. Note the line with point is highlighted in both windows
>> 6. scroll-other-window
>> 7. Note the line with point is no longer highlighted in the other window
>
> That's a feature, and you activated it by setting
> global-hl-line-sticky-flag:
>
>   (defcustom global-hl-line-sticky-flag nil
>     "Non-nil means the Global HL-Line mode highlight appears in all windows.
>
>   (define-minor-mode global-hl-line-mode
>     "Toggle line highlighting in all buffers (Global Hl-Line mode).
>
>   If `global-hl-line-sticky-flag' is non-nil, Global Hl-Line mode
>   highlights the line about the current buffer's point in all live
>   windows.
>
> So what you describe as "the line with point is no longer highlighted
> in the other window" actually happens before the point in the selected
> window is no longer visible in the other window, and thus neither is
> the highlighted line.
>
> This is not a bug.

Oops, sorry, my reproduction was confusing, I made an error in having
both windows contain the same buffer.  They should obviously contain
different buffers otherwise your response is correct.

Try again with:

1. emacs -Q
2. Eval
(setq global-hl-line-sticky-flag t)
(global-hl-line-mode)
3. C-x 3  (make two windows)
4. C-h n  (make one window contain NEWS)
5. C-x o  (switch to the other window)
6. Note the line with point is highlighted in both windows
6. scroll-other-window
7. Note the line with point is no longer highlighted in the NEWS window

bug#64993: 29.1; scroll-other-window breaks global-hl-line-sticky-flag

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: 64993@debbugs.gnu.org
> Date: Tue, 01 Aug 2023 12:28:14 -0400
> 
> 1. emacs -Q
> 2. Eval
> (setq global-hl-line-sticky-flag t)
> (global-hl-line-mode)
> 3. C-x 3  (make two windows)
> 4. C-h n  (make one window contain NEWS)
> 5. C-x o  (switch to the other window)
> 6. Note the line with point is highlighted in both windows
> 6. scroll-other-window
> 7. Note the line with point is no longer highlighted in the NEWS window

And why is this a bug?  global-hl-line-sticky-flag non-nil means the
highlight in non-selected windows is not removed:

  (defun global-hl-line-maybe-unhighlight ()
    "Maybe deactivate the Global-Hl-Line overlay on the current line.
  Specifically, when `global-hl-line-sticky-flag' is nil deactivate
  all such overlays in all buffers except the current one."

So "C-x o" leaves the highlighting overlay in the window that was
selected, and it will remain at the same position until that window
becomes selected again, because highlighting is moved only in the
selected window.

If you don't like these effects of global-hl-line-sticky-flag, then
don't use it.  It's off by default, presumably due to these effects.

bug#64993: 29.1; scroll-other-window breaks global-hl-line-sticky-flag

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: 64993@debbugs.gnu.org
>> Date: Tue, 01 Aug 2023 12:28:14 -0400
>> 
>> 1. emacs -Q
>> 2. Eval
>> (setq global-hl-line-sticky-flag t)
>> (global-hl-line-mode)
>> 3. C-x 3  (make two windows)
>> 4. C-h n  (make one window contain NEWS)
>> 5. C-x o  (switch to the other window)
>> 6. Note the line with point is highlighted in both windows
>> 6. scroll-other-window
>> 7. Note the line with point is no longer highlighted in the NEWS window
>
> And why is this a bug?

Because it contradicts the docstring and the intent of the flag, which
is to have a highlight for point in all windows.

> global-hl-line-sticky-flag non-nil means the
> highlight in non-selected windows is not removed:
>   (defun global-hl-line-maybe-unhighlight ()
>     "Maybe deactivate the Global-Hl-Line overlay on the current line.
>   Specifically, when `global-hl-line-sticky-flag' is nil deactivate
>   all such overlays in all buffers except the current one."
>
> So "C-x o" leaves the highlighting overlay in the window that was
> selected, and it will remain at the same position until that window
> becomes selected again, because highlighting is moved only in the
> selected window.

Yes, this is the implementation, and you have explained how it is buggy.

> If you don't like these effects of global-hl-line-sticky-flag, then
> don't use it.  It's off by default, presumably due to these effects.

Things which are off by default can still be buggy.

bug#64993: 29.1; scroll-other-window breaks global-hl-line-sticky-flag

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: 64993@debbugs.gnu.org
> Date: Tue, 01 Aug 2023 13:13:36 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > global-hl-line-sticky-flag non-nil means the
> > highlight in non-selected windows is not removed:
> >   (defun global-hl-line-maybe-unhighlight ()
> >     "Maybe deactivate the Global-Hl-Line overlay on the current line.
> >   Specifically, when `global-hl-line-sticky-flag' is nil deactivate
> >   all such overlays in all buffers except the current one."
> >
> > So "C-x o" leaves the highlighting overlay in the window that was
> > selected, and it will remain at the same position until that window
> > becomes selected again, because highlighting is moved only in the
> > selected window.
> 
> Yes, this is the implementation, and you have explained how it is buggy.

You may think it's "buggy", but the doc string describes the "buggy"
behavior ("deactivate the overlays in all buffers except the current
one only if the flag is nil").  So it's at least documented, and one
could argue that this is the intended behavior.

> > If you don't like these effects of global-hl-line-sticky-flag, then
> > don't use it.  It's off by default, presumably due to these effects.
> 
> Things which are off by default can still be buggy.

They can, yes.

bug#64993: 29.1; scroll-other-window breaks global-hl-line-sticky-flag

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: 64993@debbugs.gnu.org
>> Date: Tue, 01 Aug 2023 13:13:36 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > global-hl-line-sticky-flag non-nil means the
>> > highlight in non-selected windows is not removed:
>> >   (defun global-hl-line-maybe-unhighlight ()
>> >     "Maybe deactivate the Global-Hl-Line overlay on the current line.
>> >   Specifically, when `global-hl-line-sticky-flag' is nil deactivate
>> >   all such overlays in all buffers except the current one."
>> >
>> > So "C-x o" leaves the highlighting overlay in the window that was
>> > selected, and it will remain at the same position until that window
>> > becomes selected again, because highlighting is moved only in the
>> > selected window.
>> 
>> Yes, this is the implementation, and you have explained how it is buggy.
>
> You may think it's "buggy", but the doc string describes the "buggy"
> behavior ("deactivate the overlays in all buffers except the current
> one only if the flag is nil").  So it's at least documented, and one
> could argue that this is the intended behavior.

global-hl-line-maybe-unhighlight is an internal function of
global-hl-line-mode anyway, why and how would a user ever look at its
docstring?

They'd be more likely to look at global-hl-line-mode's docstring, which
explicitly says:

  If ‘global-hl-line-sticky-flag’ is non-nil, Global Hl-Line mode
  highlights the line about the current buffer’s point in all live
  windows.

It says nothing about "but if point moves in a non-current buffer, the
highlighting stops working".

Arguing about this is rather pointless since I assume you would accept a
patch which fixes the behavior to work even if point moves in a
non-current buffer.  I just want to remove the notabug marker on this
bug, and I'll get to it eventually, maybe.

>
>> > If you don't like these effects of global-hl-line-sticky-flag, then
>> > don't use it.  It's off by default, presumably due to these effects.
>> 
>> Things which are off by default can still be buggy.
>
> They can, yes.

bug#64993: 29.1; scroll-other-window breaks global-hl-line-sticky-flag

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: 64993@debbugs.gnu.org
> Date: Tue, 01 Aug 2023 13:32:55 -0400
> 
> Arguing about this is rather pointless since I assume you would accept a
> patch which fixes the behavior to work even if point moves in a
> non-current buffer.

I'm not sure I will, because I'm not sure I agree that the current
behavior is incorrect.  I understand that you don't like it, but
that's all.

bug#64993: 29.1; scroll-other-window breaks global-hl-line-sticky-flag

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: 64993@debbugs.gnu.org
>> Date: Tue, 01 Aug 2023 13:32:55 -0400
>> 
>> Arguing about this is rather pointless since I assume you would accept a
>> patch which fixes the behavior to work even if point moves in a
>> non-current buffer.
>
> I'm not sure I will, because I'm not sure I agree that the current
> behavior is incorrect.  I understand that you don't like it, but
> that's all.

Fine, can we ask an actual user of this feature whether they think this
is a bug or not?  Would that convince you that there's a bug here?  Or
what else would convince you?

Again, this behavior directly contradicts the docstring, and only
vaguely is allowed by the docstring of a random internal function that
you presumably had to read the source to find.

bug#64993: 29.1; scroll-other-window breaks global-hl-line-sticky-flag

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: 64993@debbugs.gnu.org
> Date: Tue, 01 Aug 2023 13:46:26 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Spencer Baugh <sbaugh@janestreet.com>
> >> Cc: 64993@debbugs.gnu.org
> >> Date: Tue, 01 Aug 2023 13:32:55 -0400
> >> 
> >> Arguing about this is rather pointless since I assume you would accept a
> >> patch which fixes the behavior to work even if point moves in a
> >> non-current buffer.
> >
> > I'm not sure I will, because I'm not sure I agree that the current
> > behavior is incorrect.  I understand that you don't like it, but
> > that's all.
> 
> Fine, can we ask an actual user of this feature whether they think this
> is a bug or not?  Would that convince you that there's a bug here?  Or
> what else would convince you?

I don't need to be convinced.  You want a new behavior, so please
implement it as new behavior, not a change in the old one.  For
example, a new, non-nil and non-t value of the sticky flag, which will
cause the mode to behave however you like it to behave.  Then all this
argument is completely unnecessary (as it was from the get-go).