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, 4 May 2020 17:04:18 +0200 Message-ID: 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> 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="48870"; 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 04 17:05:59 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 1jVcfP-000CZo-0w for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 May 2020 17:05:59 +0200 Original-Received: from localhost ([::1]:49842 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVcfN-0008HN-RS for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 May 2020 11:05:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54774) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVceU-0008Gl-Im for bug-gnu-emacs@gnu.org; Mon, 04 May 2020 11:05:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50354) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jVceU-0002CN-9N for bug-gnu-emacs@gnu.org; Mon, 04 May 2020 11:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jVceU-0002Dq-4c for bug-gnu-emacs@gnu.org; Mon, 04 May 2020 11:05: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, 04 May 2020 15:05: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.15886046708504 (code B ref 38181); Mon, 04 May 2020 15:05:02 +0000 Original-Received: (at 38181) by debbugs.gnu.org; 4 May 2020 15:04:30 +0000 Original-Received: from localhost ([127.0.0.1]:33667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVcdy-0002D6-6B for submit@debbugs.gnu.org; Mon, 04 May 2020 11:04:30 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:48759) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVcdw-0002Cp-0V for 38181@debbugs.gnu.org; Mon, 04 May 2020 11:04:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588604661; bh=dG0rZ2AWKc71QtfS4lsVDFIV4nHKOb5nKWepVuZ4gWo=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=dvkZY/1d9YkBYIQnbZR4mkqf/bWe62afK1TUehAbwNvZQAbItk8S/oOggF11Uk+7R rTtUBnHtnsdlcxFpwL3UhECjG8Ywj4uBhl81oQ1w4GxiWZO+gLRjrULFtw28piGwWj 15kIdQOdwfZPO+nRI46yxcSTjgex+NuUlFpqhbGs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([46.125.249.121]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MAwXr-1jPFue1cIz-00BMTP; Mon, 04 May 2020 17:04:21 +0200 In-Reply-To: <83wo5rolsc.fsf@gnu.org> Content-Language: en-US X-Provags-ID: V03:K1:ofTt6udl1RH/Rpc8q5fm7L96Z85r3fZjLmv9/T/o+AGIxfCTUVn uwnc5XUXTtxD5q9XCylEQadysAmdchCkwbiQG7Ew/pCq33a8wgHreFfGIkwa0F/rE2/G4qQ FnxFNVKMo/PnsUGVnBSAT+laQTL9MmVwRUHpfEvjAkUEHCO+E82dyTBTsgLL7hRRRxOwom7 CzYo7/bj8F9BtGP9NG+Pw== X-UI-Out-Filterresults: notjunk:1;V03:K0:0/rZCYGml1o=:IqJUIg6mUjRAQAzasJWQZj MO3lnp93y8fpz1JDuYf4eo82VrsG6CDn7gRcRoenLt9sTDCTVP0e7HdCmPqSG0GSXj0NUNJ1E vPWysOFD1hxkC92MteNlYXw7O69QrzbsjV59cnm6TMLGHrzOssFhSh30giQHHg7AZiplHbgyz 2uqmdIlS0mgXjAW4ZTLhrjsYr0h8vPZ5PNQ5GLpTbWkhESJkTMTelDjAgHKZlPMfufImU38UK bi3akzOOqP1yGU2f7vacr6M74epV8E7m7+o0fKhVxuC7OPxcmxTHzZNvUzLxs7pQOHlYYJZ3r F0AyE35lZHP7/L34qVJfNkGDbzOzhh+TX6u6rD+EzRsLzzfY+mAvr1ZZ0BcwHP2hXRsV13ZIb qSxF81+0xZGS0KwrBzDR+WeImtt+MgcN0miHUgS8l1unuxuxkALIFMzIaZ/DNWLJIaNBrqJBd hHlLWXSvbcvh0piQWK6CIASEBphYCRqEWxKDHJRH4p/bAAoCzuHkY+ZUFFWgWKWR4gaSWn1K8 2VKNK7SKhyeJ5XVDPBRICHhyhP2aEmXnAtl4ZArperM53auxJKNJGtBMxgnBiGjYmuKgjgjlK esu5ccuBz2tWmbJHLaGRRJ5dqpAQKrMKHzhLUz+5APV6WaewjbgwKlXHD/Uo8Me+0/AkNVtNE xZ7vo2HaP3i3LZpYD3FJJdC+1O900sZefDnMXmIsJ7KG+vkJx9wMbneKL57hl1AbCoQcT7rG/ TsusJ7FTYhpwxv1v/98OBm6COCE+Nr/OxRjU1EF6SD67GZCmqhH6Nz1CSOGrJkkByIjsp+WG 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:179685 Archived-At: > I don't think I follow. Are you saying that > inhibit-free-realized-faces is non-nil when you run Lisp > interactively, Yes. > 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. The problem here seems that the original value is true. So if I'm not entirely misguided it must be somehow set by PRODUCE_GLYPHS outside of redisplay_internal. > 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? Your explanation coincides with how I expected this variable to behave. It does not coincide with the behavior I see. Thanks, martin