GNU bug report logs - #44448
27.1; Strange inteference between timer, modeline/header-line and buffer position in window

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Amai Kinono <amaikinono <at> gmail.com>
Cc: 44448 <at> debbugs.gnu.org
Subject: bug#44448: Fwd: bug#44448:
Date: Thu, 12 Aug 2021 15:44:34 +0300

> From: Amai Kinono <amaikinono <at> gmail.com>
> Date: Wed, 11 Aug 2021 20:18:36 +0800
> 
> > Some code in paren.el probably moves point without unwind-protect, or
> something like that.
> 
> It's not. To answer you, I've created a new recipe that only moves overlay, and
> triggers the problem:
> 
> 1. emacs -Q
> 
> 2. M-x find-library RET paren
> 
> 3. M-x split-window-horizontally
> 
> 4. Go to the bottom of the file
> 
> 5. M-x read-only-mode to turn off read-only-mode so we can write things here.
>    Also M-x auto-save-mode to stop Emacs from auto saving it.
> 
> 6. Paste and eval this:
> 
> (defvar test-overlay (make-overlay (point-min) (1+ (point-min))))
> (overlay-put test-overlay 'face 'isearch)
> (run-with-timer 0 0.05 (lambda ()
>                          (let ((beg (random 5)))
>                            (move-overlay test-overlay beg (1+ beg)))))
> (defvar test-overlay2 (make-overlay (1- (point-max)) (point-max)))
> (overlay-put test-overlay2 'face 'isearch)
> (run-with-timer 0 0.05 (lambda ()
>                          (let ((beg (- (point-max) (random 5))))
>                            (move-overlay test-overlay beg (1+ beg)))))
> 
>    Now we have 2 overlays dancing at the beginning and end of buffer.
> 
> 7. Go to the end of ther buffer, holding C-g for several secs. You may need to
>    do this several times, but there are chances that the cursor goes to the
>    beginning of the buffer.

Thanks.  I see the cause of it: it's the :eval forms that we execute
when we redisplay the mode line, as part of redisplaying a window.
When more than one window displays the same buffer at different buffer
positions, when Emacs redisplays a non-selected window, it temporarily
moves point to the place where it is displayed in that non-selected
window.  If C-g is processed while those :eval forms run, with the
buffer's point temporarily moved, you will see point in the selected
window "inherit" the position of point from the other window showing
the same buffer.  As evidence, after this happens, you should be able
to see this in *Messages*:

  Error during redisplay: (mode-line-default-help-echo #<window 3 on paren.el>) signaled (quit)

We could prevent this jumping of point in these cases by running the
:eval forms in the mode line with inhibit-quit bound to t, but then it
will be impossible to interrupt :eval forms that run amok for some
reason, which is a real danger, since the mode-line format is very
frequently customized to include more or less arbitrary Lisp.  So I'm
not sure that inhibiting quitting would be a good idea here: the cure
could be worse than the disease.

Ideas for fixing this are welcome.

Previous Next

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