From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#38181: Actual height of mode-line not taken into account Date: Mon, 11 May 2020 10:30:45 +0200 Message-ID: <96da8d16-0691-7b26-ec33-0b8ec25e3f3e@gmx.at> 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> <83wo5rolsc.fsf@gnu.org> <4682372c-e25a-dc62-842f-c3971f79bb16@gmx.at> <838si6mnsy.fsf@gnu.org> <86491f07-ed68-2880-17a0-a60ed40d5059@gmx.at> <83ftcdktrm.fsf@gnu.org> <6713049b-49e2-64ca-902d-1f972952f590@gmx.at> <83v9l3dflc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="112122"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jonas@bernoul.li, 38181@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 11 10:31:41 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 1jY3qf-000T4d-6T for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 May 2020 10:31:41 +0200 Original-Received: from localhost ([::1]:45632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jY3qd-0005qu-LK for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 May 2020 04:31:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59068) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jY3q2-0005pm-KM for bug-gnu-emacs@gnu.org; Mon, 11 May 2020 04:31:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39638) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jY3q2-0006g2-9N for bug-gnu-emacs@gnu.org; Mon, 11 May 2020 04:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jY3q2-0007da-3p for bug-gnu-emacs@gnu.org; Mon, 11 May 2020 04:31:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 08:31:02 +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.158918585529345 (code B ref 38181); Mon, 11 May 2020 08:31:02 +0000 Original-Received: (at 38181) by debbugs.gnu.org; 11 May 2020 08:30:55 +0000 Original-Received: from localhost ([127.0.0.1]:51184 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jY3pu-0007dF-Qu for submit@debbugs.gnu.org; Mon, 11 May 2020 04:30:55 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:46315) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jY3ps-0007d0-Od for 38181@debbugs.gnu.org; Mon, 11 May 2020 04:30:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1589185846; bh=f7iFv15CZhB0Ankip2EcQDUDhYt0hwa43TAt2nit7WU=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=fOXSvhd1lW3wSvwRDD0ejqQ3tQnRt+AOwkyfFIpJ2qfdQGQwX5CBnKCgyDYj3Umwc xtIQi/tj9RKx2a4BctfAnWvFcF/xlNFGS7wfBzaX/TX0HyVU4rJE2AWi93yDWDtf/n 1LLJKfdTCJatnpIj2TVWS3LMghNTIq9us4PIRg1E= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([46.125.249.80]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mv31c-1jGfXa0pjE-00qxEk; Mon, 11 May 2020 10:30:46 +0200 In-Reply-To: <83v9l3dflc.fsf@gnu.org> Content-Language: en-US X-Provags-ID: V03:K1:rBLqQ3Tsa77bxjC1KxDIQ1LReCZhHAFIJEdwk+ZROtWRN7Y8MUq aHjGGDTB+PQ4z+cpGeJb0kkqynJQMAC7KzuZ8EQS7OAoWIgUMWe8jXrba3dncbssiGqHUaK /3pqSmjPbRXbpjHVzODYfvqrbjA3GPP4V8xhTltxAdbDRlzWRTD20w2ixYhPsNFEjjsvawY VWMqoDLafLhXdKIP7d2oA== X-UI-Out-Filterresults: notjunk:1;V03:K0:U8fGoipvFwU=:vpIXdBhRO+HQaiHNDSCFgM yYl4w3yymhg2ypgjE/xCBi4uXRr8fmAeNu7CFzjt7TRLhMUHsrQJRD5ujUTtaJYoLO26boUFS tPEWLya8J3lRdRvpfwX5PCeZ0HTe33vMEWTC4y4Wwouby3xmgl/98WaLlB1hGR5pB7UtS1QKt tfYnWw3HfdRqI2rA336SCBH1crNoaw2W7RSUKquw1ZwI7GEdvHnKRtilYYWNFSuLXL4cZTPgM EwAcPNiKI6L05BjFnSBwv7Pf+6Sxsg7uB0BYq+r/azcl2JguIim8YT50emLnpJx8jAJMI8Ao1 0oqoYzfXxmfdIysgm75BxdRHlFR4Fhf6d5vIBI72x2tU7V8jUWBnv7TKfXWObHlCxW04j025Z X7tk+FcsRxGUYNVgJ0F0RVyyB3iJ+e3+q6/JcuAL7uuMBBfNUTI7YUqRqcTtz6hFOX3dYyjBC l6CK0uyvlneE2muk4GsE3zXMNaYGfw36S1qbAESGN33M2cijZtQtpR1FzpYiMAmAu3Qls6cRl e8vtORSA3x0F5lXmxdVME4986uAMNePflmcVgxqjCQd1SqgW1bsrSKj1vt1Yj1kM7zrLAIr5h rNjv/aif3cB/pbAZenm6PqQvzQLA3N5i2QCH/hHlJBsPBAab8VaOf1a7HypFH1GlnzboogAgR mnhebVRjlCZNLdYtP+NGjl0e5uCqjAS20uy3jQ72pRTJnCnWmpcGEa7W2hLzcAdUXigYfIWOJ l6pXT7TgvbB8vtzsBqygI5TeIG/cOhMhC4ZeAwBJTkyLhB5hMcIdshREtLmcadnyM4ocbjf4 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:180057 Archived-At: > The second call happens before the first one, so it looks more correct > to me. Why did you think you didn't need to set the frame title for > child frames? Because on all systems excluding Windows child frames do not show their titles. Calculating something that cannot be displayed doesn't strike me as a good idea. And obviously native tooltip frames which suffer the same problem using (progn (setq x-gtk-use-system-tooltips nil) (set-face-background 'internal-border "red")) would still not display borders correctly. Or should we set their titles too? >> Disclaimer: In all those runs I do not know whether the >> >> (set-face-background 'internal-border "red") >> >> set the face_change flag or something else did. > > It doesn't. It sets the face_change flag of each frame instead. See > internal-set-lisp-face-attribute. This way of setting things confuses me. What is then that global face_change bool needed for? >> It might have been a wrong conclusion on my side. Maybe the problem is >> caused by the fact that face_change is not set by 'set-face-background' >> and the face change that triggered the backtraces above came from >> somewhere else. > > See above. It could be that we somehow fail to redisplay the child > frame thoroughly enough, though. I have not tried yet but I'm convinced that we would fail for a normal frame as well if we didn't set its frame title. This reliance of one (internal border color) upon the conceptually unrelated other (setting the frame title) looks fishy to me and IIRC causes redisplay_internal to initially run with old character sizes until the actual ones get realized when setting the frame title. >> So if I set `inhibit-free-realized-faces' to nil at some arbitrary time >> things may go wrong. > > Only if you do that in code that can run while redisplay_internal is > doing its job. That's what I meant, yes. >> > The other two are the reason why we set the >> > inhibit_free_realized_faces in PRODUCE_GLYPHS: the flag must be set >> > during redisplay, until update_frame finished its job. Otherwise we >> > will sooner or later crash. >> >> I'm running without this for a couple of days now and it did not crash >> so far. > > Try setting things up such that faces are modified by some Lisp that > runs during redisplay, like some :eval form of the mode line or one of > the hooks called by the display code. That's how crashes with face = > NULL invariably start. Not really needed. You convinced me here. >> Sheer luck, I presume. Couldn't PRODUCE_GLYPHS set >> inhibit_free_realized_faces iff redisplaying_p is true? > > No, because some functions we call from Lisp actually write into the > current matrix. For example, tool-bar-height and tab-bar-height. Then there's more to it than the above "the flag must be set during redisplay, until update_frame finished its job"? I'm still confused but that's probably my poor mind. Maybe re-reading your text after a day or so will help. >> So it's not so entirely trivial to do that in Elisp. > > Why do we need to do this in Lisp? Didn't you propose to calculate the mode-line height from 'fit-window-to-buffer'? >> OK. But IIUC so far we do not allow inhibit_free_realized_faces nil >> outside of redisplay_internal. Unless someone sets >> 'inhibit-free-realized-faces' which is, in general, to recommended. >> Right? > > Yes, but I see no reason not to reset it in other places, provided > that we do it carefully and only when absolutely needed. We should say that in the doc-string of 'inhibit-free-realized-faces', maybe. martin