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

Previous Next

Full log

Message #173 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: Fri, 15 May 2020 18:00:18 +0300

> Cc: jonas <at> bernoul.li, 38181 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Mon, 11 May 2020 10:30:45 +0200
> 
>  > The second call happens before the first one, so it looks more correct
>  > to me.  Why did you think you didn't need to set the frame title for
>  > child frames?
> 
> Because on all systems excluding Windows child frames do not show their
> titles.  Calculating something that cannot be displayed doesn't strike
> me as a good idea.  And obviously native tooltip frames which suffer the
> same problem using
> 
> (progn
>    (setq x-gtk-use-system-tooltips nil)
>    (set-face-background 'internal-border "red"))
> 
> would still not display borders correctly.  Or should we set their
> titles too?

Is that a serious question?

Anyway, if we want to be able create frames without titles, I guess we
should simply arrange for the face cache to be cleared and the basic
faces recomputed somewhere near the beginning of redisplay_internal.

>  >> Disclaimer: In all those runs I do not know whether the
>  >>
>  >>     (set-face-background 'internal-border "red")
>  >>
>  >> set the face_change flag or something else did.
>  >
>  > It doesn't.  It sets the face_change flag of each frame instead.  See
>  > internal-set-lisp-face-attribute.
> 
> This way of setting things confuses me.  What is then that global
> face_change bool needed for?

For when we don't want to loop over all the frames setting their
individual flags, I guess.

> I have not tried yet but I'm convinced that we would fail for a normal
> frame as well if we didn't set its frame title.  This reliance of one
> (internal border color) upon the conceptually unrelated other (setting
> the frame title) looks fishy to me and IIRC causes redisplay_internal to
> initially run with old character sizes until the actual ones get
> realized when setting the frame title.

"Initially run with old character sizes" doing what?  AFAIR, we do the
frame title thingy quite early during the redisplay cycle.  What is
done before that that needs to know about the faces change?

>  >> Sheer luck, I presume.  Couldn't PRODUCE_GLYPHS set
>  >> inhibit_free_realized_faces iff redisplaying_p is true?
>  >
>  > No, because some functions we call from Lisp actually write into the
>  > current matrix.  For example, tool-bar-height and tab-bar-height.
> 
> Then there's more to it than the above "the flag must be set during
> redisplay, until update_frame finished its job"?

More in what way?  This just means we sometimes set it elsewhere as
well.

>  >> So it's not so entirely trivial to do that in Elisp.
>  >
>  > Why do we need to do this in Lisp?
> 
> Didn't you propose to calculate the mode-line height from
> 'fit-window-to-buffer'?

I don't remember, but if so, it doesn't yet mean everything must be
done in Lisp.

>  >> OK.  But IIUC so far we do not allow inhibit_free_realized_faces nil
>  >> outside of redisplay_internal.  Unless someone sets
>  >> 'inhibit-free-realized-faces' which is, in general, to recommended.
>  >> Right?
>  >
>  > Yes, but I see no reason not to reset it in other places, provided
>  > that we do it carefully and only when absolutely needed.
> 
> We should say that in the doc-string of 'inhibit-free-realized-faces',
> maybe.

We should? why?

Previous Next

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