[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#38181: Actual height of mode-line not taken into account
From: |
Eli Zaretskii |
Subject: |
bug#38181: Actual height of mode-line not taken into account |
Date: |
Fri, 15 Oct 2021 10:54:29 +0300 |
> From: Carlos Pita <carlosjosepita2@gmail.com>
> Date: Fri, 15 Oct 2021 04:26:51 -0300
> Cc: 38181@debbugs.gnu.org
>
> > If the underlying scenario is that you first fit a window to its buffer
> > and then enlarge the height of that window's mode-line, there's not much
> > we can do here currently. It's like fitting a window to its buffer and
> > then adding a header line or a horizontal scroll bar to that window.
>
> I can't say I understand the details discussed here but I'm not quite
> sure your description fits the situation.
>
> The workaround since this bug was first reported has been: immediately
> before fit-window-to-buffer execute an advice that forces a redisplay,
> then deactivate the advice.
>
> But the problem I'm seeing now is that the first time
> org-set-tags-command is executed its popup is correctly sized (with
> said workaround in place, of course), but further executions show a
> popup with the wrong geometry that trims part of the text off. If I
> remove the "just once" clause in the workaround, so that the redisplay
> is forced after each fit-window-to-buffer execution, then the layout
> is correct every time. It goes without saying that
> org-set-tags-command is ultimately triggering the execution of
> fit-window-to-buffer, but that stuff you probably know much better
> than me. Thing is, there was no enlargement of the modeline
> in-between, as far as I can understand and see nothing changed in this
> regard between the first and the second execution of
> org-set-tags-command.
Can you show the recipe for the problem, starting from "emacs -Q"?
It sounds from what you say that the problem is not with the mode
line, but with something else. If that is true, please submit a new
bug report. This bug is about redisplaying the mode line when
something changes in mode-line-format that affects the height of the
mode line. If there are other problems with fit-window-to-buffer,
they should be discussed separately.
- bug#38181: Actual height of mode-line not taken into account, Carlos Pita, 2021/10/15
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2021/10/15
- bug#38181: Actual height of mode-line not taken into account, Carlos Pita, 2021/10/15
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2021/10/15
- bug#38181: Actual height of mode-line not taken into account, Carlos Pita, 2021/10/15
- Message not available
- Message not available
- bug#38181: Actual height of mode-line not taken into account, Carlos Pita, 2021/10/15
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2021/10/16
- bug#38181: Actual height of mode-line not taken into account, Carlos Pita, 2021/10/16
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2021/10/16
- bug#38181: Actual height of mode-line not taken into account, Carlos Pita, 2021/10/16
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2021/10/16
- bug#38181: Actual height of mode-line not taken into account, Carlos Pita, 2021/10/16