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

Previous Next

Full log

View this message in rfc822 format

From: Carlos Pita <carlosjosepita2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 38181 <at> debbugs.gnu.org
Subject: bug#38181: Actual height of mode-line not taken into account
Date: Sun, 17 Oct 2021 03:45:06 -0300

Hi Eli,

> > In practice this seems to nicely cover the relevant cases:
> >
> > (defun my-redisplay-hack (&rest _)
> >   (when mode-line-format
> >     (redisplay t)))
> > (advice-add #'split-window :after #'my-redisplay-hack)
>
> I wonder how this fixes anything, since split-window already triggers
> redisplay.

In the use cases discussed above, IIUC the problem is that the
redisplay is triggered at some point, but only after
fit-window-to-buffer has already taken place.

Consider for example what org-attach does:

1. Create a new window
2. Enter a window excursion and insert stuff into the new window
3. After the excursion fit the new window to the buffer (this is done
from another window)
4. Wait for user input

Seemingly, at point 3 the redisplay has not happened yet. The
redisplay-before-fit advice won't work in this case because the
current window is not the popup anymore when the fit (and
hence the forced redisplay) happens.

Another different example is org-set-tags-command, this is what it does:

1. Create a new window
2. Enter a window excursion and insert stuff into the new window
3. Inside the excursion fit the new window to the buffer (now this is
done while the popup is the current window)
4. After the excursion, wait for user input

So in this case the redisplay-before-fit advice works fine since it's
triggered inside the popup. But then the popup is killed while its
buffer remains hidden, outliving the popup. Remember that the advice
is really a redisplay-before-fit-once-per-buffer advice, so the next
time you call org-set-tags-command it will fail to redisplay.

This is why I believe these cases weren't properly addressed by the
previous workaround but are now.

> Which means there are two redisplay cycles, and the first one (which
> produces incorrect display) is the one from your hack.  So once again,
> I wonder why that call to 'redisplay' is needed.

Yes, I know that is the cause. The redisplay is not needed per se and,
worse, produces undesirable visual artifacts, but apparently it's the
only way we have to update the information about the mode-line height
before fit-window-to-buffer runs.

Now, if you are saying that step 1 in the examples above already
triggered a redisplay, and if a redisplay always updates whatever
information about the modeline geometry that needs to be updated, then
something is not adding up.

Best regards
--
Carlos

Previous Next

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