[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#38181: Actual height of mode-line not taken into account
From: |
Carlos Pita |
Subject: |
bug#38181: Actual height of mode-line not taken into account |
Date: |
Sat, 16 Oct 2021 16:57:33 -0300 |
I was just about to email you with some questions that you now have
answered to some extent. Anyway, I'm copying my original questions
with some annotations.
> > I think you mean with every set_window_buffer? And probably with every
> > set_window_configuration too. Did you try it?
>
> I still need to refine my concept of "on window creation".
Well, any relevant window hook in [1] is advertised as "called during
redisplay", so that surely isn't the place to trigger that same
redisplay to begin with...
Let's go back to advising then. Here are some questions I have:
1. Is there a primitive function that is like the mother of all
windows? There is no window-create nor create-window alikes, so maybe
split-window-internal?
> Window creation means 'split-window' which assigns the new window a
> buffer that appears in the window that was split.
So this more or less settles the question, but to be more precise:
do you see any difference of relevance between advicing split-window
and split-window-internal?
2. Or is it better to advise set-window-buffer/configuration for
whatever reasons? Any or both of them?
3. If advising set-window-buffer/configuration is the preferred
method, I'm still assuming that we will keep a window parameter in
order to disable the forced redisplay after its first execution for the
window. Is there any reason not do so (taking into account what
I said before of the target use case: a single modeline height for
every modeline during the entire session).
> Or do the mode lines of _all_ your windows have
> the same height? That indeed would simplify things a lot.
Yes, this is by far the usual case and I believe it's a fact that
favours the "advise window creation" strategy over the
"advise window buffer/config change events" (with or without
the "just once per window" clause) strategy.
Thanks again,
Carlos
- bug#38181: Actual height of mode-line not taken into account, (continued)
- 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 <=
- 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, Eli Zaretskii, 2021/10/17
- bug#38181: Actual height of mode-line not taken into account, Carlos Pita, 2021/10/17
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2021/10/17
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2021/10/17
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2021/10/17
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2021/10/18
- bug#38181: Actual height of mode-line not taken into account, Carlos Pita, 2021/10/18
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2021/10/18
- bug#38181: Actual height of mode-line not taken into account, Eli Zaretskii, 2021/10/18