[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14744: 24.3.50; Flickering mouse-face on process output
From: |
Eli Zaretskii |
Subject: |
bug#14744: 24.3.50; Flickering mouse-face on process output |
Date: |
Sat, 29 Jun 2013 17:45:14 +0300 |
> 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.