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

Previous Next

Full log

Message #176 received at 38181 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, 38181 <at> debbugs.gnu.org
Subject: Re: bug#38181: Actual height of mode-line not taken into account
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

Previous Next

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