bug#58176: 29.0.50; mouse-set-point region flicker with highlight-nonselected-windows=t and same buffer in two windows

[Eli Zaretskii <eliz@gnu.org>]

> From: <miha@kamnitnik.top>
> Cc: 58176@debbugs.gnu.org
> Date: Fri, 30 Sep 2022 23:15:31 +0200
> 
> >> Well, maybe we could try a bit harder to reduce the flicker for ordinary
> >> non-dragging mouse-1 clicks. One idea could be to prevent down-mouse-1
> >> from activating mark until the region becomes non-zero length, so
> >> something like this patch.
> >
> > Thanks, but this is exactly the opposite of the behavior we want.  We
> > currently make a significant effort to show regions of zero length.
> 
> (I'm assuming that by "show regions of zero length", you mean that the
> "Copy text" toolbar icon is enabled.)

No, we actually attempt to display zero-length regions in the text.

> I hope I'm not arguing semantics too much, but my patch doesn't actually
> hide an (active) region of zero length, it prevents one from being
> activated.

Which is against the behavior we want, I think.

> It only prevents it in the specific case of a non-dragging mouse-1
> click, which makes quite a lot sense to me. The current behaviour of a
> non-dragging mouse-1 click is that the zero-length region is only active
> for the duration of the mouse button being held down. Once the button is
> released, the zero-length region is deactivated, which makes it not very
> useful, as far as I can see.

It is useful in the much more frequent use case where the user then
drags the mouse.

> If you want to create a zero-length region that stays active after
> releasing mouse-1, you have to drag the mouse a little first to make the
> region length non-zero and then drag the mouse back to the starting
> position to make the region length zero again. This use case is still
> supported by my patch.
> 
> (Perhaps I missed some use-cases of a zero-length region active during a
> non-dragging mouse-1 button hold. If you know any, please let me know
> about them.)
> 
> This, together with the fact that it reduces the "flicker" from the
> original message, makes me insist on the patch.

I still insist that what you propose is the opposite of the behavior
we want.