GNU bug report logs - #14744
24.3.50; Flickering mouse-face on process output

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14744 in the body.
You can then email your comments to 14744 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Flickering mouse-face on process output
Date: Sat, 29 Jun 2013 01:10:51 +0100 (BST)

    emacs -q
    C-x 2
    M-x shell RET
    cat /dev/urandom RET
    C-x o
    # Move mouse on one of the buttons so the face changes to highlight

The button flickers here.

Xorg and GTK+ 2.24.10 on GNU/Linux and current Emacs trunk.  This issue
is easily reproducible on older Emacsen, such as 24.3 or 23.4.

        Christopher

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <christopher <at> ch.ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Sat, 29 Jun 2013 10:46:36 +0300

> From: Christopher Schmidt <christopher <at> ch.ristopher.com>
> Date: Sat, 29 Jun 2013 01:10:51 +0100 (BST)
> 
>     emacs -q
>     C-x 2
>     M-x shell RET
>     cat /dev/urandom RET
>     C-x o
>     # Move mouse on one of the buttons so the face changes to highlight
> 
> The button flickers here.
> 
> Xorg and GTK+ 2.24.10 on GNU/Linux and current Emacs trunk.  This issue
> is easily reproducible on older Emacsen, such as 24.3 or 23.4.

Redisplay of a window always includes redisplay of the tool bar.  The
latter involves drawing the buttons, and then applying the depressed
faced to the button that the mouse pointer hovers above.  That is what
you see, I believe.  So why do you consider that a bug?

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Sat, 29 Jun 2013 10:47:15 +0100 (BST)

Eli Zaretskii <eliz <at> gnu.org> writes:
> Redisplay of a window always includes redisplay of the tool bar.  The
> latter involves drawing the buttons, and then applying the depressed
> faced to the button that the mouse pointer hovers above.  That is what
> you see, I believe.  So why do you consider that a bug?

I was not talking about the tool bar.  I was talking about the buttons
in the other window of Emacs, such as

    Emacs Tutorial	Learn basic keystroke commands
    ^^^^^^^^^^^^^^
    Emacs Guided Tour	Overview of Emacs features at gnu.org
    ^^^^^^^^^^^^^^^^^
    View Emacs Manual	View the Emacs manual using Info
    ^^^^^^^^^^^^^^^^^
I call them buttons because they were created using insert-button.  This
does not exactly matter here.  Any text with a mouse-face will do.

I see actual flickering.  That is, I move my mouse cursor over the text
and expect the text face to be highlight as long as the cursor is
somewhere in between the continuous fragment of text.  It is not.  The
actual face is switching between two faces, one of them being highlight.

I am able to reproduce the bug on different GNU/Linux/Xorg/GTK 2.*
boxes.  On a fast machine the flickering is barely noticeable, on a slow
one the faces flickers with a high frequency which is very distracting
and mildly annoying.

        Christopher

Message #14 received at 14744 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: 14744 <at> debbugs.gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Sat, 29 Jun 2013 12:35:27 +0200

On Sat, 29 Jun 2013 10:47:15 +0100 (BST) Christopher Schmidt <christopher <at> ch.ristopher.com> wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>> Redisplay of a window always includes redisplay of the tool bar.  The
>> latter involves drawing the buttons, and then applying the depressed
>> faced to the button that the mouse pointer hovers above.  That is what
>> you see, I believe.  So why do you consider that a bug?
>
> I was not talking about the tool bar.  I was talking about the buttons
> in the other window of Emacs, such as
>
>     Emacs Tutorial	Learn basic keystroke commands
>     ^^^^^^^^^^^^^^
>     Emacs Guided Tour	Overview of Emacs features at gnu.org
>     ^^^^^^^^^^^^^^^^^
>     View Emacs Manual	View the Emacs manual using Info
>     ^^^^^^^^^^^^^^^^^
> I call them buttons because they were created using insert-button.  This
> does not exactly matter here.  Any text with a mouse-face will do.
>
> I see actual flickering.  That is, I move my mouse cursor over the text
> and expect the text face to be highlight as long as the cursor is
> somewhere in between the continuous fragment of text.  It is not.  The
> actual face is switching between two faces, one of them being highlight.

I've noticed this for a long time (I can't remember when I first noticed
it, but it was certainly many months, perhaps years ago); I think I
always see it when the *shell* buffer is rapidly outputting data from
building Emacs, and a Gnus *Summary* buffer is in the other window.

Steve Berman

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <christopher <at> ch.ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Sat, 29 Jun 2013 14:41:35 +0300

> From: Christopher Schmidt <christopher <at> ch.ristopher.com>
> Date: Sat, 29 Jun 2013 10:47:15 +0100 (BST)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > Redisplay of a window always includes redisplay of the tool bar.  The
> > latter involves drawing the buttons, and then applying the depressed
> > faced to the button that the mouse pointer hovers above.  That is what
> > you see, I believe.  So why do you consider that a bug?
> 
> I was not talking about the tool bar.  I was talking about the buttons
> in the other window of Emacs, such as
> 
>     Emacs Tutorial	Learn basic keystroke commands
>     ^^^^^^^^^^^^^^
>     Emacs Guided Tour	Overview of Emacs features at gnu.org
>     ^^^^^^^^^^^^^^^^^
>     View Emacs Manual	View the Emacs manual using Info
>     ^^^^^^^^^^^^^^^^^

That doesn't matter.  In the situation you described, Emacs redisplays
all the windows, which involves redrawing the mouse highlight of these
buttons.

> I see actual flickering.  That is, I move my mouse cursor over the text
> and expect the text face to be highlight as long as the cursor is
> somewhere in between the continuous fragment of text.  It is not.  The
> actual face is switching between two faces, one of them being highlight.

Because we redraw the window.

Redisplay optimization that refrains from redrawing windows other than
the one whose buffer and mode line get updated was never implemented.

For the record, what is the real-life use case where this matters?

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Sat, 29 Jun 2013 13:56:53 +0100 (BST)

Eli Zaretskii <eliz <at> gnu.org> writes:
> For the record, what is the real-life use case where this matters?

The one Stephen described in <8761wxfbm8.fsf <at> rosalinde.fritz.box>.

        Christopher

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <christopher <at> ch.ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Sat, 29 Jun 2013 17:45:14 +0300

> From: Christopher Schmidt <christopher <at> ch.ristopher.com>
> Date: Sat, 29 Jun 2013 13:56:53 +0100 (BST)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > For the record, what is the real-life use case where this matters?
> 
> The one Stephen described in <8761wxfbm8.fsf <at> rosalinde.fritz.box>.

Thanks.  For the record, here's what happens:

  . comint-output-filter moves the comint-last-prompt-overlay overlay

  . This eventually calls modify_overlay, which has this code:

     /* If BUF is visible, consider updating the display if ...  */
     if (buffer_window_count (buf) > 0)
       {
	 /* ... it's visible in other window than selected,  */
	 if (buf != XBUFFER (XWINDOW (selected_window)->contents))
	   windows_or_buffers_changed = 1;
	 /* ... or if we modify an overlay at the end of the buffer
	    and so we cannot be sure that window end is still valid.  */
	 else if (end >= ZV && start <= ZV)
	   windows_or_buffers_changed = 1;
       }

    In our case, the overlay is at the end of the buffer, so the last
    'else if' clause fires, and sets windows_or_buffers_changed to a
    non-zero value.

  . When redisplay sees a non-zero value in windows_or_buffers_changed,
    it forces a thorough redisplay of all the windows, because having
    the window end invalid generally means the window configuration
    might have changed.

I guess one way of fixing this problem would be to modify comint.el
not to use overlays for this purpose.

Message #26 received at 14744 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Christopher Schmidt <christopher <at> ch.ristopher.com>, 14744 <at> debbugs.gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Sat, 29 Jun 2013 11:08:51 -0400

>> emacs -q
>> C-x 2
>> M-x shell RET
>> cat /dev/urandom RET
>> C-x o
>> # Move mouse on one of the buttons so the face changes to highlight
>> The button flickers here.
>> Xorg and GTK+ 2.24.10 on GNU/Linux and current Emacs trunk.  This issue
>> is easily reproducible on older Emacsen, such as 24.3 or 23.4.

> Redisplay of a window always includes redisplay of the tool bar.  The
> latter involves drawing the buttons, and then applying the depressed
> faced to the button that the mouse pointer hovers above.  That is what
> you see, I believe.  So why do you consider that a bug?

I consider it a bug because some part of the screen flickers.
I understand the underlying technical reason why Emacs does that, but
it's still a misfeature.  Ideally we should refrain from redrawing
things that haven't changed, and the second best fix is to use some kind
of double buffering so the intermediate "drawn but not depressed" state
is kept hidden.


        Stefan

Message #29 received at 14744 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: christopher <at> ch.ristopher.com, 14744 <at> debbugs.gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Sat, 29 Jun 2013 18:16:30 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Christopher Schmidt <christopher <at> ch.ristopher.com>,  14744 <at> debbugs.gnu.org
> Date: Sat, 29 Jun 2013 11:08:51 -0400
> 
> I consider it a bug because some part of the screen flickers.
> I understand the underlying technical reason why Emacs does that, but
> it's still a misfeature.

See my other message, where I explained the reasons for this specific
case.  Not surprisingly, it's use of overlays.

> Ideally we should refrain from redrawing things that haven't
> changed

We do, but not with mouse-highlight.

> the second best fix is to use some kind of double buffering so the
> intermediate "drawn but not depressed" state is kept hidden.

I admit that I have no idea what you have in mind here, but patches
are most welcome.

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Sat,  3 Aug 2013 10:41:23 +0100 (BST)

Eli Zaretskii <eliz <at> gnu.org> writes:
> Thanks.  For the record, here's what happens:
[...]

Thanks for the thorough explanation of what's going on.

> I guess one way of fixing this problem would be to modify comint.el
> not to use overlays for this purpose.

This works around the underlying issue.  There are other real use cases
in which, due to whatever reason, a redisplay is enforced and this
artifact appears.

        Christopher

Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <christopher <at> ch.ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Sat, 03 Aug 2013 13:36:53 +0300

> From: Christopher Schmidt <christopher <at> ch.ristopher.com>
> Date: Sat,  3 Aug 2013 10:41:23 +0100 (BST)
> 
> > I guess one way of fixing this problem would be to modify comint.el
> > not to use overlays for this purpose.
> 
> This works around the underlying issue.  There are other real use cases
> in which, due to whatever reason, a redisplay is enforced and this
> artifact appears.

In the absence of a solution for all of them, fixing some of them
would be good nevertheless.  comint is a widely used infrastructure,
so modifying it is likely to solve quite a few of those cases.

Btw, not every case that forces a redisplay cycle actually redraws the
screen.  Emacs display engine has the last line of defense, in that,
after the display engine determines what should be on the screen, it
compares that with what actually is on the screen, and only redraws
the parts that are different.  However, places which have
mouse-highlight are always redrawn (because mouse pointer can move
asynchronously and independently of what Emacs does).

Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Sat,  3 Aug 2013 13:25:39 +0100 (BST)

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:
> In the absence of a solution for all of them, fixing some of them
> would be good nevertheless.  comint is a widely used infrastructure,
> so modifying it is likely to solve quite a few of those cases.

How about this:

[Message part 2 (text/x-diff, inline)]

--- lisp/comint.el
+++ lisp/comint.el
@@ -636,7 +636,7 @@
   (setq-local comint-last-input-start (point-min-marker))
   (setq-local comint-last-input-end (point-min-marker))
   (setq-local comint-last-output-start (make-marker))
-  (make-local-variable 'comint-last-prompt-overlay)
+  (make-local-variable 'comint-last-prompt)
   (make-local-variable 'comint-prompt-regexp)        ; Don't set; default
   (make-local-variable 'comint-input-ring-size)      ; ...to global val.
   (make-local-variable 'comint-input-ring)
@@ -1902,21 +1902,24 @@
   "If nil, Comint will interpret `carriage control' characters in output.
 See `comint-carriage-motion' for details.")
 
-;; When non-nil, this is an overlay over the last recognized prompt in
-;; the buffer; it is used when highlighting the prompt.
-(defvar comint-last-prompt-overlay nil)
+(defvar comint-last-prompt nil
+  "Markers pointing to the last prompt.
+If non-nil, a cons cell containing markers.  The car points to
+the start, the cdr to the end of the last prompt recognized.")
 
 (defun comint-snapshot-last-prompt ()
-  "`snapshot' any current `comint-last-prompt-overlay'.
-Freeze its attributes in place, even when more input comes along
-and moves the prompt overlay."
-  (when comint-last-prompt-overlay
-    (let ((inhibit-read-only t))
-      (with-silent-modifications
-        (add-text-properties
-         (overlay-start comint-last-prompt-overlay)
-         (overlay-end comint-last-prompt-overlay)
-         (overlay-properties comint-last-prompt-overlay))))))
+  "Snapshot the current `comint-last-prompt'.
+Freezes the `font-lock-face' text property in place."
+  (when comint-last-prompt
+    (with-silent-modifications
+      (add-text-properties
+       (car comint-last-prompt)
+       (cdr comint-last-prompt)
+       '(font-lock-face comint-highlight-prompt)))
+    ;; Reset comint-last-prompt so later on comint-output-filter does
+    ;; not remove the font-lock-face text property of the previous
+    ;; (this) prompt.
+    (setq comint-last-prompt nil)))
 
 (defun comint-carriage-motion (start end)
   "Interpret carriage control characters in the region from START to END.
@@ -2063,20 +2066,15 @@
                   (add-text-properties
                    prompt-start (point)
                    '(read-only t rear-nonsticky t front-sticky (read-only)))))
-	      (unless (and (bolp) (null comint-last-prompt-overlay))
-		;; Need to create or move the prompt overlay (in the case
-		;; where there is no prompt ((bolp) == t), we still do
-		;; this if there's already an existing overlay).
-		(if comint-last-prompt-overlay
-		    ;; Just move an existing overlay
-		    (move-overlay comint-last-prompt-overlay
-				  prompt-start (point))
-		  ;; Need to create the overlay
-		  (setq comint-last-prompt-overlay
-			(make-overlay prompt-start (point)))
-		  (overlay-put comint-last-prompt-overlay
-			       'font-lock-face 'comint-highlight-prompt))))
-
+	      (when comint-last-prompt
+		(remove-text-properties (car comint-last-prompt)
+					(cdr comint-last-prompt)
+					'(font-lock-face)))
+	      (setq comint-last-prompt
+		    (cons (copy-marker prompt-start) (point-marker)))
+	      (add-text-properties (car comint-last-prompt)
+				   (cdr comint-last-prompt)
+				   '(font-lock-face comint-highlight-prompt)))
 	    (goto-char saved-point)))))))
 
 (defun comint-preinput-scroll-to-bottom ()

[Message part 3 (text/plain, inline)]

        Christopher

Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <christopher <at> ch.ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Sat, 03 Aug 2013 15:41:46 +0300

> From: Christopher Schmidt <christopher <at> ch.ristopher.com>
> Date: Sat,  3 Aug 2013 13:25:39 +0100 (BST)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > In the absence of a solution for all of them, fixing some of them
> > would be good nevertheless.  comint is a widely used infrastructure,
> > so modifying it is likely to solve quite a few of those cases.
> 
> How about this:

Looks fine to me, although I just skimmed through it.  Does it solve
the problem?

Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Sat,  3 Aug 2013 13:56:48 +0100 (BST)

Eli Zaretskii <eliz <at> gnu.org> writes:
> Looks fine to me, although I just skimmed through it.  Does it solve
> the problem?

Yes, it does.

        Christopher

Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <christopher <at> ch.ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Sat, 03 Aug 2013 16:12:14 +0300

> From: Christopher Schmidt <christopher <at> ch.ristopher.com>
> Date: Sat,  3 Aug 2013 13:56:48 +0100 (BST)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > Looks fine to me, although I just skimmed through it.  Does it solve
> > the problem?
> 
> Yes, it does.

Then I recommend to install it, barring any objections.

Message #50 received at 14744 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Christopher Schmidt <christopher <at> ch.ristopher.com>, 14744 <at> debbugs.gnu.org
Subject: Re: bug#14744: 24.3.50; Flickering mouse-face on process output
Date: Tue, 25 Aug 2020 13:01:58 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> > Looks fine to me, although I just skimmed through it.  Does it solve
>> > the problem?
>> 
>> Yes, it does.
>
> Then I recommend to install it, barring any objections.

Looks like this was applied, but the bug report wasn't closed, so I'm
doing that now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.