bug#44448: Fwd: bug#44448:

[Eli Zaretskii]

[Please use Reply All when you reply, to keep the bug address on the
CC list.]

> From: Amai Kinono <amaikinono@gmail.com>
> Date: Fri, 13 Aug 2021 17:49:24 +0800
> 
> 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.

Not here, it doesn't.  If I set mode-line-format to nil in the buffer
that visits paren.el, I cannot reproduce the problem anymore.

However, as I wrote in my other message, the :eval form in the mode
line cannot be the whole story, because we evaluate these forms in a
way that should (and does) catch any errors, including quit.
Something else is at work here.

P.S. FTR, I use setq, not setq-default, and I also do this before
running the experiment (to avoid unrelated triggers for redisplay):

  M-x blink-cursor-mode RET
  M-x global-eldoc-mode RET

And M-~ after pasting the code which starts the overlays.

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

I'm not sure either, but your timer functions in general don't switch
to the specific buffer, so this could be unrelated.