bug#44448: Fwd: bug#44448:

[Amai Kinono]

I'm on the latest commit (55772baee1627571c0814cf2d666fb3b963ff591) now.
Unfortunately the bug can still be reproduced on my side.

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

Even if I follow these steps when testing, with mode-line-format begin nil, on
the latest commit, it can still be reproduced.

But I think your patch is doing its work. I did some programming work, and I
feel the chance it happens becomes lower.

Eli Zaretskii <eliz@gnu.org> 于2021年8月15日周日 下午7:21写道：

> Date: Sat, 14 Aug 2021 12:25:43 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 44448@debbugs.gnu.org
>
> > >  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.

I found a few places where we allowed redisplay_window to exit
non-locally, leaving point in its temporarily wrong position.  This
should now be fixed on the master branch.  Please test.

Thanks.