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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: jonas <at> bernoul.li, 38181 <at> debbugs.gnu.org
Subject: Re: bug#38181: Actual height of mode-line not taken into account
Date: Mon, 04 May 2020 16:46:27 +0300

> Cc: jonas <at> bernoul.li, 38181 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> 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?

Previous Next

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