[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?
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2020/05/02
- bug#38181: Actual height of mode-line not taken into account,
Eli Zaretskii <=
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2020/05/04
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2020/05/04
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2020/05/05
- bug#38181: Actual height of mode-line not taken into account, Eli Zaretskii, 2020/05/05
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2020/05/05
- bug#38181: Actual height of mode-line not taken into account, Eli Zaretskii, 2020/05/05
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2020/05/06
- bug#38181: Actual height of mode-line not taken into account, Eli Zaretskii, 2020/05/06
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2020/05/06
- bug#38181: Actual height of mode-line not taken into account, Eli Zaretskii, 2020/05/06