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