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: Sat, 14 Aug 2021 12:25:43 +0300

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

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

Previous Next

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