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: Mon, 04 May 2020 16:46:27 +0300

> Cc: jonas@bernoul.li, 38181@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 2 May 2020 20:06:38 +0200
> 
>  > Suppose we had a Lisp-callable function which would return the height
>  > of the mode line of a window as per the current mode-line-format for
>  > that window -- would that make the solution possible/easier?
> 
> Suppose I wanted to write such a function.  Then the problem is with
> scenarios like your earlier

Sorry for the belated response, there's a tsunami out there...

>    (defun test-popup ()
>      (interactive)
>      (set-face-attribute 'mode-line nil :height 350)
>      (set-face-attribute 'mode-line-inactive nil :height 350)
>      (with-current-buffer (generate-new-buffer "*test*")
>        (save-excursion
>       (insert "one\ntwo\nthree\nfour\nfive"))
>        (let ((win (display-buffer (current-buffer)
>                                '(display-buffer-in-side-window
>                                  (side . bottom)))))
>       (fit-window-to-buffer win))))
> 
> If I wanted to take into account the changes of the face attributes in
> 'fit-window-to-buffer', I'd have to set 'inhibit-free-realized-faces'
> there to nil in order to apply the necessary face changes.  Wouldn't
> that possibly harm our window matrices?  Can you somehow summarize how
> that variable is supposed to be treated in general?  I already gave up
> fighting with it in Bug#40639.

I don't think I follow.  Are you saying that
inhibit-free-realized-faces is non-nil when you run Lisp
interactively, or in general in a Lisp program that was not called,
directly or indirectly, from redisplay_internal?  That should never
happen, as the code arranges for inhibit-free-realized-faces to be
reset to its original value when redisplay_internal returns.  If this
doesn't work, then we have a serious bug on our hands, and should fix
it ASAP.

This variable is supposed to be non-nil only when we are done
preparing the desired matrices and are about to call update_frame,
because that function cannot cope with faces referenced in the desired
matrices that were meanwhile freed.  This could happen if some hook
called from redisplay_internal manages to run code that decides to
free the faces.

But once update_frame is done, we don't need this variable set
anymore, and it should revert to nil soon enough, because
redisplay_internal returns soon after that.

What am I missing?





reply via email to

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