bug#56662: 29.0.50; Funny region highlights when highlight-nonselected-windows is t

["Kévin Le Gouguec" <kevin.legouguec@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> From: Visuwesh <visuweshm@gmail.com>
>> >> Date: Wed, 20 Jul 2022 17:05:11 +0530
>> >> 
>> >>     1. emacs -Q
>> >>     2. Visit a longish file.
>> >>     3. C-x 3 and scroll up in any of the window.
>> >>     4. M-: (setq highlight-nonselected-windows t) RET.
>> >>     5. Create an active region and compare the highlighting.
>> >
>> > What is wrong with this behavior?  In each window the region between
>> > the mark and point is highlighted, as you requested by turning on that
>> > option.
>> >
>> > What am I missing?
>> 
>> Since the point is local to the window, it felt natural that the region
>> would be too.
>
> And it is.  But the mark originally is the same.  If you switch to the
> other window and set its mark in a different place, you will have
> completely separate and independent highlighting.

Mm.  I was very interested in your answer because a big pet peeve of
mine is not being able to activate a region in window-1, move to
window-2 showing another portion of the same buffer, and work on that
second portion while stealing glances at what I highlighted in window-1.

Now I see that if I hit C-SPC in window-2 I can indeed change the
highlighting in that window while keeping the highlighting in window-1
untouched, however…

(1) Haven't been able to find a reproducible recipe, but on occasion,
    when hitting C-SPC in window-2, the highlighting in window-1
    sometimes "snaps" and updates to match the mark I just set in
    window-2.

(2) AFAICT I have to keep a region activated in window-2 for window-1 to
    retain its highlighting.

    For the use-case described above though, the first thing I do when
    moving to window-2 is C-g to deactivate the region, and AFAICT that
    deactivates the highlighting in window-2.

    I kind of wish there was a third value for this user option;
    e.g. (setq highlight-nonselected-windows 'lazy) to signify "keep
    highlighting as-is when leaving the window, and never update it
    until the window becomes current again"? 🤷

    Not sure how well-defined that proposal is though (e.g. what should
    happen when part of the highlighted region is erased); and I have no
    idea how much work it would be to actually implement that.

If any of (2) makes sense, could this bug remain open as a wishlist
item?  It's a bit frustrating to (a) highlight part of a window I want
to glance at for reference (b) move to another window to work on another
location (c) lose the highlighting because that location "just happens"
to be in the same buffer.