* bug#14744: 24.3.50; Flickering mouse-face on process output @ 2013-06-29 0:10 Christopher Schmidt 2013-06-29 7:46 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Christopher Schmidt @ 2013-06-29 0:10 UTC (permalink / raw) To: 14744 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-06-29 0:10 bug#14744: 24.3.50; Flickering mouse-face on process output Christopher Schmidt @ 2013-06-29 7:46 ` Eli Zaretskii 2013-06-29 9:47 ` Christopher Schmidt 2013-06-29 15:08 ` Stefan Monnier 0 siblings, 2 replies; 16+ messages in thread From: Eli Zaretskii @ 2013-06-29 7:46 UTC (permalink / raw) To: Christopher Schmidt; +Cc: 14744 > From: Christopher Schmidt <christopher@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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-06-29 7:46 ` Eli Zaretskii @ 2013-06-29 9:47 ` Christopher Schmidt 2013-06-29 10:35 ` Stephen Berman 2013-06-29 11:41 ` Eli Zaretskii 2013-06-29 15:08 ` Stefan Monnier 1 sibling, 2 replies; 16+ messages in thread From: Christopher Schmidt @ 2013-06-29 9:47 UTC (permalink / raw) To: 14744 Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-06-29 9:47 ` Christopher Schmidt @ 2013-06-29 10:35 ` Stephen Berman 2013-06-29 11:41 ` Eli Zaretskii 1 sibling, 0 replies; 16+ messages in thread From: Stephen Berman @ 2013-06-29 10:35 UTC (permalink / raw) To: 14744 On Sat, 29 Jun 2013 10:47:15 +0100 (BST) Christopher Schmidt <christopher@ch.ristopher.com> wrote: > Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-06-29 9:47 ` Christopher Schmidt 2013-06-29 10:35 ` Stephen Berman @ 2013-06-29 11:41 ` Eli Zaretskii 2013-06-29 12:56 ` Christopher Schmidt 1 sibling, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2013-06-29 11:41 UTC (permalink / raw) To: Christopher Schmidt; +Cc: 14744 > From: Christopher Schmidt <christopher@ch.ristopher.com> > Date: Sat, 29 Jun 2013 10:47:15 +0100 (BST) > > Eli Zaretskii <eliz@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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-06-29 11:41 ` Eli Zaretskii @ 2013-06-29 12:56 ` Christopher Schmidt 2013-06-29 14:45 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Christopher Schmidt @ 2013-06-29 12:56 UTC (permalink / raw) To: 14744 Eli Zaretskii <eliz@gnu.org> writes: > For the record, what is the real-life use case where this matters? The one Stephen described in <8761wxfbm8.fsf@rosalinde.fritz.box>. Christopher ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-06-29 12:56 ` Christopher Schmidt @ 2013-06-29 14:45 ` Eli Zaretskii 2013-08-03 9:41 ` Christopher Schmidt 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2013-06-29 14:45 UTC (permalink / raw) To: Christopher Schmidt; +Cc: 14744 > From: Christopher Schmidt <christopher@ch.ristopher.com> > Date: Sat, 29 Jun 2013 13:56:53 +0100 (BST) > > Eli Zaretskii <eliz@gnu.org> writes: > > For the record, what is the real-life use case where this matters? > > The one Stephen described in <8761wxfbm8.fsf@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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-06-29 14:45 ` Eli Zaretskii @ 2013-08-03 9:41 ` Christopher Schmidt 2013-08-03 10:36 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Christopher Schmidt @ 2013-08-03 9:41 UTC (permalink / raw) To: 14744 Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-08-03 9:41 ` Christopher Schmidt @ 2013-08-03 10:36 ` Eli Zaretskii 2013-08-03 12:25 ` Christopher Schmidt 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2013-08-03 10:36 UTC (permalink / raw) To: Christopher Schmidt; +Cc: 14744 > From: Christopher Schmidt <christopher@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). ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-08-03 10:36 ` Eli Zaretskii @ 2013-08-03 12:25 ` Christopher Schmidt 2013-08-03 12:41 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Christopher Schmidt @ 2013-08-03 12:25 UTC (permalink / raw) To: 14744 [-- Attachment #1: Type: text/plain, Size: 258 bytes --] Eli Zaretskii <eliz@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: [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Type: text/x-diff, Size: 3401 bytes --] --- 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 () [-- Attachment #3: Type: text/plain, Size: 21 bytes --] Christopher ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-08-03 12:25 ` Christopher Schmidt @ 2013-08-03 12:41 ` Eli Zaretskii 2013-08-03 12:56 ` Christopher Schmidt 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2013-08-03 12:41 UTC (permalink / raw) To: Christopher Schmidt; +Cc: 14744 > From: Christopher Schmidt <christopher@ch.ristopher.com> > Date: Sat, 3 Aug 2013 13:25:39 +0100 (BST) > > Eli Zaretskii <eliz@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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-08-03 12:41 ` Eli Zaretskii @ 2013-08-03 12:56 ` Christopher Schmidt 2013-08-03 13:12 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Christopher Schmidt @ 2013-08-03 12:56 UTC (permalink / raw) To: 14744 Eli Zaretskii <eliz@gnu.org> writes: > Looks fine to me, although I just skimmed through it. Does it solve > the problem? Yes, it does. Christopher ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-08-03 12:56 ` Christopher Schmidt @ 2013-08-03 13:12 ` Eli Zaretskii 2020-08-25 11:01 ` Lars Ingebrigtsen 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2013-08-03 13:12 UTC (permalink / raw) To: Christopher Schmidt; +Cc: 14744 > From: Christopher Schmidt <christopher@ch.ristopher.com> > Date: Sat, 3 Aug 2013 13:56:48 +0100 (BST) > > Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-08-03 13:12 ` Eli Zaretskii @ 2020-08-25 11:01 ` Lars Ingebrigtsen 0 siblings, 0 replies; 16+ messages in thread From: Lars Ingebrigtsen @ 2020-08-25 11:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Christopher Schmidt, 14744 Eli Zaretskii <eliz@gnu.org> writes: >> Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-06-29 7:46 ` Eli Zaretskii 2013-06-29 9:47 ` Christopher Schmidt @ 2013-06-29 15:08 ` Stefan Monnier 2013-06-29 15:16 ` Eli Zaretskii 1 sibling, 1 reply; 16+ messages in thread From: Stefan Monnier @ 2013-06-29 15:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Christopher Schmidt, 14744 >> 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#14744: 24.3.50; Flickering mouse-face on process output 2013-06-29 15:08 ` Stefan Monnier @ 2013-06-29 15:16 ` Eli Zaretskii 0 siblings, 0 replies; 16+ messages in thread From: Eli Zaretskii @ 2013-06-29 15:16 UTC (permalink / raw) To: Stefan Monnier; +Cc: christopher, 14744 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Christopher Schmidt <christopher@ch.ristopher.com>, 14744@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. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-08-25 11:01 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-06-29 0:10 bug#14744: 24.3.50; Flickering mouse-face on process output Christopher Schmidt 2013-06-29 7:46 ` Eli Zaretskii 2013-06-29 9:47 ` Christopher Schmidt 2013-06-29 10:35 ` Stephen Berman 2013-06-29 11:41 ` Eli Zaretskii 2013-06-29 12:56 ` Christopher Schmidt 2013-06-29 14:45 ` Eli Zaretskii 2013-08-03 9:41 ` Christopher Schmidt 2013-08-03 10:36 ` Eli Zaretskii 2013-08-03 12:25 ` Christopher Schmidt 2013-08-03 12:41 ` Eli Zaretskii 2013-08-03 12:56 ` Christopher Schmidt 2013-08-03 13:12 ` Eli Zaretskii 2020-08-25 11:01 ` Lars Ingebrigtsen 2013-06-29 15:08 ` Stefan Monnier 2013-06-29 15:16 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.