bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#38181: Actual height of mode-line not taken into account
Date: Tue, 05 May 2020 17:58:05 +0300

> From: martin rudalics <rudalics@gmx.at>
> Cc: jonas@bernoul.li, 38181@debbugs.gnu.org
> Date: Tue, 5 May 2020 10:32:31 +0200
> 
> Below find two backtraces with emacs -Q where PRODUCE_GLYPHS here sets
> inhibit_free_realized_faces outside the scope of redisplay_internal
> (that is, while redisplaying_p is nil) such that these will not get
> caught by the unbind form in redisplay_internal.

Thanks.  All of these enter redisplay via echo_area_display.  That
calls redisplay_internal, but only after it displays the mini-window.

However, I had my doubts regarding the accuracy of my mental model.
Namely, the part where I said that inhibit_free_realized_faces should
never be non-zero outside of redisplay.  So I looked at the code and
its history, and it turns out I was wrong: the line that sets the flag
in PRODUCE_GLYPHS was there since Emacs 21, and I see the flag set to
non-zero all the way back to Emacs 22.1 (and probably earlier).

So it sounds like we always were running like that.  Therefore, I must
turn the table and ask you to please describe in more detail,
preferably with Lisp snippets to try, how the fact that this flag is
non-zero gets in the way of something we need to do with faces, both
in this bug and the other one you mentioned.  I'd like to understand
better how this flag interferes in these use cases.

Thanks (and sorry for spreading misinformation: I was somehow
confident that it was myself who added the setting of
inhibit_free_realized_faces in PRODUCE_GLYPHS, but the truth is that
it was Gerd, long ago).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]