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

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

[miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 3374 bytes --]

emacs -q:

1. (setq highlight-nonselected-windows t)
2. 'C-x 2'
3. Click with mouse-1 somewhere to move point

Notice that for the duration mouse-1 being held down for the click,
region highlighting appears in the non-selected window. Usually the
click is short so the region only appears for a short time, which can be
perceived as a somewhat annoying flicker.

In GNU Emacs 29.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
 3.24.34, cairo version 1.17.6) of 2022-09-29 built on miha-pc
Repository revision: 0edd7770e0ce70cac59f239134962d10f48dec79
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Arch Linux

Configured using:
 'configure -C --prefix=/usr --without-libsystemd
 --enable-checking=yes,glyphs --enable-check-lisp-object-type
 'CFLAGS=-O0 -g3''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11
XDBE XIM XINPUT2 XPM GTK3 ZLIB

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

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-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
  blink-cursor-mode: t
  buffer-read-only: 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 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 mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date subr-x
cl-loaddefs cl-lib rmc iso-transl tooltip 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 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 lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 38907 4530)
 (symbols 48 5110 0)
 (strings 32 13189 1629)
 (string-bytes 1 377949)
 (vectors 16 9355)
 (vector-slots 8 148819 10571)
 (floats 8 25 24)
 (intervals 56 348 5)
 (buffers 1000 11))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

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

[Eli Zaretskii]

> Date: Thu, 29 Sep 2022 19:38:28 +0200
> From: miha--- via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 1. (setq highlight-nonselected-windows t)
> 2. 'C-x 2'
> 3. Click with mouse-1 somewhere to move point
> 
> Notice that for the duration mouse-1 being held down for the click,
> region highlighting appears in the non-selected window. Usually the
> click is short so the region only appears for a short time, which can be
> perceived as a somewhat annoying flicker.

It's a direct consequence of the fact that point is different in each
window.  I don't see any bug here, FWIW.  If you don't like this side
effect of highlight-nonselected-windows, then don't set it non-nil.

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

[miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 29 Sep 2022 19:38:28 +0200
>> From: miha--- via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> 1. (setq highlight-nonselected-windows t)
>> 2. 'C-x 2'
>> 3. Click with mouse-1 somewhere to move point
>> 
>> Notice that for the duration mouse-1 being held down for the click,
>> region highlighting appears in the non-selected window. Usually the
>> click is short so the region only appears for a short time, which can be
>> perceived as a somewhat annoying flicker.
>
> It's a direct consequence of the fact that point is different in each
> window.  I don't see any bug here, FWIW.  If you don't like this side
> effect of highlight-nonselected-windows, then don't set it non-nil.

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.

diff --git a/lisp/mouse.el b/lisp/mouse.el
index e38a4f8a71..a0f48de923 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -1729,7 +1729,7 @@ mouse-drag-track
                           '(only)
                         (cons 'only transient-mark-mode)))
           (let ((range (mouse-start-end start-point start-point click-count)))
-            (push-mark (nth 0 range) t t)
+            (push-mark (nth 0 range) t (not (eql (nth 0 range) (nth 1 range))))
             (goto-char (nth 1 range)))
 
           (setf (terminal-parameter nil 'mouse-drag-start) start-event)
@@ -1794,7 +1794,10 @@ mouse--drag-set-mark-and-point
 	   (goto-char beg))
 	  (t
 	   (set-mark beg)
-	   (goto-char end)))))
+	   (goto-char end)))
+    (unless mark-active
+      (unless (eql beg end)
+        (activate-mark 'no-tmm)))))
 
 ;; Commands to handle xterm-style multiple clicks.
 (defun mouse-skip-word (dir)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

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

[Eli Zaretskii]

> From: <miha@kamnitnik.top>
> Cc: 58176@debbugs.gnu.org
> Date: Thu, 29 Sep 2022 23:09:37 +0200
> 
> > It's a direct consequence of the fact that point is different in each
> > window.  I don't see any bug here, FWIW.  If you don't like this side
> > effect of highlight-nonselected-windows, then don't set it non-nil.
> 
> 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.

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

[miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: <miha@kamnitnik.top>
>> Cc: 58176@debbugs.gnu.org
>> Date: Thu, 29 Sep 2022 23:09:37 +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.)

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.

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. For example, pressing M-w or C-w during the
mouse button being held down doesn't seem to work on the correct
zero-length region and you can't click on the "Copy text" toolbar icon
(maybe you could in a multi-pointer setup, but that's a pretty bizarre
use-case).

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.

Best regards.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

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

[Eli Zaretskii]

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

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

[Eli Zaretskii]

> From: <miha@kamnitnik.top>
> Cc: 58176@debbugs.gnu.org
> Date: Sat, 01 Oct 2022 12:00:43 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> (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.
> 
> Maybe there's something obvious I'm missing, but in a graphical emacs
> -q, I can't see a zero length active region in the text at all. That is,
> after activating it with C-SPC or a non-dragging mouse-1 button press, I
> can't see a single pixel around point changing to indicate the region. I
> even tried it after considerably enlarging the font with 'C-x C-+ + + +
> + ...'.
> 
> (On the other hand, zero-length rectangular regions, created with C-x
> SPC, are properly indicated with a thin vertical line, but we aren't
> talking about rectangular regions here.)

I was talking about what we show for zero-width rectangular regions,
yes.

> In essence, my patch tries to make behaviour of mouse-1 region
> activation more similar to C-M-mouse-1 rectangular region activation.

Sorry, I'm not convinced.

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

[miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 6271 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

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

Maybe there's something obvious I'm missing, but in a graphical emacs
-q, I can't see a zero length active region in the text at all. That is,
after activating it with C-SPC or a non-dragging mouse-1 button press, I
can't see a single pixel around point changing to indicate the region. I
even tried it after considerably enlarging the font with 'C-x C-+ + + +
+ ...'.

(On the other hand, zero-length rectangular regions, created with C-x
SPC, are properly indicated with a thin vertical line, but we aren't
talking about rectangular regions here.)

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

This use case is, of course, still supported by my patch.

I was talking about the very specific zero-length region, active for the
duration of a non-dragging mouse-1 button being held down. My patch
affects only this specific use-case

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

Another unrelated thing to consider is the current behaviour of
clicking/dragging C-M-mouse-1. It doesn't activate a rectangular region
until the user drags C-M-mouse-1. In fact, if the user only does a
non-dragging C-M-mouse-1 click, the rectangular region is never
activated, only the point moves. You can try experimenting with
C-M-mouse-1 and see, if this is really the opposite of the behaviour we
want.

In essence, my patch tries to make behaviour of mouse-1 region
activation more similar to C-M-mouse-1 rectangular region activation.

(Emacs build info follows, since the non-display of zero-length
non-rectangular regions in the text could be dependent on build
configuration.)

In GNU Emacs 29.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
 3.24.34, cairo version 1.17.6) of 2022-09-29 built on miha-pc
Repository revision: 0edd7770e0ce70cac59f239134962d10f48dec79
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Arch Linux

Configured using:
 'configure -C --prefix=/usr --without-libsystemd
 --enable-checking=yes,glyphs --enable-check-lisp-object-type
 'CFLAGS=-O0 -g3''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11
XDBE XIM XINPUT2 XPM GTK3 ZLIB

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

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-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
  blink-cursor-mode: t
  buffer-read-only: 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 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 mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date subr-x
cl-loaddefs cl-lib rmc iso-transl tooltip 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 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 lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 38907 4530)
 (symbols 48 5110 0)
 (strings 32 13189 1629)
 (string-bytes 1 377949)
 (vectors 16 9355)
 (vector-slots 8 148819 10571)
 (floats 8 25 24)
 (intervals 56 348 5)
 (buffers 1000 11))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]