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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 16 May 2020 13:46:41 +0300

> Cc: [email-masked], [email-masked]
> From: martin rudalics <[email-masked]>
> Date: Sat, 16 May 2020 10:44:38 +0200
> 
>  > 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.

Yes, of course.  I hope you don't assume I didn't know that.

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

Could you please tell where is this discussion going?  Because I no
longer understand that.  We seem to be talking around the issue, but
to what end?  Why are these details important for whatever job you
have in mind?  I'd like to help you do that job, but I'm lost in
"twisty little passages, all alike".

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

All it takes is to call free_all_realized_faces for the frame in
question, and then do what init_iterator does:

  if (FRAME_FACE_CACHE (it->f) == NULL)
    init_frame_faces (it->f);
  if (FRAME_FACE_CACHE (it->f)->used == 0)
    recompute_basic_faces (it->f);

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

I don't think it matters that this flag is set when we are outside
redisplay.