GNU bug report logs -
#60210
30.0.50; tab-bar height not recalculated when face changes
Previous Next
Full log
Message #40 received at 60210 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 01 Jan 2023 21:50:56 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: 60210 <at> debbugs.gnu.org, juri <at> linkov.net
>
>
> >> The bug is that, in redisplay_tab_bar, WINDOW_PIXEL_HEIGHT (w) uses the
> >> height of the default face, which is 39 pixels, whereas new_height,
> >> which is computed with tab_bar_height, uses the font of the tab-bar
> >> face (variable-pitch in emacs -Q). On my system, new_height is (with a
> >> single *scratch* tab) 36 pixels. Therefore new_height <
> >> WINDOW_PIXEL_HEIGHT (w), when in fact according to the logic of the
> >> code we should have new_height == WINDOW_PIXEL_HEIGHT (w).
> >
> > I'm not sure I understand how the above causes the tab bar not to be
> > displayed, or become empty. AFAIU, it just means the frame's
> > change_tab_bar_height_hook will be called. What did I miss?
> >
>
> I do not fully understand it either yet. A simpler recipe, which does not
> involve changing fonts:
>
> (set-face-attribute 'tab-bar nil :height 0.5)
> (tab-bar-mode 1)
>
> This should display a tiny tab-bar, it displays a white bar instead.
>
> In redisplay_tab_bar, new_height is set to half the height of a canonical
> line (17 and 34 on my system). Therefore redisplay_tab_bar returns true.
> The next redisplay cycle finds that WINDOW_TOTAL_LINES (w) == 0, and does
> nothing.
Ah, if WINDOW_TOTAL_LINES becomes zero, that will indeed explain the
problem. We should prevent that from happening as long as the tab bar
is turned on.
This bug report was last modified 2 years and 193 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.