From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#38181: Actual height of mode-line not taken into account Date: Mon, 04 May 2020 16:46:27 +0300 Message-ID: <83wo5rolsc.fsf@gnu.org> References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <83k1806qca.fsf@gnu.org> <8336en7giv.fsf@gnu.org> <81264049-4f88-fae7-6448-e0ac5d977268@gmx.at> <83a78u5s8y.fsf@gnu.org> <01cee2f7-aeb5-4eb1-b2d5-e056c91eab8b@gmx.at> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="72458"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jonas@bernoul.li, 38181@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 04 15:47:27 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jVbRN-000Ihe-Sh for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 May 2020 15:47:25 +0200 Original-Received: from localhost ([::1]:34190 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVbRM-0001nX-UB for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 May 2020 09:47:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40198) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVbQz-0001mY-Vp for bug-gnu-emacs@gnu.org; Mon, 04 May 2020 09:47:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47744) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jVbQz-0001s9-MZ for bug-gnu-emacs@gnu.org; Mon, 04 May 2020 09:47:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jVbQz-0007yq-Jy for bug-gnu-emacs@gnu.org; Mon, 04 May 2020 09:47:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 May 2020 13:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38181 X-GNU-PR-Package: emacs Original-Received: via spool by 38181-submit@debbugs.gnu.org id=B38181.158860000130646 (code B ref 38181); Mon, 04 May 2020 13:47:01 +0000 Original-Received: (at 38181) by debbugs.gnu.org; 4 May 2020 13:46:41 +0000 Original-Received: from localhost ([127.0.0.1]:59290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVbQf-0007yC-Ef for submit@debbugs.gnu.org; Mon, 04 May 2020 09:46:41 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37084) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVbQc-0007xw-Ns for 38181@debbugs.gnu.org; Mon, 04 May 2020 09:46:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57893) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVbQW-0001Go-FY; Mon, 04 May 2020 09:46:32 -0400 Original-Received: from [176.228.60.248] (port=2207 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jVbQV-0004hJ-Rt; Mon, 04 May 2020 09:46:32 -0400 In-Reply-To: <01cee2f7-aeb5-4eb1-b2d5-e056c91eab8b@gmx.at> (message from martin rudalics on Sat, 2 May 2020 20:06:38 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:179679 Archived-At: > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > 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?