bug#44448: Fwd: bug#44448: Fwd: bug#44448:

[Amai Kinono]

---------- Forwarded message ---------
发件人： Amai Kinono <amaikinono@gmail.com>
Date: 2021年8月13日周五 下午5:49
Subject: Re: bug#44448: Fwd: bug#44448:
To: Eli Zaretskii <eliz@gnu.org>

Thanks for testing! I feel kind of relieved when I know it can be reproduced.

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

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

I'm afraid this is not the truth. If you eval

    (setq-default mode-line-format nil)

before step 6, the problem still happens, and there's no error messages in the *Messages* buffer.

When testing with mode-line-format being nil, I noticed that:

- after I pressed C-x b and I'm in the minibuffer,

- occasionally, when I'm visiting *Messages* or *Buffer list* buffer,

The overlay that should appear at the bottom of paren.el moves to its beginning. The reason looks like (point-max) is returning the maximum point in current buffer. I don't know if this fact has anything to do with the bug, though.

Eli Zaretskii <eliz@gnu.org> 于2021年8月12日周四 下午8:44写道：

> From: Amai Kinono <amaikinono@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.