Subject: bug#38181: Actual height of mode-line not taken into account

From: martin rudalics <[email-masked]>
Date: Sat, 16 May 2020 10:44:38 +0200

>> 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?

Given my current knowledge of the matter, yes.  Note that ATK apparently
even mandates that tooltip windows have some sort of title set.

 > Anyway, if we want to be able create frames without titles,

Our tooltips are frames and don't have titles so we do that already.

 >> 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.

Agreed.  But does our code adhere to that idea?  gui_set_font_backend
sets face_change to true and so does IT_set_frame_parameters (not that
it matters here - I'm just talking about the idea) while working on a
specific frame.  And in x_create_tip_frame and w32_create_tip_frame we
even have to save the value of it via face_change_before even though
these two functions really should only affect the tip frame about to be
created.  All other settings of face_change happen in xfaces.c and that
one really should know better.

 > "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?

Earlier, when debugging this issue, I spent some time stepping through
the iterator with the old faces in place and just wondered why the new
faces would not get applied.  Whenever I'm back there I might be able to
tell more.  But before that I'd rather wait whether your

 > 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.

could be implemented and solve all these problems in one rush.

 >>   >> 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.

With the inevitable consequence that redisplay_internal restores it to
true when it exits.  Is that the idea behind "we sometimes set it
elsewhere as well" or just some sort of collateral damage?

 >> We should say that in the doc-string of 'inhibit-free-realized-faces',
 >> maybe.
 >
 > We should? why?

Because it might help people like me understand this issue.  Do you
think that my questions are provocative?  Maybe they are, but then
that's a consequence of the fact that I don't get the picture of our
implementation of faces.

martin