GNU bug report logs - #38181
Actual height of mode-line not taken into account

Previous Next

Full log

Message #41 received at 38181 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: jonas <at> bernoul.li, 38181 <at> debbugs.gnu.org
Subject: Re: bug#38181: Actual height of mode-line not taken into account
Date: Sat, 16 Nov 2019 12:57:41 +0200

> Cc: jonas <at> bernoul.li, 38181 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sat, 16 Nov 2019 09:57:40 +0100
> 
>  > Then I'm not sure we can fix such use cases at all, without causing
>  > display flickering in much more popular use cases.  Do you have any
>  > ideas for a possible fix?  Could fit-window-to-buffer invoke
>  > 'redisplay' internally, perhaps?
> 
> It could but it's called way too often to warrant such behavior by
> default.

What are the frequent calls?  Help and completions windows come to
mind, but those are interactive, and so I'm not sure I see why calling
redisplay would be a bad idea there.  Are there other callers which
I'm missing?

> But we could give it a separate optional argument so users can avoid
> the advice.

That's possible, of course.

>  >> But, as I mentioned earlier, the problem shows up with the
>  >> scroll bar immediately when Jonas' form is evaluated, see the attached
>  >> screenshot.
>  >
>  > That just means we (or a Lisp program which makes these mode-line
>  > modifications) need to recreate and redisplay the scroll bars anew in
>  > these cases, right?
> 
> Right.  But that same program could also redisplay all windows in
> these cases, right?

I meant that calling redisplay should do this automatically.

Previous Next

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