From unknown Wed Jun 25 03:52:30 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#38181 <38181@debbugs.gnu.org> To: bug#38181 <38181@debbugs.gnu.org> Subject: Status: Actual height of mode-line not taken into account Reply-To: bug#38181 <38181@debbugs.gnu.org> Date: Wed, 25 Jun 2025 10:52:30 +0000 retitle 38181 Actual height of mode-line not taken into account reassign 38181 emacs submitter 38181 Jonas Bernoulli severity 38181 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 12 11:53:11 2019 Received: (at submit) by debbugs.gnu.org; 12 Nov 2019 16:53:11 +0000 Received: from localhost ([127.0.0.1]:58295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUZPj-0004Tc-2v for submit@debbugs.gnu.org; Tue, 12 Nov 2019 11:53:11 -0500 Received: from lists.gnu.org ([209.51.188.17]:37767) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUZPh-0004TV-J3 for submit@debbugs.gnu.org; Tue, 12 Nov 2019 11:53:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56465) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iUZPg-00013v-CL for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2019 11:53:09 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_LOW autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iUZPf-0000Cw-8g for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2019 11:53:08 -0500 Received: from mail.hostpark.net ([212.243.197.30]:55814) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iUZPf-0000CO-2v for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2019 11:53:07 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 730181663E for ; Tue, 12 Nov 2019 17:53:04 +0100 (CET) X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10124) with ESMTP id DLoXplHuE8ux for ; Tue, 12 Nov 2019 17:53:04 +0100 (CET) Received: from customer (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 0305916618 for ; Tue, 12 Nov 2019 17:53:03 +0100 (CET) User-agent: mu4e 1.1.0; emacs 27.0.50 From: Jonas Bernoulli To: bug-gnu-emacs@gnu.org Subject: Actual height of mode-line not taken into account Message-ID: <87eeyd3ul0.fsf@bernoul.li> Date: Tue, 12 Nov 2019 17:52:59 +0100 MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 212.243.197.30 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) If the height of the mode-line is increased by inserting an image into it, then that height is not taken into account in a buffer/window until `redisplay' has been called at least once since the buffer was created. This function can be used for testing: (defun test-popup () (interactive) (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))))) ;; (redisplay) (fit-window-to-buffer win)))) First we can see that if we increase the height by modifying the `mode-line' and `mode-line-inactive' faces, then that IS taken into account. (set-face-attribute 'mode-line nil :height 250) (set-face-attribute 'mode-line-inactive nil :height 250) Now decrease the height again and try this instead: (setq-default mode-line-format (cons (propertize " " 'display (create-image "/* XPM */ static char * image[] = { \"3 60 1 1\", \"0 c #00aaff\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\" };" 'xpm t :ascent 'center)) mode-line-format)) When you call the command now, then the lower parts of the buffer are not visible because the window is not high enough. A work-around is to call `redisplay' before calling `fit-window-to-buffer', which could be done by advising that function. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 13 03:04:10 2019 Received: (at 38181) by debbugs.gnu.org; 13 Nov 2019 08:04:10 +0000 Received: from localhost ([127.0.0.1]:58797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUndJ-0005Qp-TL for submit@debbugs.gnu.org; Wed, 13 Nov 2019 03:04:10 -0500 Received: from mout.gmx.net ([212.227.17.20]:45589) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUndG-0005QH-RA for 38181@debbugs.gnu.org; Wed, 13 Nov 2019 03:04:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573632238; bh=chSJA4EUWxP2SikFdpsU0p6bEHLnT0u5R/rZdgDln+Y=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=hhRTVTK39QC/puA4+DuOgdqrICgpgirQK4sVU0oUmzI9UpyNKf/d6QxgVG2oAe/Vk P61zEvr6e9lUshgNAUrT0wOwbMJsXjyQrxWvVNU9l0Vm8BVU+BAdi7+OeKdWeeyqM4 13r3QdTKMpgmiAWAs1h+gsS/a+wVjotOgLRJ0g3k= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.103] ([46.125.249.127]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1My32F-1hgOEk3apD-00zVyV; Wed, 13 Nov 2019 09:03:58 +0100 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Jonas Bernoulli , 38181@debbugs.gnu.org References: <87eeyd3ul0.fsf@bernoul.li> From: martin rudalics Message-ID: <2d8a9ed2-4152-338a-06ef-fd69b9d2830f@gmx.at> Date: Wed, 13 Nov 2019 09:03:56 +0100 MIME-Version: 1.0 In-Reply-To: <87eeyd3ul0.fsf@bernoul.li> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:hNnBOviDMQZkkCygUDkeM1n9As8h0+phy3buM8oNeH7L5wfGDv7 e1+o9Ph8+k/EY742wpyfn2GDVxZpxJgHLqoUFDKbdkGZmG0PixfJW4A03NvfVvjC/zcjIc2 BD/FoDi0tFQemVO3azRQ7MWweJ0bAdJg/Vpr4HJbwGU/d3aRujJZYaNFhjmkJ7isuZvyTIH 0mabZCeaf4a8q/dPLVBSQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:+c5zJvLeZHM=:07ki1KiV5Zj9kHpgh6OoG4 9TtmbcpCJse3FdwDIZcZs7qcVbcoH6hOCalXCJJatbOOyoXtfcrv5xYsbMt/VXKr+UgD/wzwl YM95eZEpK9+OYqC0dpjQEJvjsO2d8Cbq8AuiWMIJWzhHWvDTYDz+xi6J++RxzYaDEkvp9lGSG BsLHReugOcuGapo6LtAIH8HnTYFkdU8fMxyzFhE9FtR26VWFjqzz5NJc+/2mv6JxzXnzi34WF 8biVs85VpuCR26p7uxPS2j5kdbZK7VRHta5DoyK3zCxLGCYRfs6sm4s6OMxxRb2pMLW/lOBrS /He3cthTfOHeRmtCJtAcJ3pNZgljwa04mL/yM+7PVRQhHIStreiVtFAEz67PJvLX4jGSIwUoD mLpa6oHB0MsQrEVa/1jWiNK9M0Y9TUhbJv6rY23IrDOx7Xd8wu0wRTP8FVB1wD0qT5oQ4CZyx 6+xMNcNifFAVd8oYjEqfibfUdOfxkWsuDQ4lTHjx8Xe/TrkGD2++RWftKy1/Hmtfckx5sKXjE rPvIvnDJNw4TsfE/6S+XMeOesxSQmWl1RNbl3ACuMsB81iknSXM8abW1EyaQ3bwcdajfjNoJI EHPLnnkmIdOfw0yjbbRSTHAr5Ntf/mq8iQqZu0Ab4jSNtkJNhYUKx9kgQRcZX2BXWF8LsVZSe d21iyjO/yKHqd638thFRU+/Wm/bgtBujKjd+9quwLUsYLuH5vu6cOQei38nnhuMVNKL95oS1p w1S21zuYAmI5NrkPAt3yfYKTpCmNxUc6Bni96XiPK4we9x+VcwTp2RAZnM0GUQWmauxdKWtRL 2/SUh5ijfy0u3+1YkT+/nKIJ6f4oUmciLZehU7bOFoso1k18lAO9d2ehkMy+ddl40ETuH7neW hhQ8Kf5QrdCxC4tTCQ6571d6w8ZQceoEVrbf3QbfALX03zBf8ecNjTockQGg8Kqwx66dcElLW YtvF5nxVwVm1d2u7bI6R6qias3OD27IXb4Kdrx6PLV2MsTLNDsUqKgvI79bVyldxKsbYHcK8a TJmY5pqrqV968XeKm0MhH7w3LVm3/n/2dOhrzri9yEqJ8bHYugTzq8UOqvtyABdSP6Ta10JuF 1WCNryhefOCz+QfqoqwL+rgoaWv+do/g+1EDrJXcpRTXWJbVa6QTIAA4pcQKx33Zh74XW96NM Bfozx1rSTTp4/+7pwVa9EwHffekqMnP6yYtm3940PYTPkKcevwsiV1B6Vf5HIM5dZ2JCnIK2y YYFtKWgCmDNRh8SZrT63fI2UvLTwp3Sw1FHIKF+god+QgvZ4qhMjnKM7pIdY= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > (setq-default > mode-line-format > (cons (propertize " " 'display > (create-image "/* XPM */ static char * image[] = { > \"3 60 1 1\", > \"0 c #00aaff\", > \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", > \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", > \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", > \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", > \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", > \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", > \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", > \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", > \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", > \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", > \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", > \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\" > };" 'xpm t :ascent 'center)) > mode-line-format)) When I evaluate that specification, the scroll bars are screwed up for all windows and remain so for all unselected windows. So this problem is not pertinent to 'fit-window-to-buffer' only. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 08:49:20 2019 Received: (at 38181) by debbugs.gnu.org; 15 Nov 2019 13:49:20 +0000 Received: from localhost ([127.0.0.1]:35834 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVbyR-0005Ky-Qy for submit@debbugs.gnu.org; Fri, 15 Nov 2019 08:49:20 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46085) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVbyO-0005Kl-Ve for 38181@debbugs.gnu.org; Fri, 15 Nov 2019 08:49:17 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57010) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iVbyJ-0000CL-6N; Fri, 15 Nov 2019 08:49:11 -0500 Received: from [176.228.60.248] (port=4307 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iVbyG-0002eX-QZ; Fri, 15 Nov 2019 08:49:10 -0500 Date: Fri, 15 Nov 2019 15:48:53 +0200 Message-Id: <83d0dt2qt6.fsf@gnu.org> From: Eli Zaretskii To: Jonas Bernoulli In-reply-to: <87eeyd3ul0.fsf@bernoul.li> (message from Jonas Bernoulli on Tue, 12 Nov 2019 17:52:59 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Jonas Bernoulli > Date: Tue, 12 Nov 2019 17:52:59 +0100 > > If the height of the mode-line is increased by inserting an image into > it, then that height is not taken into account in a buffer/window until > `redisplay' has been called at least once since the buffer was created. AFAIR, the mode line display is done lazily, because otherwise the mode line would flicker. When you change the face, that triggers a thorough redisplay, because any change in faces does that (it could mean many faces now have a different appearance). Adding an image to the mode line doesn't have that effect, which is why you need to force redisplay manually. So much for theory. Now for the practical aspects: how bad is it to have to invoke redisplay by hand in these cases? After all, they don't sound like something a Lisp program would do frequently. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 08:50:37 2019 Received: (at 38181) by debbugs.gnu.org; 15 Nov 2019 13:50:37 +0000 Received: from localhost ([127.0.0.1]:35838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVbzh-0005ND-8j for submit@debbugs.gnu.org; Fri, 15 Nov 2019 08:50:37 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46302) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVbzf-0005Mz-Un for 38181@debbugs.gnu.org; Fri, 15 Nov 2019 08:50:36 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57033) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iVbza-00014J-01; Fri, 15 Nov 2019 08:50:30 -0500 Received: from [176.228.60.248] (port=4383 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iVbzV-0002jj-3c; Fri, 15 Nov 2019 08:50:27 -0500 Date: Fri, 15 Nov 2019 15:50:08 +0200 Message-Id: <83bltd2qr3.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-reply-to: <2d8a9ed2-4152-338a-06ef-fd69b9d2830f@gmx.at> (message from martin rudalics on Wed, 13 Nov 2019 09:03:56 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <2d8a9ed2-4152-338a-06ef-fd69b9d2830f@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: martin rudalics > Date: Wed, 13 Nov 2019 09:03:56 +0100 > > When I evaluate that specification, the scroll bars are screwed up for > all windows and remain so for all unselected windows. Doesn't happen here, FWIW. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 09:24:21 2019 Received: (at 38181) by debbugs.gnu.org; 15 Nov 2019 14:24:21 +0000 Received: from localhost ([127.0.0.1]:35870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVcWK-0006Ah-US for submit@debbugs.gnu.org; Fri, 15 Nov 2019 09:24:21 -0500 Received: from mail.hostpark.net ([212.243.197.30]:54330) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVcWI-0006AY-VR for 38181@debbugs.gnu.org; Fri, 15 Nov 2019 09:24:19 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 9F8A01667E; Fri, 15 Nov 2019 15:24:17 +0100 (CET) X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10124) with ESMTP id 8N7Tck_ViUp7; Fri, 15 Nov 2019 15:24:17 +0100 (CET) Received: from customer (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 3710A16680; Fri, 15 Nov 2019 15:24:17 +0100 (CET) References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> User-agent: mu4e 1.1.0; emacs 27.0.50 From: Jonas Bernoulli To: Eli Zaretskii Subject: Re: bug#38181: Actual height of mode-line not taken into account In-reply-to: <83d0dt2qt6.fsf@gnu.org> Message-ID: <87a78xnrp0.fsf@bernoul.li> Date: Fri, 15 Nov 2019 15:24:11 +0100 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: > So much for theory. Now for the practical aspects: how bad is it to > have to invoke redisplay by hand in these cases? After all, they > don't sound like something a Lisp program would do frequently. Currently I do the manual redisplay by advising fit-window-to-buffer, which I don't think can be avoided. This results in some flickering, so I make sure it is only done once per buffer. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 10:11:45 2019 Received: (at 38181) by debbugs.gnu.org; 15 Nov 2019 15:11:45 +0000 Received: from localhost ([127.0.0.1]:37237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVdGC-0007fA-OE for submit@debbugs.gnu.org; Fri, 15 Nov 2019 10:11:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60230) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVdGA-0007eu-Db for 38181@debbugs.gnu.org; Fri, 15 Nov 2019 10:11:42 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58316) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iVdG4-0000UR-Vk; Fri, 15 Nov 2019 10:11:37 -0500 Received: from [176.228.60.248] (port=1362 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iVdG2-0000Nz-AT; Fri, 15 Nov 2019 10:11:36 -0500 Date: Fri, 15 Nov 2019 17:11:19 +0200 Message-Id: <835zjl2mzs.fsf@gnu.org> From: Eli Zaretskii To: Jonas Bernoulli In-reply-to: <87a78xnrp0.fsf@bernoul.li> (message from Jonas Bernoulli on Fri, 15 Nov 2019 15:24:11 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <87a78xnrp0.fsf@bernoul.li> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Jonas Bernoulli > Cc: 38181@debbugs.gnu.org > Date: Fri, 15 Nov 2019 15:24:11 +0100 > > > Eli Zaretskii writes: > > > So much for theory. Now for the practical aspects: how bad is it to > > have to invoke redisplay by hand in these cases? After all, they > > don't sound like something a Lisp program would do frequently. > > Currently I do the manual redisplay by advising fit-window-to-buffer, > which I don't think can be avoided. This results in some flickering, > so I make sure it is only done once per buffer. Why the need to use advising? Your recipe shows that calling redisplay before fit-window-to-buffer also solves the problem. Can't you do something like that only when you add such tall images to the mode line? An alternative would be to scale the image so that it doesn't enlarge the mode line, btw. Is that possible in your use cases? From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 14:38:55 2019 Received: (at 38181) by debbugs.gnu.org; 15 Nov 2019 19:38:55 +0000 Received: from localhost ([127.0.0.1]:37407 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVhQk-0005ad-Ji for submit@debbugs.gnu.org; Fri, 15 Nov 2019 14:38:54 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50997) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVhQc-0005aG-PQ for 38181@debbugs.gnu.org; Fri, 15 Nov 2019 14:38:53 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iVhQX-0000Tj-4m; Fri, 15 Nov 2019 14:38:41 -0500 Received: from [176.228.60.248] (port=2117 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iVhQW-0001Tg-HW; Fri, 15 Nov 2019 14:38:40 -0500 Date: Fri, 15 Nov 2019 21:38:27 +0200 Message-Id: <83r2290w24.fsf@gnu.org> From: Eli Zaretskii To: jonas@bernoul.li In-reply-to: <83d0dt2qt6.fsf@gnu.org> (message from Eli Zaretskii on Fri, 15 Nov 2019 15:48:53 +0200) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 15 Nov 2019 15:48:53 +0200 > From: Eli Zaretskii > Cc: 38181@debbugs.gnu.org > > > From: Jonas Bernoulli > > Date: Tue, 12 Nov 2019 17:52:59 +0100 > > > > If the height of the mode-line is increased by inserting an image into > > it, then that height is not taken into account in a buffer/window until > > `redisplay' has been called at least once since the buffer was created. > > AFAIR, the mode line display is done lazily, because otherwise the > mode line would flicker. When you change the face, that triggers a > thorough redisplay, because any change in faces does that (it could > mean many faces now have a different appearance). Adding an image to > the mode line doesn't have that effect, which is why you need to force > redisplay manually. Btw, I was wrong above: enlarging the mode-line faces also causes a similar problem. Try this slightly modified recipe: (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)))) and you will see that the buffer *test* isn't shown in its entirety, either. I think fit-window-to-buffer relies on window's metrics (like the number of lines in the text area) to be up to date, and that is only true after a window was redisplayed once since changing the mode-line height. Martin, is this correct? From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 15 18:53:02 2019 Received: (at 38181) by debbugs.gnu.org; 15 Nov 2019 23:53:02 +0000 Received: from localhost ([127.0.0.1]:37502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVlOg-00073t-C7 for submit@debbugs.gnu.org; Fri, 15 Nov 2019 18:53:02 -0500 Received: from mail.hostpark.net ([212.243.197.30]:58052) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVlOe-00073U-Do for 38181@debbugs.gnu.org; Fri, 15 Nov 2019 18:53:01 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id F174D16618; Sat, 16 Nov 2019 00:52:58 +0100 (CET) X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail0.hostpark.net [127.0.0.1]) (amavisd-new, port 10124) with ESMTP id iWgy6QbeR9HN; Sat, 16 Nov 2019 00:51:24 +0100 (CET) Received: from customer (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 26F83165F1; Sat, 16 Nov 2019 00:51:24 +0100 (CET) References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <87a78xnrp0.fsf@bernoul.li> <835zjl2mzs.fsf@gnu.org> User-agent: mu4e 1.1.0; emacs 27.0.50 From: Jonas Bernoulli To: Eli Zaretskii Subject: Re: bug#38181: Actual height of mode-line not taken into account In-reply-to: <835zjl2mzs.fsf@gnu.org> Date: Sat, 16 Nov 2019 00:51:19 +0100 Message-ID: <87eey8og08.fsf@bernoul.li> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: > Why the need to use advising? Your recipe shows that calling > redisplay before fit-window-to-buffer also solves the problem. Can't > you do something like that only when you add such tall images to the > mode line? This is about packages like powerline, spaceline, doom-modeline and my moody. These packages add images to the global mode-line-format to make them prettier. These packages do not create any buffers of their own and they never call fit-window-to-buffer themselves, but whenever that function is called for a new buffer redisplay has to be run first, so the advice is needed. > An alternative would be to scale the image so that it doesn't enlarge > the mode line, btw. Is that possible in your use cases? No because enlarging the mode-line is one of the things I did in order to make it prettier (imo). It's a goal not a means or side-effect. You can see a screenshot on https://github.com/tarsius/moody. Many other "mode-line prettifiers" also increase its height. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 03:20:43 2019 Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 08:20:43 +0000 Received: from localhost ([127.0.0.1]:37679 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVtJz-0008JX-GP for submit@debbugs.gnu.org; Sat, 16 Nov 2019 03:20:43 -0500 Received: from mout.gmx.net ([212.227.17.21]:38177) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVtJx-0008JH-2z for 38181@debbugs.gnu.org; Sat, 16 Nov 2019 03:20:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573892428; bh=1hxo5lq2IrYhioJm7QDJYvT03GElraFEr4CRDbVhvDE=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=X7J6tvumR7PU3+uKk7nKgPh2RDpG4NX/VS7pWmxBVYADPYy3rA6V4xHWR9x8z9l5L JpRppqA5QwwtiX8q9ra6Rrf/qyBoYgXF05/CbhT+s3BfefxXQsTKlJpixEMnW4E3xM TdgKYyxDp35InAkZnBSOWBsyHNUr355mPv9E11ZE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.104] ([46.125.249.58]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MsHnm-1hcHrC2ERO-00tkaS; Sat, 16 Nov 2019 09:20:28 +0100 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii , jonas@bernoul.li References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> From: martin rudalics Message-ID: Date: Sat, 16 Nov 2019 09:20:27 +0100 MIME-Version: 1.0 In-Reply-To: <83r2290w24.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------EEAD7462F06F3F75B4F2F9A7" Content-Language: de-AT X-Provags-ID: V03:K1:ucGkFA0LKF0KEix6aJPqPjtzFWfcWnreTUXtiyTXLK8COz8zv2/ s27GNYqvNF7gFsTFr0mOhWUch0kUE75DdqsCxu9PZUtNMpVODF5jNUQFS0TrBUPjybhszlD 4vKHaZVc6erLT3uLzQygkXdA7m5gjaCblFfCg6wsAFPN2/doUq0GwAIb9mfhDjg+Db1dcwm l4pD+8wvlZlNoN/pC1hGg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Wpnqartv9cA=:NrEwcsHKggJY64eK1tFzh9 gmRWPIaywXkyj+dZ3zVpysDETJz1ZUrL4htCF7cXdVGAWGNF1t7+TQRjuBjw9r9LKt573dpgO ekunQng9ry3dC/+hcqXANGdvUwdoTw1OQ5XUFwYFM+Cm7qiMcDOutHwegXrsHbX1FUjsOK7e5 WAImwEkniu1+0ubKhB3p1amNUnfXdNwHvPe+n9kNqbhO3PR4Ix5+2uAxo9pyh9vN0Yw8uZNnE ncqweWK6eKJl3D1ZUvk+glTerQNyMGGR0xkfBtN7yAY6IHe0P4v4SvivyPgubPw0UGXgowCBG TdvXpWbOLKQs0mgIqOsEo/lRnkiLpqK3DAFeIkIU6yP+BbYkgVmZAcYtHDkw0vmsO3+Bzf8S1 Tr0v5GMxJePIG0LfI4gUzQX54b0cbTkDjmJcVdNh7gxM0bRfQMyNF2Txi8XvmWMCEMPIITChF YBCnSGqH+4bzts73XOu4frVMaa3KoA35JNCACS4cW/GfKfTT0JSHxbaLS9aBPIZ9MMrl39/0w jj3WaqFhr6J6PaOIGYGFtuEK1HWD78T3ma1Mutf9v9X3v6VanPKWOaOCk84NC3IKSTTeqFETf uuixW+C4yRn0VLhsW9CNDg5YxeJvILD3dP+Ed5e1Ltnl+AU8oAL64mos3x+cAE/WPJ5wRXowc z+Yg1zzrrrRhVhxnd8MEbfgKjFqFQxr/G/oiSYYyGoalGAcgxyRSdu9Fm39rhJb5BNbjL/mgC kByxkWL6dXuOtW0BU5m79HvF7AFzGG8WaSsclacKUfjy89DH8AhwDvMGeSO0d7oM7bZt97oge 1m7/8CVMATpyK+QrILU23L+Ry9PhKrDaBHXbkl210LrEP+re+eFFE/PPYCWLiSIo8q8cIMxDT nD07Wo9XbNcZuWlcP4b8RTndpI4RlQ/cdfOlL0nf9XDJw7Xmz+Ix3/u4Oxdl3OsNLVLG8QyM8 A4f51L6dyTg/OSSy+yd7LeVdojMtcmdVP3RWhZzMvwAqqc0GFrb/Z6JL5cD4cd52XKQoNg7bv Q/HfALQk2vqKiiavvtDVeWOZv/o7+JdixQlIcYIw925+Sa7kBg2U6VeaJNem2uhswNpBlGgZ5 0dHsJUTcFE+ylMxPpicr5ETRb1dN3pvObaq+f/JqRTVpjFq1Ch+RbXFFetwuqYqXOskk9+L85 e8gJF618jFdVDTbbR3VqmygkIV7Tvaf2Tji6Inr3rQopuVSkmRWKcce9Wmf5TxRB3C8Lz+qrQ v1uwaUGQI46imRNA2MxE+JAs8Spjlk6on992LKA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --------------EEAD7462F06F3F75B4F2F9A7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit > I think fit-window-to-buffer relies on window's metrics (like the > number of lines in the text area) to be up to date, and that is only > true after a window was redisplayed once since changing the mode-line > height. Martin, is this correct? Yes. But, as I mentioned earlier, the problem shows up with the scroll bar immediately when Jonas' form is evaluated, see the attached screenshot. Code like 'fit-window-to-buffer' works on the text area only, it doesn't care whether a scroll bar or mode line changed size since last redisplay. martin --------------EEAD7462F06F3F75B4F2F9A7 Content-Type: image/png; name="mode-line-vs-scroll-bar.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mode-line-vs-scroll-bar.png" iVBORw0KGgoAAAANSUhEUgAAAqgAAAKTCAIAAABaZ21lAAAACXBIWXMAAA7DAAAOwwHHb6hk AAAgAElEQVR4nO3de3xU9Z3/8c/JjZvIXVHGALlwiU1B+WkciphQow2yipeg2y4sum5ok7UG 0Ra0unZthQoxsW6yhWplQ+1DjPdiokU7EVnSyKJW1nBJCBAGQbkFQpAkM3N+f5yZyWQyM5lJ JgnJ9/V85I/JmTPne77nzJn3+X7Pmflq06bPEAAAoIYoEXlt3fLeXg0AAFrd85NVr/xXj2ZT D5f4y9w1SyZc1mPFrT1w5N8LHhaRu7JWRfRYqQAAoNdFBX5ad4gWISJSV3O6bp+94WyEJvrF w/QJiVGXj79YdNF15wwAAODCFyj4jdQ/aj378Ye2+ubRA4cP1SIjW5rsB2rPf7rzzOWjv5l9 85DRlwxxnxwAAIALnN/gd+gSESF7vjhVXj54eOKkkQOjHc32mEhtzOhBYy8bYj3YuP/Lr0te 2v+DO5onJo4g+wEA6BP8xnWEJkfrzn5UPmjUdya12BxnjjWeb2gaGBMxbGjMd757yX05371s 3NChoxPef8N28vhZUh8AgD4hUFf/37a0XJyQ2HzufPzE4dfNHDd4cHTMgMjz51oio7SD1fXf nm6O0B1DLhq/5f298390UY+tsU8HX3nsxmf3Ov9JXvzBi7eMd/7z2ePXPv3K7Y9Wr7iq3fzy 2Bu/XmxyTvloZeb94j2byNH1//LAr3d6Lvazx699Ld7jhdI6pX1ZbWeuWJf44Gbjiaseev7V e8aGp/IAgB6UeG1mgGerPykJb3HX/+kt48HHP5zvb0pI/DbVD9eeOdk0OmpAdNNZ28UXxSRO HqnbHX/6r89fLvz8D2v+9w+/+aThxLdis0VHDDhy4KJjX5/pRNlhcnT9v2TeuP+u6k9KnH/3 H77x2nUftc4w6aqa19ZbPV/y2QvuswSD9d3CmvR7vGazvrvg2gf23e9a7C/FUtHhyky6qubp x33OVrEu8cGDj71hLO35uZsfWPDK0RBqCQBQklfedzH1JUDw1x2wRQ2+yH6+ZfDAqO1bD//p 91/YbI7kGWOjIrSzx7+N0CRCRG/RHTZ7hGPIwZpznSu+6w6+8nxp+vPVKy5b/y+ZiddmLviX xxYcvLX6Obl/5WfueSYnSOlWj5St2P7K7en3eC5k6zZJv/X+dM/Zjq7/9/WTnyt5yuyaYLpl sVk6NPf+xXteePeg9+Sj61/YfM9z7n6CsYt/uViefecj79kAAH1Da2vT9dd9ZYWrrW/wG/xn 6iUiIlJrcTQ1tkQ49KOHGnZ/fux73499+Dez5/1oapSmOZodul0Xmz1GYuqPt/hYhPXdBddm Jl6bmehsf3/2+LWPra9wTny8Qg6+8ljitZmJ12a6274frTTmz0xsje2jRqIbL2n/r2Xz+Jx7 xjrj/5OSnIS9k8ePFfOtj9Vsd8dq/MK7Jrem7NH1Lxx8bOE1Hit61LJZ5s4aO37WTNm8w5nZ 1h2lO9NvDCLpvV1xS07C+ke8WvPtl2aaMTf54H6rAADQIc+k70rqS4Br/Lqui123nbePGD7w 1numxE8ZaWtxfFFxpOaLY8e/Omtvtus2h+aQKD3SbvN59vDZ43dsm/tGyasmkYp1C145esM9 IrL31y/M/OCTkvEV6xIfzNzz0PPVn4yVinWJD77z0T1ZN4jcsKKkeoUYl8bXL7xqseno+n95 oDT9+eoXXZfDK975dcKj1S+6L6If2Sfj0kQO7Je5C8eKyISJk0REZOzEhIP7rXKDs4V91Y23 P/1BRdYNZhHrjlKZudok+9xr6poiMmOuPG+x3uJslyePm+B72+z99R2Zv24zZdJjHv/csOLR D659fv0sz/sAfC5t775DIibvqQAAdB+/wX/xMP1oXVNU9MD5/zhl4uSRx482/v5XlccPnYnU tIgILSYyIlK0SLsW44g632QbNirS+/XWr/bI3lfcAXm70cKe9NgvbxkvIuZr7pGD8bPGivPx a86Qbr39bdJj4mwo57zocRPcFeOuevPpBRM97oxLuHy8HLXUjJ/oTNDx8VeIyNH9rVNERG5Y uLjw3989aL7lwIb1k+8vGS+tFwIObt0m6Q+MFxEZm5YuN274bLFxd97OwwdExkt7kx5rd3Nf 2xmueuq57YkbPlu8wmOaj6VNir/Cx9IBAMHr4Vvteou7k9943C1d/VfERTefOaPbtAN7TolI dExk/JSR8VeOvnzisFFjBg+MjopqjohqjohuiW5x1JsSBvlaRvoL7osf3nfL+2J9d8GD8sIn JdWfPP9Ysp95TLe8+knJanne1dUv8ub2j1zte5HPXnh2875DItYdpQnX3NDmhTPmyjZLxbuF NYvvb9OB/9kLz+797NkHjMsHNz67V97c/pExf/LmDzq+m88P862Ped7l135p1h2lO9ucmgAA +hDnhWmPv+4rK8CN/Z0QIPiHjbj4RITNZnlj74u/+tv+L0+kL5iUmT3t9n/97j8/lvLon35w 72rzsMGDWxq/HTGp/rKxI7xfb7p8smwuDOnG9UOHPzP6w607So1v0JlmzE32sZDx9/z6g4cm 7Tl4VOSqG2/fXPjK0RsWziy9IzPx2u03vrF4z4OZiXcczvE+1Ri7+P7xv35wvaTPaNPsrtj+ SvLiD1rvznj+MWdCj118f/orD2a2hrf13fUhnAeMXfzLxXsefPqV1tLTX3nQ/V2Dzx6/Y708 dOsN/l4NAICItEv9rmd/oO/xz/z+oDf+u/bSyybt/7/je3ccHXPZRbFxIy65fOjIMYPrdpys 3XJcPxn5tb57/m3tUl9E5Kqn3li84I4HEp8VEZHbH61e4WsuT+ZbH3vhgRuvXS/J6fc4W/xj F7/46L5rnQu557mSp8R9LSD9hU/GivOC+gML5PlXP7nFeM0Nrgc+lp8sE9t+e/6j8s1XpT/v cSowNi190q/LP3vKfJWYs6rfGLfgjsxE45nkxR+82FEVPJluWf3QthufdZeeVf3cOvcp4T3P lbzaiTsHAQBt9Xxnfg+X2L5Xv4s392nTps/wOSyvQ9cjNO3Lz4998Lo+auSEwQMHDB82MFLX bGfs5762OU6J6LavInbN+XHk5CmXOhx6RITWlfXooo9WZt7/pvu/9Bc+yaIxDQB9F8Pyhpfn sLx+W/wRmuZw6FdOHzN85OkP39p9pG74GRkW4xgQ7YgQ3f6tVh8T//XtC4aPHTtcd0jvpr60 fh0AAAAEEqirPyJC0x0yLnbYop8Oq9lzfH9VXcNJXRwydIw+I3lwXPwE0YXheQAA6EMCBb9I a6gnTB6dMLn906L1clMfAACEgNY6AAAKIfgBAFBIm67+3V+3+wE+AAB6wz0/WdWPS5w6IGrt gSM9VpynNsF//fVzemUlAADw9OGH5FE4Hdu72f2Yrn4AABRC8AMAoBCCHwAAhRD8AAAoJJjg 35w7vFV6Ua3UFqUPTy+qNZ4yHnRFm+Xnbm7/bHpRrXgUGp6iQlhWWIoOVuCt4Wte964IrVZd WK1QN2AY3iftltClnbI5t6NN2y26943UfiMH2OxhOXIB9ElBtvivefrTesPm7DiJy95cvzk7 Loyr0br8gnQ/s7QW2tnPrM25wzO/dBX06e1vXh1wKR6lhL++gbm2xqdPf5kZIJ8252auX1xi 7BLPx90ivcDYbiWLXavXk1vEh27cKeENxV58IwGAD+p09dcWPbN+cYn7Yzcue+3T8uhve6HZ F7y4xCvly+pACXTNpHifjwEA8K1zwe+rSVRblB5c/3RQXEtLL6puW+jm3OGZ62X7o1eHWE7t e29uX3yLZ3dC3A9uv8aI1c25w9OLNrtLrDU6BzxK8ahvazXd5W/OHZ5eVJTbtgM8HJtj87vr F/+sXSeH93ZILyryeFzrq/DNucPTc3PThw/P3Rze/eRja/iZ2O65Lpfu3iZey2y/NztaSJt9 1+4NFmhjelwB8VX/3M1dfyOFid8NH9LmAtAfBBn82x+9OvDn9ebcq9+83eigLpFnQv74cC/f 9dl69aNXltTX19evlTfXt5kzvcDd2+z3qoAfPprE2/fuc63AM7K2vr7+06fl0SVFtf5KaV2x +k+f/jLT/Tm5/dG9txgd4duNXoTNv3XNF/Jqtm6NTCnx++LWNdycne3xOM7Pvtj+5aS19fUF 6V1aMS8+t4a/TWS8IoylB1im194M/Hqvfee16wNuTM8rIOufcZ2FuF9QX5De5TdSaFqPU+MN tL61uACHZ0ibC0CfF/I1ft+f17XVX7bG1Xp3nAbNvfyCdGNp1zz903QRkbjsny0OcVl++Vgt 97nANU+vzY5zlud/9WurvxRXt0GbOV2rm37LYqNzPn7SNeszO9t+cl/jn/RMJ9pgvvfFNbf/ IE6kiyvWvqB2W8PvJpIwlx5ome32ZqCOhnb7zruO/jemuJv8roitfe/N7c5emkCCfyOFpvU4 dd2QEaAWHq8K5s0PoL8I4zX+xSXuD5ywtebCJ+4Ht1+z/l3PT/3a997cfmWi90d0bfWXYSku e3N9/VpZ0qU+7bgf3H5N5z6I/e+LsKxYp3VH6YGW6dqbcdmbO//W9L8xa4vSM6XEaLZf09n1 7yHBHJ5hevMDuLCFKfjjEq+U9aH38Ptfmqujs7bomfVhWmj2zxavb71JfnPu1Y+Ks3klItvf fM+4Ot7uVgCvFRPX2UNt0TPr/c/pLHLzp09f04mGm1Pte29uN/ok4ie5zwA2v7s+8KuC2Bdd XTGPgry3RhCbKDylB1pmcHszqOUG3Jj79jr3T+17b2435v/B7dcEcSCE+Ebqqg7eEuHbXAD6 gnC1+NMLPn1aOroRwL/Wa5PpRbUi6QUli9dnDh8+fPgSuX1xu7JuWRz6zX1iXBaXTNflTynx /GbVNVfuXTJ8+PDhVz96pfO6us9S0gs+ffpLYxFXv3n7p/6bj66bvq5+9MqOO369ubbG1W/e /ulmdyessUGGvyuLO6xngH3RpRXzUVC7rRFwE4Vls3jdg+Zjme33Zmj18tj1ATdm+k+dzy3Z e6WzxR+XvbnkyjZ3rHTtjRQegQ/PLm4uAH2MNm36jNfWLTf+GTNJzaN+c+7wZyZ9yhes+wf2 ZkjYXIAS3KPz3ZW1Sp3v8QMAAIV+wAcAAEhUb6/AhSC9oF7Naxz9EnszJGwuQDm0+AEAUAjB DwCAQtp09Tc2NvbWegAAgB7gfY1/7969vbIeAACgO/z5z3/+yT1m97909QMAoBCCHwAAhRD8 AAAohOAHAEAhyv2AT9qctOBntvzV0n1rAgSWltb6XrVYeCsCCI9gg9/zMyiAC/zjKW1O2ra/ /Wnw4EHBzPzxth1pc9LIfvSM9ofY+++/n56e3tLS8otf/KL9s919rPWPQx5Ae0EFf1pa2s6d O+Pj4wcN8h2Zzc3NBw8efOKJJ9LS0i7YD4K0OWlfffX5N8f3Bzn/9TNnPP+7X1xQ2V9aWtq5 F86dOzeY2Q4cODBp0qTm5ubOlRJGnVuT0tJSfzUN8NSFIC0trbHxqOeUe+/9yU033fTf//3f DQ0NAwYMWLDg9gcfzJ4+Pdl4du/f37tqZsjHWvBbtX8c8gB8CrbFH+AjQERiYmJOnDixYsWK J554IikpqXMfBD5bGOH9TDlQV+V+fP78eX+znfv2W+PB6BEXhbH0LiotLf3+97/f0tJy5MiR K664wpjocDhERNM0XdeNx26aph0+fHjcuHEtLS09Fnv9LwaCPNkKy+at27PFeFC1e3/jmWMi smPHDl3Xr7/++o/+uumL//3Q1rDvkktGisjmP7/Y9eIC64FDHkCvCDb4fX4E6LpuRI6u601N TZdffvmwYcN+//vfd+LTf86ctHffe3natGTPiRs2/PHhR/5tzer/DGlRAZw8dSrAsw1nGrym HD91NlxFh4XD4WhsbGxqajpz5ozdbjemREREOBwOr+y32Wwi0tLScubMmdOnT/fM6gXZOdxN SktLZ8+e7fMUp7S09Oabb+702c911113ySWX+HtW1/X6+vqwnFodP1EvIseP1//XC6+Xvre1 vr7+hz/84YgRI5qbm2en3bL2xZJ/XHDTpPjYMWOGNzf5PW0Nl+4+5AH0lk7e3Kc7OTQtQtcd ui6nTp2cOnXqsGHDbrzxxvz8/FA/CAYPHpKcnHTsxD738kXkyu9M+NOGcHY7N5xpuPTSSwYO HGj869XoH+zxSXfu22/L3t065TvxYSw9LHRdj4yMbGlpEddWMsK+ubk5KirKbrdHR0cbfbma pkVERBj7qQdWLC0t7dThv4wYd1MPlOXP0KFDfSZ0fHyX9uMll1xibHB/LrooPD1Do0cNF5FV ecW/fCr/9ddfF5GYmJidO3dqmjZkyJCRo01btn6eEHfFqJHDpW3vTg8I+yEPoLeEHPzu41/X Rdcdmia67tB1vbGxccCAASIyZsyY1NTU4uLi4D8I7v/XRb/9z1+LyLfnvnXoekREhKZpERHa pWNHTbky7kf/tODlP74a6nr6M3DgwIMH6wLPYzT09x880ung91n3rn8yGu2tyMjIiRMnBjP/ //3f/4nr/KBbpaWlnTrykX7KIh7t/l6JgREjRng1vktLS2+55ZZz5851ZbFHjhxpamoSkYiI iNjY2FOnTp0+fXrChAkHDhwYNmzYiBEjurreIiJy5szZ5hbb7FnTf/nEQ6fqG86fb/J8NjIy 8h8X3BShaafqGxw9cS7n1B2HPIBeFELwex3/xj9Gt5/oenNzy/Dhw71eEuQHgd1mT0m5umbf 3xvPnbPb9ciIiMioiOjoaE3TvpOc+PWRY3PmzPGZXl3/lPlyV+2p484e/hGjh1461m+Pbkgs FotX3Y047PonoyP0pl53B39aWtopa6mR+iernhSRIwf37as90vMxYLfbR44cOW7cOM+J8fHx uq538XrHZZdd5vnviBEjjLCfMGFCVxbr5eKLLxKRW+fOvnio7y6EpMkTjGv8PcN9yH/wwYf5 +Ss//vgTEUlLm/mTn+R+f86crhzyAHpRCMHvcNg9I9/4VBBX8i/IvCv1htmNjWethw8fPXL0 73//orHh2O//8KdglhwZFRkzIOb0mbMtLS1N55sjIyOioqN0h+5w6PHxsROyTP/20/sHDRwW HRMdoWkDBgyIGRAdGRlVX3+i658yp443zLp+mueUMF7Xd69e2C9+19fXdziPcZnfuAMgvKV7 Mnr49dPbPCdeNj7+svHxf39r6LQejIG5c+fW1tbGx8efPHnS3eh3N/e/+uqrrlyDr6qqstvt ycnJu3fvHjhwoNHKLysr85zH522AIRVqtPhF5DtJcSLywV8/2fH57u07qmw2u3uepCkTNU37 5sh+6f7OFeOQf+ON11evfvonP/nnVasebWw8V1n5+S9/+fj589/eecftnT7kAfSikIK/TeQb 5wBahGacCTh0R8yAGJttwMSJEy8ZM2b48GF7qj4LcslfHz0eGRF55Mg3AwYMPH/unKZFREVF 6qLbbY4BA2MGDhrQbDvb1NCg243iHHaHbmuxnzwVhnvWRowe2vWF+GQ0+r1OTbr+Aa3rekuL j5aWT0ePHpXubPGnpaWVv7nMK/Xdrpg0rXz9t6k9mP27d+9OTEwcOXLkmDFjjCljx44VkfPn zxubotOSkpKMB1OmTDEelJWVXXfddcby/WloaAjppj+jxe/2t+3/928PPvbnefMCv2rXrl3d dF+9cci/+OJ//fjHi9LTvz9kyKU7d/5PYuKEf/iHG9evX3fddddFRkUOGNCZQx5ALwot+D0j 33ig2TXjRMButw8eNGjQwIE2m81us48Zc8mBmJggl3z27LctNsfJY/VNLS2/K9x47JuTwa/V nDlzROSvf/1r8C/xdOnYS3w28c81dumSsKcwNsuMtnt0dHTwL+nWm/ssFktqWtrvcgaYp3qv 0rD41IvH/7/L4r8j8l6Pdf8ajf6JEyceO3astLR02LBh3/ve986dO2e1Wrt4y737Gr9xXd/Y pIFTX0SGDg3ttPLAga+abTb3v/WnG+Z1lPoiMnXq1JBKCZ7D4dAdjo8/rszPf/Kyy5L+9rdN jY3nzp49d/nl4z744Pljx46NHjVq5MiRdrs91EMeQC8KJfjtdiPyRcTV6nd+t0eMb5I5HA6H w2azDRs21G5vcTjsHS7TTdel8dumrVt2bP+kYsjQKLvD1tH8us1ma2mx2VpsItG3z7/7P5// r2AKOnnqVPuk9xnzZ86c6WL8G41+9+OuLMpLMF397h7+iIhuHJHBqGP+/fqc6W0+9E/vK2/8 6vPLzPe//fwNtz3wUfetgJcvv/xy4sSJJpPpxIkTI0aMOH36tMPhOHToUHJycscv9s/zGr9x XX/37t0iYrVajROCyMjICRMmnDx58tSpU/Hx8fv27RsxYsTIkaFdj58w4XLPf2v3HxaRV155 xeiuGDRo0JIlS0SkoqKisrIyNze3oKAgJSXFbDb7XFrXOex2u8MuojU2nqurqzp79lxj47nG xnOjRo2NiIg4fuz4kMGDo6Oj7XZ7Jw55AL0l9K5+0Y0HEUbku77Ua0S+3W4zHg+7+OLBgweH sib2c+e+/fzTPaNHj6o+8LG/mdyNV5vNbrPZbS22pubm+vqG803BJvT+g0fK3t0azJzjxo4S kf939XeCXHJ7npf2w9Lq1TRNRILv6v/qq6964Ot8ruyXOdNjpv2b86TqdzkDzFPrTx/8ZFzC d0V6Lvjnzp27adOmjIyMKVOm7Nu3z+FwVFRUdP0b9sY1fhExLvMbd7OLiMlk8pxt5MiRRth3 7guEddavPe/kNy7t33PPPV6zmc1mI+xzc3M7UUrwHA6H3WafPTvlb3/7dMqUM+fOfdvYeG7E iEsmTpwyZ86s8+fPNzU1NTc3GfeRhH7IA+gd3ThIz9CLhoQ0/97d+z/7rOLc+dPGz9GIx6+F eM7mOslw2Fps55uaWpptVTurrYeCvYI7cfxl2dmZHc7WcKbh+KmzXWnxt7+hLyxf53M4HBdd dFFVVZXXLXvGRjO2m8Fut0dFRWmaFvg76GFhZP/vcjT34x8XNr33H5EDR1njpl3b3aV7mTt3 bmlp6Y033nj55ZdXVFSEZZnua/wiMmXKFF3XjRb/F198Ybfbr7rqqi+//HLgwIFGK9/d7g+1 lFjTpZ7/Xj19ioj89Kc/PXfu3AsvvPDzn//c6HgwWvnudn9X69aRf/iHO9evf+HOO+dedtml w4aNHjPGdPXV14rIv96f7XVshnrIA+gVIQS/zW5zHue6ruu6zeOY13XdZmsxYkl3OHTRddHt ofT7ORyOHdv3XHLJJbv3fSSii2hG817TRNfFfSrgcOhGK6Slxdbc0tLc1HzixOkv/r4nOioy +LLa/0Jfe8dPnd1qqbz62k72D3v18Lv/7WL2G1s4Ojra+K6juzWvaZrD4YiMjPScMzIy0m63 tz9z6iZe1zXS0tJ+8MS5v/9nbQ8U7dPHH388bty4ESNGnAr4c41B8nmNX0S++93vGg+uvPJK 98zudn+odlYdbLG12JqdjX7j9tXf/va3xr+/+c1vPGd2t/u7j81uszvsGRk/aGxs3LJls8Wy TURSUq57aGnus/kF82+/Y0Px+u99b6YYV/tCPOQB9JYQgt9ut4tHv7Gu6w6HPSIi0riwZ7fb NRER3e6wu24BDGE9Dh44tGjRD5ubzzc1NbtOL8ShOyK0CLvD7nDokZERdrvD1mITTWtuarY7 HE3nm5ubWw7VHX3zjQ8+/LCTN/f5ZNwEcPjoias79fL21/U9Q7Er2W9smZaWFk3TvvnmGxGJ iYmJiYnRPYiIcdnFZrNddtllgwYN6pngF1/ZHzNywp6ab3qmdK9v0zU1NdXW1rZ/qhPd/rqu d3iN37iuLyJGo//AgQN2uz3URn9y0njPf0eOGCYe1/iNi/rGU0ajf+3atd9++233Nfrtdrvu cERFRs5JS5s6Zco9dy9qbm7StAgtwtmxtHDR4lc3/umqq6YbvxEZ0iEPoLeEdnOf0b2s67qI Lq2/72Hc6udw6LrdbvdMoODVnz794x/f/7+fvy8idrvDKMhuFOf6lTK73W6z2R0OR9P5Zpvd rjv0+vqGzz6rio7u/AWLrR//3f3Y8wd8Ot3J7+9uPncodqXF726+nzhxYuzYsZdeemlERIT7 3j2bzdbS0uJwOE6fPn3y5MmYmJjGxsZhw4b1WPBLu9rZhyTUHDjeY6Ubnfzux+IR+e6nOvGj +vX19f5+lNfzGr9nzHfuh3127607d77Z3eLfsvVTaXuN3yvjjXv9uo9xyEdHRw8bdrHd3hIV Hdl0vsn47chlD+WuycvXNG3B3T984fe/u/76Wd16DymAMAqlq9/W4tnc10R00TXRXLHfyvVP CP1+5881DRoc09j4rc1mt9vtRve+iBjLE1232e0Oh8PWYrfb7c3NLcazR7469n7Z/7z33l+C LOX4qbNDL/b+hpXxAz7HT501xuLzvOe/oSHkH/MJkOthubHf2AV2u/2SSy6JjIzctWuX0eK8 8sorW1pa7Ha73W4fMWLE0aNHBw4c6B7Cp+vlds7Fl09deNvKHvguX/uAb/+v11NBCvwq4xq/ iITlMv+USbGe/w4dOkR69Rq/+5AfNGjgqFGjLrroIputRRNNNMnMvPPb8+eLin4nIvf/6493 /O/fBg4YwF39QJ8QbPA3NzcbrXkR3Tjy7a4R4YwLzOL61q/ouuunfkJYj/SbflC978sjR75p abHbbMZXA5wJp4lms9sddofR4m9qatZ1EdGbmpr37N4vXetejJ3o7MJtn/oXLON2h4iICM+L +jabzdgLMTExUVFR7qc8b/frSWlpaZWbckr+/PeOZw0Tdzu+fVQHeCqkJXsyluO+xi/huMz/ RdX+5mabw+YcmGp87FjpvWv8Xof8wIEDjK4148COiorKvOvO4cOGPb3yNyJy8sSJkSNHOnpy CAEAnRVs8J89e9a4xi+a6LruORSsEfyaiO5w6M7efufv+Qe5cIvFcsW4yZ1Y+5HBRo0AACAA SURBVOjoqL/8ZXMnXug2eMjgPhH2BuOMSoz7LUQcDkdTU5P7ur6u61FRUQMGDIiMjHRflLHZ bD2f/WlpaW+88E87vrAu+4/SHvvZPs+f6Q3+qS4K4zX+c2eOfjepzdhLvXuNv/0hL67zSE3T YmJiRowYnnrD7CuTpp4/f77+9OkhQy6ixQ/0CcEGv9VqHX7xYPcFfTFGgtc0h/GFfodDdzUF jKa+w2EP6fS/x+Jh/8EjWy2VPVNW2Bk3qNuNqx42m9E1YjzlcDhiYmIGDBjg7tt3n5n15DV+ Q1huaAiJ0ZT3usDv9ZQxsevf6fcUxmv8R+q+/LzijePHv2m2O843nD3fZKvbf1B67xp/4EM+ MiJi0MCBo0aNjIiMOHWqPiYm2ujp6771ARAuwQb/3yrKB8dommiuO/s0h+7QPL94J5pxvm8c /A7d8b+fXog/3H2u8dzoMaODmTPI2XrM3Llz//KXv4wdOzY6Onrw4MH19fWDBg2aOHGi8WMy UVFR7m/tG2216OjoXry6fwEO0Rb25n5DQ0PgH+VtaOj4i6MGi8Xy3RQfIznt2rWrw1/k3bVr V5ClhCSYQ95ma2lpaWlqtkVo2uGDkZ99/kV3rAmA8Aoq+D2/phWSC+3TP9S2/v6DR+rrwzAU ULjcdNNN7vQ6fPhwMC9paGg4ffp0kM3cCRMmNDc3d379wqcTaxKgjuFt5bt9+OGHYVyaz4PF 84eDQn1te8Fv1X5zyANoL9gWfz84ni1/taTNCfmzzPLXC6vi3ZRhCFXP7IhePO76wSEPwKdu /MneC9CFluIAAPQwfnMDAACFEPwAACiE4AcAQCEEPwAACmlzc19eXl5vrQcAAOgBbYL/ySef 9DlT4F8pAQAA3cHf74Dt2LEjxCW1DpSq1tf5AADoH1JTU4Ocs7y83PNfrvEDAKCQIIPfWnHr QxW13bsq3VluqMuhvj2D+vbMcvp6fQGEU5DBb5o0T3Z/YPXxzIfPrYm/c83PKk+se2hN/J0v rWud58S651669c418Q95TgxxemfKDW39Q52f+namXv6mU9+Oyw1t/UOdv2/UF0A4BdvVPyrr oTG/eb26/RMTTaNERiWMGxU/XkTGxLtGKf3wuXfkznvfef3hfc/eG//6JvdoJiFOD7ncUNef +lJf6nvB1xdAGAV/jd9k/vnBrX5OzF3H7fhRE51Tqt8/OOVG18E80XTs/crOTQ+13JDW39na +NlzL8XfuSb+zjW3PlcdcH7qS32pby/VF0DHli5dGsxsIdzcNyrrbh8n73GmMcZxO9E0SsaP jvPz4t1+uvKCmN6lcgOu/6isZ+/9+fgTu2XW5tcf3vf6bVPafEJR3xDKpb5BT6e+IZQLIGhG 6geT/SHd1Z/i6+Q9Zd6+Z81xInF33rvvwcRQFtfj5fpcjkx58MHEOBGRxJvHd0+5oaK+nSuX +or05/oC8MvI+/z8fAki+0P7Op9x8n4iqHkPntjv8d8UU2enh1puIKEuh/r6R307N70z6+mP avUF4JNn6geT/aF+jz/F/POD7wRxC27ij38o+5yzVf/uf8bcnNK56aGWK9J6w3BX1j/U+alv 56Z3Zj2pb+eWE8r8F2p9Afhm5H37xz6F/Mt9o7LuHhP/+omsB0cFni/uTrM8tyZ+i4iM+vlz 936/s9NDLVek+v0tIuO/9+MUn896LufEuode+s1BkTtl3evz5Lk1WVtEtrwkz92bZfI5P/Wl vtS3d+sLoL32Sd9B9k+bPqP6kxLj74wfelvH1y79w9pDeo8LrtxD2/7hjsCzhbr+1LdnUF9f qC+gNH+5bLFYgl+IxWJxB/206TO0adNnvLZuuXEScOmUm32eHPSlQXpqX38p3TpLnduFqG// Rn0BtQUYpCek3+o3DXEO0nNX1qp+N0hP3J337uvtdehJ1Ld/o74Awq3fBT8AAArwGnMveAQ/ AAB9D8PyAgCAjhH8AAAoJMjg7+vjeas2fjn17ZlyQ0V9AfS+IIO/r4/nrdr45dQ3MOrbcbkX Un0BhFOwXf19fTxv1cYvp77Utz/VF0AYBX+Nv6+P563a+OXUl/r2p/oCCJsQbu7r6+N5qzZ+ OfWlvv2pvgDCJaS7+vv6eN6qjV9OfUWob/jLDVVvlQvAt9C+ztfXx/NWbfxy6hu++alv56Z3 Zj0BdKtQv8ff18fzVm38cuobGPX17UKtL4AwCPkne/v6eN6qjV9Ofalvf6ovgDCYNn2Ge5he f+P+eo3s29fH81Zt/HLqG45yw4/6+tJxfQGl+Mtli8US/EIsFos76KdNn6FNmz7jtXXLjZOA S6fc7PPkYOjQoT14KtI1qo3nTX37N+oLqK2hocHn9B07doQ0SI9pyHHj8V1Zq/rd6HyqjedN ffs36gsg3BikBwAAhRD8AAAohOAHAEAhBD8AAAoJMvj7+njeqo1fTn17ptxQUV8AvS/I4O/r 43mrNn459Q2M+nZc7oVUXwDhFGxXf18fz1u18cupL/XtT/UFEEbBX+Pv6+N5qzZ+OfWlvv2p vgDCJoSb+/r6eN6qjV9Ofalvf6ovgHAJ6a7+vj6et2rjl1NfEeob/nJD1VvlAvAttK/z9fXx vFUbv5z6hm9+6tu56Z1ZTwDdKtTv8ff18bxVG7+c+gZGfX27UOsLIAxCHqSnr4/nrdr45dSX +van+gIIg2nTZ7iH6fU37q/XyL59fTxv1cYvp77hKDf8qK8vHdcXUIq/XLZYLMEvxGKxuIN+ 2vQZ2rTpM15bt9w4Cbh0ys0+Tw6GDh3ag6ciXaPaeN7Ut3+jvoDaGhoafE7fsWNHampqkAsp Ly83DTluPL4ra1XIXf0XOtXG86a+/Rv1BRBuDNIDAIBCCH4AABRC8AMAoBCCHwAAhQQZ/H19 PG/Vxi+nvj1TbqioL4DeF2Tw9/XxvFUbv5z6BkZ9Oy73QqovgHAKtqu/r4/nrdr45dSX+van +gIIo+Cv8ff18bxVG7+c+lLf/lRfAGETws19fX08b9XGL6e+1Lc/1RdAuIR0V39fH89btfHL qa8I9Q1/uaHqrXIB+Bba1/n6+njeqo1fTn3DNz/17dz0zqwngG4V6vf4+/p43qqNX059A6O+ vl2o9QUQBiEP0tPXx/NWbfxy6kt9+1N9AYTBtOkz3MP0+hv312tk374+nrdq45dT33CUG37U 15eO6wsoxV8uWyyW4BdisVjcQT9t+gxt2vQZr61bbpwEXDrlZp8nB0OHDu3BU5GuUW08b+rb v1FfQG0NDQ0+p+/YsSM1NTXIhZSXl5uGHDce35W1KuSu/gudauN5U9/+jfoCCDcG6QEAQCEE PwAACiH4AQBQCMEPAIBCggz+vj6et2rjl1Pfnik3VNQXQO8LMvj7+njeqo1fTn0Do74dl3sh 1RdAOAXb1d/Xx/NWbfxy6kt9+1N9AYRR8Nf4+/p43qqNX059qW9/qi+AsAnh5r6+Pp63auOX U1/q25/qCyBcQrqrv6+P563a+OXUV4T6hr/cUPVWuQB8C+3rfH19PG/Vxi+nvuGbn/p2bnpn 1hNAtwr1e/x9fTxv1cYvp76BUV/ferO+ALpZyIP09PXxvFUbv5z6Ut++VV8A3W7a9BnuYXr9 jfvrNbJvXx/PW7Xxy6lvOMoNP+oLoEP+ctlisQS/EIvF4g76adNnaNOmz3ht3XLjJODSKTf7 PDkYOnRoD56KdI1q43lT3/5NtfoCaKuhocHn9B07dqSmpga5kPLyctOQ48bju7JWhdzVf6FT bTxv6tu/qVZfAN2PQXoAAFAIwQ8AgEIIfgAAFELwAwCgEIIfAACFhBD81T/zGu8roM6Mt122 RNO0mQXBrxI6pS9s55qCmTMLaoKfDgAITgjBn/jM67dN2bLnw47nFOnceNsZU83Br07YFMxc UtYLxYbNxvs2VYT2iu7dzuHZngm5jycvXd1+Qf6mAwCCE1pX/8iE8b4mWytuvXNN/HPVtd5P dGa87eTJrY9rCmZqmqZpS8qczVRNm1lQIwUzNU2bWVCwxHhWm7mkoEZcDdklS2ZqmrakrGzJ TE3TAodQTcFMTVtasW6u5hRcZJ1YPXtNxuy2cbu1YvV9azJmr8mY/dLqlz27RU5s/NVLGbPX ZMxek/2rl7Lvc7/oRIVresZ9Favve2ljnYiI1FW7lrMm+1cVh0RE5NDLL2XMXpP9q03Zzvld RddVZM9es75m93/Mdr5k9dZg1l9E2m5nEZGaMtfm1GYWLHE3qz0nL3FNM3bAktbt79xsAban r+WIa6/OLKgpK/DeXxmP5O98ykfj3t90AEAwuu0af6fG256cLOapHr9RlpC7rTrfLGYRkcSp ZjFnlW7LTZDcbXq+ueLVXVOLq3Vd1/Vtj8iiJWWSsbY631yxc2qxXp0vc+fK49V6afLOtwJk eULuNl3PN2eVun7XcG1GZ+s7a9I9Tz5ctuXhsi33ztr/tjuAD738zkcTZ63b8nDZlodXpI5x D2BW8at3tqbeWrbl4bItD5c9OVpcObaxeM89fzCW83DRotGv/KpCRK740b3rlozaXysL//hw 2ZaHn4g7tuHlEyIiseaiLQ8vTpjyxBbnSx6ZFdTKem9nkbIli96aX+zcCsWTxXV+UrD6rUe2 OSdve2Ty6iUF4totFTvl8Wpd1/XSZFcQ+9+ePpcjIhlrdb00q2Lpoqd2zS+u1vXi+YnuSE+Y nFzx6qb2Ce9vOgAgCKH9ct+o+PHHsu586edthv0QMZnfeb1d53HKvH3GsCIh/PRYxlrdO3kT crdVT56ZqGlizq/elpvgfsK84JHcBOe/CfMW7FxdJhmJIuYFuQkik0Wy5mckSM3U4CsXvFGP bHn4Ea9pdXtfefJ//lojIjIxQSamOidf8aNZE+97O2utMX3KE08a26l6a+2UR37hGq8kNvGR LYkiInUVH/1l9/q/7PZY7pRZvzBOfGTOffPMsSIi5tQxGw52qQLttnPZWzsXrF3r2rgJrudr Cl5dt27punUec2bNXyvGa7MeX5uRICKSMT/5qT0Bywu4HBEx5xe7dm1G6x6WjKnmubuqRTwm BZwOAOhYaMF/Yt/BMeten9du6K1uVVP9VoWYzWbZVV0jCRfmh3316n/aHfv0vWWzRonIoZdf eqX1qcRH/vDwIyJSd+LQxxVZT1aU/cF5jnRI5AqvxcSOnpjwvaI/9MadDiI17ZM0YXKyOX/b ttyuLjpcywEAdFk4uvoDjRfeVTUFMxOfktLqbdu2PS5PJXrc0F3x6uqCGud/NZteTZ7f6V56 2bmnxihryUxtSRBdyO2u8dcd358wZmbsKBE5tLXilQ9PuJ/ZeN9Lq7ca3fKjZLxMjBstIiKJ s+L+Z+XLztkO1VWvvs+4PJ84K2539svBfnPC5VhdnYjIoZc3Zc/edCjEF4uISMb85KWLXNu2 pqZsyUzj8nzG/ORXZxaEeitd++3ZueWU7arwuiIReDoAoGOhtfhP1hyUeO+J1e9vEZl97zO+ xwvvipqCmYlLK0Qq3qpem1H91roKkYrEmWL0+JsXzJ+8epG2rkLEnFVavDZDypYkLq0Q0ZZM 1ueLrJs7c2p1sci6uZqUBrp4P+/x5EWJ2lIRMWeVVq8NokvhpPeEWPOK77+U9U9rRGTiTd9b +P1R//HoS7F/vPfuWBEZI+XvZDx6QkQkYcoTTzrzyvyLe+t+9U7GbGP6qMX33Xv3LGP6rfKr dzJmv21Mnxg3a8UvEuXll7LWnhBZI08//Ihsynh0t8jubLm36EejRGTmfWNW/tOa9cby/zjP uxchOBlrq/csWaRpFSIiZnP+49W5Gcb0YlmySNPmGtPNyY8Xr80Q537RpFRfK0u0uetE1rn2 i+/t6XM5CVJmvFhknbZURCTLc0/V7NlpXvBI+/3hbzoAIAghDMtb/bM73949+7Z3vEYItW6K f3bU5mfNwd2+Fy4FM2dKseclf/Q3ZUu0t+b7OGPzNx0A+p9eHpY38ZnXH/Yx2TRv37PBLyQs CmZqSytEErWl5nydK8f9Uk3BUzvzi9cGPR0AEJzQuvovELnbdNK+n0vI3bYtlOkAgODwW/0A ACiE4AcAQCEEPwAACiH4AQBQCMEPAIBCCH63ro1S7xw8UPM5WHzZEt/Tw6V15LsOhiPsfjUF M31W1d90AEDPIvjdMtbqpVldebWuV+f7/pn9jLV6N/7YUE3BUzuTq11D3/XYL9sU+DzHSMh9 PHnp6vZP+JsOAOhZ/Sn4jSa7MUr8krIyr/Hdawrcw8d7/mp86zjxbXPMz/jxnVspr54Av+PZ h15u2RJNS1xaUbEu0VVMayG+6muszsyCmrIC9/YJuN3KWhezpKB1W87UtKUV6+a6+hk8N13G I/muYXrb8DcdANCT+lPwZ6ytzjdX7JxarFfny9y58ni1Xpq8860yEZGCmYvENSD8tuLJbzlz 2HMY+uL5bz3lHjjW3/jxnVip9j0BfsezD73cjLW6Xp1vNue7XuP8ZSM/9ZWMtbpemlWxdNFT u+YXV+t68fzEmkDbTTLmPeLcPtvm75rrDPiE3G26nm/OKnWW2vYHdBMmJ1e8uql9wvubDgDo Qf0p+EVExLwgN0ESJotkzc9IkMSpIiJSU/Bq8uOtfe0JGfOTX91UYwxD/4hrBPiEjEcWOPO5 puDVda42tKZpiXPXrdtVJtLafm/V+UvqnuPZS3jL9Vdf90bKL962NiMhQSQhwznQsc/tJiI1 m1Yvchb51M4ga5Yx1Vyxy8cQg/6mAwB6Tr8L/rBImJzsbkO3adNmrNV1X9P7eLl+lS1JfHXq 4877B4oX+L6DAQDQh6gR/Am5CzwvL9eUvbVzwbwEY5j41WWuYejLVr9a4Zyjc+PHd12YyvVX 31DV7NlpTp6XmCAiNWUFrZvHaeeeGhHn3QRLPDoUynZVmKe2HcMx4HQAQA+aNn1G9Sclxt8Z P7xbmxco1z35WaXGQ3N+tXFxPatU1/Xq/Cxng9VszndfnNarS92Ts0qdL/N6Qsxmc1ZptZ9S 2xTdyrj+7Xu6+5J/VmnrLOb86tDL1b2/RtB62d1nfb3XJ6u0g+3mXlVzVn5pvrl1Nb22nOda VuebW+cKYjoAwA9/uWyxWIJfiMVicQf9tOkztGnTZ7y2brnxAX7plJt9nhwMHTrU53SgvbIl 2lvzfVyK8DcdAOBPQ0ODz+k7duxITU0NciHl5eWmIceNx3dlrVKjqx89pqbgqZ35j7RPd3/T AQA9K6q3VwD9S0Lutm2hTAcA9Cxa/AAAKCSoFr+maT6n67oe1pUBAADdixY/AAAKIfgBAFAI wQ8AgEIIfgAAFELwAwCgEIIfAACFEPwAACiE4AcAQCEEPwAACiH4AQBQCMEPAIBCCH4AABRC 8AMAoBCCHwAAhRD8AAAoJCqYmXRd7+71AAAAPYAWPwAACiH4AQBQCMEPAIBCCH4AABRC8AMA oBCCHwAAhRD8AAAohOAHAEAhBD8AAAoh+AEAUAjBDwCAQgh+AAAUQvADAKAQgh8AAIUQ/AAA KITgBwBAIQQ/AAAKIfgBAFAIwQ8AgEIIfgAAFELwAwCgEIIfAACFEPwAACiE4AcAQCEEPwAA CiH4AQBQCMEPAIBCCH4AABRC8AMAoBCCHwAAhRD8AAAohOAHAEAhBD8AAAoh+AEAUAjBDwCA Qgh+AAAUQvADAKAQgh8AAIUQ/AAAKITgBwBAIQQ/AAAKIfgBAFAIwQ8AgEIIfgAAFELwAwCg EIIfAACFEPwAACiE4AcAQCEEPwAACiH4AQBQCMEPAIBCCH4AABRC8AMAoBCCHwAAhRD8AAAo hOAHAEAhBD8AAAoh+AEAUAjBDwCAQgh+AAAUQvADAKAQgh8AAIUQ/AAAKITgBwBAIQQ/AAAK IfgBAFAIwQ8AgEIIfgAAFELwAwCgEIIfAACFEPwAACiE4AcAQCEEPwAACiH4AQBQCMEPAIBC CH4AABRC8AMAoBCCHwAAhRD8AAAohOAHAEAhBD8AAAoh+AEAUAjBDwCAQgh+AAAUQvADAKAQ gh8AAIUQ/AAAKITgBwBAIQQ/AAAKIfgBAFAIwQ8AgEIIfgAAFELwAwCgEIIfAACFEPwAACiE 4AcAQCEEPwAACiH4AQBQCMEPAIBCCH4AABRC8AMAoBCCHwAAhRD8AAAohOAHAEAhBD8AAAoh +AEAUAjBDwCAQgh+AAAUQvADAKAQgh8AAIUQ/AAAKITgBwBAIQQ/AAAKIfgBAFAIwQ8AgEII fgAAFELwAwCgEIIfAACFEPwAACiE4AcAQCEEPwAACiH4AQBQCMEPAIBCCH4AABRC8AMAoBCC HwAAhRD8AAAohOAHAEAhBD8AAAoh+AEAUAjBDwCAQgh+AAAUQvADAKAQgh8AAIUQ/AAAKITg BwBAIQQ/AAAKIfgBAFAIwQ8AgEIIfgAAFELwAwCgEIIfAACFEPwAACiE4AcAQCEEPwAACiH4 AQBQCMEPAIBCCH4AABRC8AMAoBCCHwAAhRD8AAAohOAHAEAhBD8AAAoh+AEAUAjBDwCAQgh+ AAAUQvADAKAQgh8AAIUQ/AAAKITgBwBAIQQ/AAAKIfgBAFAIwQ8AgEIIfgAAFELwAwCgEIIf AACFEPwAACiE4AcAQCEEPwAACiH4AQBQCMEPAIBCCH4AABRC8AMAoBCCHwAAhRD8AAAohOAH AEAhBD8AAAoh+AEAUAjBDwCAQgh+AAAUQvADAKAQgh8AAIUQ/AAAKITgBwBAIQQ/AAAKIfgB AFAIwQ8AgEIIfgAAFELwAwCgEIIfAACFEPwAACiE4AcAQCEEPwAACiH4AQBQCMEPAIBCCH4A ABRC8AMAoBCCHwAAhRD8AAAohOAHAEAhBD8AAAoh+AEAUAjBDwCAQgh+AAAUQvADAKAQgh8A AIUQ/AAAKITgBwBAIQQ/AAAKIfgBAFAIwQ8AgEIIfgAAFELwAwCgEIIfAACFEPwAACiE4AcA QCEEPwAACiH4AQBQCMEPAIBCCH4AABRC8AMAoBCCHwAAhRD8AAAohOAHAEAhBD8AAAoh+AEA UAjBDwCAQgh+AAAUQvADAKAQgh8AAIUQ/AAAKITgBwBAIQQ/AAAKIfgBAFAIwQ8AgEIIfgAA FELwAwCgEIIfAACFEPwAACgkqrdXAAAAhMZqtf7xj38Mfn7T5IHuxwQ/AAB9z8yZM4Occ9u2 bZ7/0tUPAIBCCH4AABRC8AMAoBCCHwAAhRD8AAAohOAHAEAhBD8AAAoh+AEAUAjBDwCAQgh+ AAAUQvADAKAQgh8AAIUQ/AAAKITgBwBAIQQ/AAAKIfgBAFAIwQ8AgEIIfgAAFELwAwCgEIIf AACFEPwAACiE4AcAQCEEPwAACiH4AQBQCMEPAIBCCH4AABRC8AMAoBCCHwAAhRD8AAAohOAH AEAhBD8AAAoh+AEAUAjBDwCAQgh+AAAUQvADAKAQgh8AAIUQ/AAAKITgBwBAIQQ/AAAKIfgB AFAIwQ8AgEIIfgAAFELwAwCgEIIfAACFEPwAACiE4AcAQCEEPwAACiH4AQBQCMEPAIBCCH4A ABRC8AMAoBCCHwAAhRD8AAAohOAHAEAhBD8AAAoh+AEAUAjBDwCAQgh+AAAUQvADAKAQgh8A AIUQ/AAAKITgBwBAIQQ/AAAKIfgBAFAIwQ8AgEIIfgAAFELwAwCgEIIfAACFEPwAACiE4AcA QCEEPwAACiH4AQBQCMEPAIBCCH4AABQS1dsrAAAAOu/5559vP/GBBx7wNz8tfgAAFEKLHwCA PixA494ngh8AgD6Mrn4AAOAXLX4AAPowuvoBAFAIXf0AAMAvWvwAAPRhoXb10+IHAEAhBD8A AAoh+AEAUAjBDwCAQgh+AAAUQvADAKAQgh8AAIUQ/AAAKITgBwBAIQQ/AAAKIfgBAFAIwQ8A gEIIfgAAFELwAwCgEIIfAACFEPwAACiE4AcAQCEEPwAACiH4AQBQCMEPAIBCCH4AABRC8AMA oBCCHwAAhRD8AAAohOAHAEAhBD8AAAoh+AEAUAjBDwCAQgh+AAAUQvADAKAQgh8AAIUQ/AAA KITgBwBAIQQ/AAAKIfgBAFAIwQ8AgEIIfgAAFELwAwCgEIIfAACFEPwAACiE4AcAQCEEPwAA CiH4AQBQCMEPAIBCCH4AABRC8AMAoBCCHwAAhUR5/jPp86Huxzviv3I/bmho6Lk1AgAA3SbK 6/+jR50P9tr39vS6AACAbkZXPwAACiH4AQBQCMEPAIBCCH4AABRC8AMAoBCCHwAAhRD8AAAo hOAHAEAhBD8AAAoh+AEAUAjBDwCAQgh+AAAUQvADAKAQgh8AAIUQ/AAAKITgBwBAIQQ/AAAK IfgBAFAIwQ8AgEIIfgAAFELwAwCgEIIfAACFEPwAACgkjMFvLcnJKbGGb3kAACDcOhP8Vmtl ZUleTk5a25w3mVOlvMJv8ltLcvIqQ5geLtaSnLRuLaBLhVpLctLS0tICzNwr6x+Cyrw0Tzl5 leE9+fNcvveJZWVejqtUH6eclXkBN2y3aj0JDrT+zue76XzZa89c0O8i/7pp+7gOPM+3bklr ke13l9cLuvI+p4mE3hbVideYTCmmzJSUWMmpazs9c0Vc2sbKzGUpbee3VpZUiNksImK1VlZU iDkzxRRgej9wuK4quBlNmYWW2Ly05d27Ot0pZdmG7NqNsYXGXrdW5i1cWWIpzAz8opKcPNcr Ol6+xbKsMi+n7u7CzLbvjpKcYlm0wZJiEqu1ZOXKtku0luQUx67KTtoaan3CoTKvKG6RxVhb /+svrueD2g6hS1lmsSwTa0nOSlnhu+x2QtgvYRWg3G7aPqbMwg3isWWsJTkrPYq0LPOc4HzB qrq0rbMszjd6Sc7KPOnctjJlLvL5QQmEaNu2bZ17YWeC3z/T3dm1K0usKW0/ZUwpmWZr5cbi qk1SMWtFpvtJf9PDpTIvbXlt0jypEinOy1m+SbI3GEe5tSRvZdEmdzTPpq1p9gAACORJREFU W+U8mL2fSMreUJhpqsxLW75JROatWiXFyzdVSdK87BXLMk1iLclZWVRlzO2a5ix2k4jI8rRN wSzfeFxXkrO8qKrdgnyu/4UtKS7W9bC1vklJ2YsKM1NExFqSs7CoSkScW8dj84Qos7DQ+chk MqeK51loZd7KukWFy8aVlHdmwV1VUrxp3qJlHc/neqckee9Yj+02L0lqUwsLM0ty0oqqkrKz 48pdT7jfJyExNn/SvHmyybmcVUZ6Bdgv1sq8lcuNt61nscbqJ2VvWCQbi4s2VbkXVVmSV+xe y0XLMt1713NB2fOkPHZFYab4LzeY7eN6X/mtV8cq83LqlhW2vpuCYspckZrj+qzz9T73V1+T iEjK3dnF7T8ogVCYTKG+fY67H4U3+P2fy1YUb5LsbCmvk8yUYKaHQ8rdq7I3FhdtEpGq2nnZ q+525enCotrsDZZCk/PIrK2zSorJ+OgQ5xPGh07dYRFTyjKLZVZe2vJNy5fLvFWWwnElOQs3 VmYuSzFlFrpattaSnIUrS8yFmSajvTArL225eAWav+WLiMimctlgsZjaLsj3+l+INrlOckSS sjc4M89oalqM/6yVeTkl4wozTabMQktmmFuW1pKV5akrCt3/5RTLosIUkd7pTq2sq5o3K5i6 +WxZGrWJNboyxFqZt7BWRCSz0CI5aeV1qSs2WEzG2WtOXmXo29Bo6S4sl1UbLCkmqczLKTYC yP9+Kdm49W7XbhRrZV5eybJlmdL6Rl9ZPG/Rig3LTFJptYqYRFLMd4/LXOY6ec2rdB4HlXkr t85aYTGesFbmLXStkL/3g5/t4/t95a9eAVUVLUwrEknKDuI0zZspNq5q62ERk+/18Vff1hcX V1jD39qBUlJTU4Ocs7y83PPfMAe/v3PZw5K6qjAzxRqbV1HpGfG+prtbzG6dbROaUsyxxUWS lCRVVRLruowwLjZJNhUtTCuSpKSkuNRFG5YZFx4qyquSsje41jtl1jypjR3nazUyCy0iImKt LFlZ7GryiySlBlyZwMuft8h4whQbJ1Wu8wHf638hats6zClZUZgpJeVxiwrd62xKmRXXPZ90 1hKjee9e8OG6qiqPM5Gc2J7tKLHW1Yrc3YUFmDIXxeUsX1gkIpKUNG/VCvd1k6TUuzNdZ/km c2rtxkpJ6dTZ07xFxpteUmbFFdcFnNVaUr5pU9EmzyNy3qxl4i42Kdt9HcH1DrVWbHR1bCUl SdwsY2rl1trUZe69ZOpsF7410PsqhHo5V35DYebhvJwgZg15fQLXNyU2aXnreT/Qs8Ie/M5G vzVzmedbOiUzU0TElLKs7cVfX9ONS5NhYa0or5q3yrJM8tKWb61cZnxImjILLebKyoq6rXV1 tZuKlm8q99mF3u6DyasVZy1ZubwobtWGwhST0ZovD23dgvng87n+FzZTyt2pxRsPi4zreN7O sZbktN5SUJK3sm6W1xXs1jeQMesF1qryXH8/UpYZDUir1VqxMZh7JrqRKTYuKbswhBWozFtY Hmu0u43KejxnvRCTLmVZYWcOLGtdbVLs3SKBThouyPoC3fI9/hTjSn83LDlUpsxCy7IUZxQ4 D25rSU5aTsW4lMzMZcuWFW7Inme0sMVkTk2qKtrovlfXWpIT8N7bw3VVMi92nEnEai3ZWN72 Zr5xsUkidVYRsVY6lxPq8v2t/wXOWrmxqEpExJSZWlvcWj9r5dbaVHPrp2BtnVVExFqSl5OW 16n3irUkL2ej3F24zHnmdaHctG6KjRM53IUFlOS4bhk3mSTW856JqvKNJVbnxrJWlMcFdUEh NO33S8qsuPKckqA3rrWuNinOPM55967HgZEyK67I/bFgtVbmtfm2StDvhw7eV50X2jvIWrmx PG5Rpsn/+gSub2VdVVJst50cA4Fp06bPeG2d86by68/fdfSo8wnLmHJ/r/Hui0/KbtciqcxL 23q3ZdmFeLbrvonJ0OYmqTY337U+41Fhz/uMKvNylm+qEklKyk513nPleWOS8aQkJc1LdZXg Y/nue5uSsjcUxm50FtTudqYLV7srMx7r7u+mJ4+7npLmrVqxLNBVjPZXfozNPK7tfmx3Qcj9 up7fliU5aXWLvO9Q8zRvlWVZit9LWiU5eXVxtZtcd9O5t09JTo4sWlRXbLzpOtpu7Uuet8qy LMX99nf1JLW5e87PfvG8SS0pKW7RimUpJt+LF/E4wpLmZS+KLV9e5Ouu2qSk7EUrMtsX0Fpu gEt+fm/u81ev9qzebx/38v2U2+5zw3P7+Lu5z199Q/uuBeCH+xr/0qVL8/PzPZ/ymlJeXm4a 4ry5766sVZ0J/mDwxoa6KvNav/cVPiU5ORxS/UP3vEGgHM/gFxF30nv9K+2Cv7t+steUWchH FBSVsizbs/s3HEpy0oqqqooWevzODPooa0lxbfbdpD7Cx8h4I+/bp3573dXiBwAA3cfr63xG 5Iuv1O+hFj8AAOgxRt4HbusbCH4AAPqDYFJfCH4AAJRC8AMAoBCCHwAAhRD8AAAoJPy/1Q8A ALqb15h7waPFDwBAf/bnP//Z81+CHwAAhRD8AAAohOAHAEAhBD8AAAoh+AEAUAjBDwCAQgh+ AAAUQvADAKAQgh8AAIUQ/AAAKITgBwBAIQQ/AAAKIfgBAFAIwQ8AgEKiPP85OVuLcT3+80MP 9fzaAACAbtUm+I+fOeNzpqFDh/bIygAAgFYNDQ0+p+/YsSPEJR13P4oKMBcAALgwpaamBjln eXm5579c4wcAQCEEPwAACiH4AQBQCMEPAEB/sHTp0mBmI/gBAOjzjNQPJvu5qx8AgL7H8179 t99+W0Ruu+22t99+e+nSpbfddluAFxL8AAD0be6kDxz5BoIfAIC+h+/xAwCAjhH8AAAohOAH AKAPa38nf+B7+wl+AAD6Ns+k7/AbfQQ/AAB9WH5+vrT9Hr8xxR/u6gcAoO/xvFff/Q1+47HX bfxe2gT/17vf9znT111fQQAAECamId5Tcn74PdfD44FfS1c/AAAKIfgBAFCINm36jN5eBwAA 0EP+P66ixCUhh+bLAAAAAElFTkSuQmCC --------------EEAD7462F06F3F75B4F2F9A7-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 03:36:05 2019 Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 08:36:06 +0000 Received: from localhost ([127.0.0.1]:37692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVtYr-0000Fo-Ke for submit@debbugs.gnu.org; Sat, 16 Nov 2019 03:36:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVtYn-0000FI-HU for 38181@debbugs.gnu.org; Sat, 16 Nov 2019 03:36:04 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46673) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iVtYh-000455-FZ; Sat, 16 Nov 2019 03:35:55 -0500 Received: from [176.228.60.248] (port=1402 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iVtYg-0000fL-MR; Sat, 16 Nov 2019 03:35:55 -0500 Date: Sat, 16 Nov 2019 10:35:50 +0200 Message-Id: <83pnhs6wwp.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-reply-to: (message from martin rudalics on Sat, 16 Nov 2019 09:20:27 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 38181@debbugs.gnu.org > From: martin rudalics > Date: Sat, 16 Nov 2019 09:20:27 +0100 > > > I think fit-window-to-buffer relies on window's metrics (like the > > number of lines in the text area) to be up to date, and that is only > > true after a window was redisplayed once since changing the mode-line > > height. Martin, is this correct? > > Yes. Then I'm not sure we can fix such use cases at all, without causing display flickering in much more popular use cases. Do you have any ideas for a possible fix? Could fit-window-to-buffer invoke 'redisplay' internally, perhaps? > But, as I mentioned earlier, the problem shows up with the > scroll bar immediately when Jonas' form is evaluated, see the attached > screenshot. That just means we (or a Lisp program which makes these mode-line modifications) need to recreate and redisplay the scroll bars anew in these cases, right? It's a separate problem, right? From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 03:38:27 2019 Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 08:38:27 +0000 Received: from localhost ([127.0.0.1]:37696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVtb9-0000JK-2a for submit@debbugs.gnu.org; Sat, 16 Nov 2019 03:38:27 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47390) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVtb6-0000J5-3l for 38181@debbugs.gnu.org; Sat, 16 Nov 2019 03:38:25 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iVtb0-0005Wu-Vi; Sat, 16 Nov 2019 03:38:19 -0500 Received: from [176.228.60.248] (port=1550 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iVtb0-0000ne-7f; Sat, 16 Nov 2019 03:38:18 -0500 Date: Sat, 16 Nov 2019 10:38:16 +0200 Message-Id: <83o8xc6wsn.fsf@gnu.org> From: Eli Zaretskii To: Jonas Bernoulli In-reply-to: <87eey8og08.fsf@bernoul.li> (message from Jonas Bernoulli on Sat, 16 Nov 2019 00:51:19 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <87a78xnrp0.fsf@bernoul.li> <835zjl2mzs.fsf@gnu.org> <87eey8og08.fsf@bernoul.li> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Jonas Bernoulli > Cc: 38181@debbugs.gnu.org > Date: Sat, 16 Nov 2019 00:51:19 +0100 > > > An alternative would be to scale the image so that it doesn't enlarge > > the mode line, btw. Is that possible in your use cases? > > No because enlarging the mode-line is one of the things I did in order > to make it prettier (imo). It's a goal not a means or side-effect. If this is to make the mode line prettier, then it should be done once, at the beginning of a session, right? In that case, why calling redisplay after loading the package or enabling a feature is not a solution? From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 03:57:56 2019 Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 08:57:56 +0000 Received: from localhost ([127.0.0.1]:37721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVttz-0000mn-Qw for submit@debbugs.gnu.org; Sat, 16 Nov 2019 03:57:56 -0500 Received: from mout.gmx.net ([212.227.15.19]:57461) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVttx-0000mY-1Z for 38181@debbugs.gnu.org; Sat, 16 Nov 2019 03:57:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573894663; bh=ZDyP8/kJGGcgr/GIyULQ1l2OEN9h5Ui9CZl4p3DPvDI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=KBxOnJYBLPDryoGwHBdPced2hCRQP2BOrlzbrHmgTNMNnn+F+tAca2cecniB+3pKq X5SZWhzD4SmDaP0PYs8w1JJ3zCEHSXs1BPvnjQvdN9xwEx9GCxet4hBAR4K24X6HUV UbysBLRvVSCDx0MIOv/c5p8xHVn9Z2JMExVlGfXw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.104] ([46.125.249.58]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1McpJg-1hw0ur01AI-00Zxlm; Sat, 16 Nov 2019 09:57:43 +0100 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> From: martin rudalics Message-ID: Date: Sat, 16 Nov 2019 09:57:40 +0100 MIME-Version: 1.0 In-Reply-To: <83pnhs6wwp.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:nt9tB0kuFblBiPLFis/euTam/CUoxZ034W7NdHqqLlNZF0SDXJQ +IIPIEMEhWA5cb1VOoQmqYUgmOG2qPTlxy2IbUmSXFHgGeYkbhExkWMJLzenOdKNAGLrAtO tPmivQHsQCxwBIfgQlB/dtNsA5YLC4VnC40Dq2L56ces3bHayqAcjNgJfIydQjW9qmN0DWc AR8beOZzc0ls3fQsuVSTQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Fa02vbCNyRk=:gO14rdj9vnoNYal2DbSIrI GvOiiwQVU0R2ZOwat8xwhRRR0Ua+n2PoZIxZDA9DqV9D3FkgFeq5n0jS/3Jnl1ifD1dQX98e0 tVZhzvorzLqdt+3m2bZR60Su0mFIPwt2SE63vaAjt8JqIJg4EeV1HhHLdJPPysXXYZ3tstNUU Iu53J3Vc+etaU3/zjy4aOAi9BjTuxJA04heQW3Oi/eIzAHgr5L0qnQCW7CmblQl67MALAn3/y /dI3AvCuObaKwP/ByXv2Gi9YQ/zlFLKls1hdGFeKxDDlwaBqT4ToiLzTZoo32WEJaLmH/vd4E kFBTM6gDTBpn1gkAFkX0gnZh4UtCU6Wue4W4DtlF/nBokAx6UV+1nBZQFTtSr9Hvj00MfI1U3 wcVs0kAFt7+UzNCusGHhIrKlV+MGDtgmPWB+OLA8mk2eyj/qx+A4VZ/pNrKlFb7W4iTBKijpe wpeBsce5OMXeJ51SCPG/aWcdX457WMbPsQSrp2bkFfCuZrbwC4EXTDbaqY5Ee/w4+lsutGWI5 ZTKbMcPnzzNzZbFkVF5oSerqy34iGlA8AdIK4UiXvneqggnekjHPSL2S3nVO2yeQWmxBoofry jgpY8w+qjPopHfMmg2CFlQc1n40/JMxG5TLWRogsPy6ghJCKucunfwxJt/cp33rEVlPm7sizx /nVy8Rt80tTVXSb2yJeCi1pd86G4rW1PjpuFk0CW97gfhgqwvy0a9pAkuELU0z6oEBQtcqYgs RNRx2RqIJwStEiT+X7Hs4WVqweuvfRTvZswDmQ2kIFLVfYUZ8OJB/ZqAOxnUOM71/Mm+0uKRU 8/NmFabAETfGGo9L7ch73e+rRHB70wLEZcTIFsk2XhRlw83bBssYjUGOl/u75TydTpGiM23pW EfDr0R76hw3mHuyTP9KSgoK/D7lgKsoMUrYEbshzk2R6dXT7qCqiRZG3k/+ojQHTUE2BaHH17 M7RX18XEaI9FQBsZJ3rAup5CAOjA5osqZXTHHjGB34AOjO0goMMWz5dACjH1uqVe8vOk1oVxl d7FKpzqC4C2s+Q4z42ikTZjRVntS3jmu+p5iLXq1kbZoGko4Vc8EDpC+TU9OXqL5mv8gmF/x/ pMTvl2b1UuTs1AqGBHJkftxCmyjwfOKTiR7psnQH6P6+MURkSv2Y01ITFq9bIoOtQkM/958Y6 Fws/lkNUYdyKvd5HU6Y/GiU/Xwyi7zH/DU1DZ10aTOl7IlMSlosxxMnkRSLq9nDwuT3gmAWkv TqL9cV6Ih9WOIl6Uje6H5dMqBoD+Yo5e/7Ge2Mw== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> > I think fit-window-to-buffer relies on window's metrics (like the >> > number of lines in the text area) to be up to date, and that is only >> > true after a window was redisplayed once since changing the mode-line >> > height. Martin, is this correct? >> >> Yes. > > Then I'm not sure we can fix such use cases at all, without causing > display flickering in much more popular use cases. Do you have any > ideas for a possible fix? Could fit-window-to-buffer invoke > 'redisplay' internally, perhaps? It could but it's called way too often to warrant such behavior by default. But we could give it a separate optional argument so users can avoid the advice. I think Jonas could easily write and a test a patch along this idea. >> But, as I mentioned earlier, the problem shows up with the >> scroll bar immediately when Jonas' form is evaluated, see the attached >> screenshot. > > That just means we (or a Lisp program which makes these mode-line > modifications) need to recreate and redisplay the scroll bars anew in > these cases, right? Right. But that same program could also redisplay all windows in these cases, right? > It's a separate problem, right? For some value of right ... martin From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 05:57:51 2019 Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 10:57:51 +0000 Received: from localhost ([127.0.0.1]:37787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVvm3-0003eU-Hs for submit@debbugs.gnu.org; Sat, 16 Nov 2019 05:57:51 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVvm1-0003eI-Nt for 38181@debbugs.gnu.org; Sat, 16 Nov 2019 05:57:50 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iVvlw-000101-17; Sat, 16 Nov 2019 05:57:44 -0500 Received: from [176.228.60.248] (port=2093 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iVvlu-00023n-UK; Sat, 16 Nov 2019 05:57:43 -0500 Date: Sat, 16 Nov 2019 12:57:41 +0200 Message-Id: <83k1806qca.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-reply-to: (message from martin rudalics on Sat, 16 Nov 2019 09:57:40 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Sat, 16 Nov 2019 09:57:40 +0100 > > > Then I'm not sure we can fix such use cases at all, without causing > > display flickering in much more popular use cases. Do you have any > > ideas for a possible fix? Could fit-window-to-buffer invoke > > 'redisplay' internally, perhaps? > > It could but it's called way too often to warrant such behavior by > default. What are the frequent calls? Help and completions windows come to mind, but those are interactive, and so I'm not sure I see why calling redisplay would be a bad idea there. Are there other callers which I'm missing? > But we could give it a separate optional argument so users can avoid > the advice. That's possible, of course. > >> But, as I mentioned earlier, the problem shows up with the > >> scroll bar immediately when Jonas' form is evaluated, see the attached > >> screenshot. > > > > That just means we (or a Lisp program which makes these mode-line > > modifications) need to recreate and redisplay the scroll bars anew in > > these cases, right? > > Right. But that same program could also redisplay all windows in > these cases, right? I meant that calling redisplay should do this automatically. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 09:54:58 2019 Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 14:54:58 +0000 Received: from localhost ([127.0.0.1]:37864 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVzTW-0004nz-Ka for submit@debbugs.gnu.org; Sat, 16 Nov 2019 09:54:58 -0500 Received: from mail.hostpark.net ([212.243.197.30]:35616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVzTU-0004np-7o for 38181@debbugs.gnu.org; Sat, 16 Nov 2019 09:54:56 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id B0CAB16618; Sat, 16 Nov 2019 15:54:54 +0100 (CET) X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail0.hostpark.net [127.0.0.1]) (amavisd-new, port 10124) with ESMTP id 5d3HH2CszVCI; Sat, 16 Nov 2019 15:54:54 +0100 (CET) Received: from customer (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 24C69165F1; Sat, 16 Nov 2019 15:54:54 +0100 (CET) References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <87a78xnrp0.fsf@bernoul.li> <835zjl2mzs.fsf@gnu.org> <87eey8og08.fsf@bernoul.li> <83o8xc6wsn.fsf@gnu.org> User-agent: mu4e 1.1.0; emacs 27.0.50 From: Jonas Bernoulli To: Eli Zaretskii Subject: Re: bug#38181: Actual height of mode-line not taken into account In-reply-to: <83o8xc6wsn.fsf@gnu.org> Date: Sat, 16 Nov 2019 15:54:53 +0100 Message-ID: <87bltbooqq.fsf@bernoul.li> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> From: Jonas Bernoulli >> Cc: 38181@debbugs.gnu.org >> Date: Sat, 16 Nov 2019 00:51:19 +0100 >> >> > An alternative would be to scale the image so that it doesn't enlarge >> > the mode line, btw. Is that possible in your use cases? >> >> No because enlarging the mode-line is one of the things I did in order >> to make it prettier (imo). It's a goal not a means or side-effect. > > If this is to make the mode line prettier, then it should be done > once, at the beginning of a session, right? In that case, why calling > redisplay after loading the package or enabling a feature is not a > solution? No that won't work. Each buffer has its own mode-line so when a new buffer is created, then its height has to be calculated. In practice all mode-lines have the same height, so if Emacs could use the height "that all the other buffers/windows are using" when it does not know the actual height, then that would help. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 10:27:20 2019 Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 15:27:20 +0000 Received: from localhost ([127.0.0.1]:39582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVzyn-0005xz-Dd for submit@debbugs.gnu.org; Sat, 16 Nov 2019 10:27:17 -0500 Received: from mail.hostpark.net ([212.243.197.30]:60168) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iVzyk-0005xo-Qo for 38181@debbugs.gnu.org; Sat, 16 Nov 2019 10:27:15 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 5BE9916640; Sat, 16 Nov 2019 16:27:13 +0100 (CET) X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10124) with ESMTP id aT2etsM1HJr3; Sat, 16 Nov 2019 16:27:12 +0100 (CET) Received: from customer (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id D0F40165CB; Sat, 16 Nov 2019 16:27:12 +0100 (CET) References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> User-agent: mu4e 1.1.0; emacs 27.0.50 From: Jonas Bernoulli To: martin rudalics Subject: Re: bug#38181: Actual height of mode-line not taken into account In-reply-to: Date: Sat, 16 Nov 2019 16:27:12 +0100 Message-ID: <878sofon8v.fsf@bernoul.li> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: Eli Zaretskii , 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> Could fit-window-to-buffer invoke >> 'redisplay' internally, perhaps? > > It could but it's called way too often to warrant such behavior by > default. But we could give it a separate optional argument so users > can avoid the advice. I think Jonas could easily write and a test a > patch along this idea. Again, the mode-line-prettifiers are not the ones who create new buffers and then call fit-buffer-to-window. It's arbitrary other packages that do that. An optional argument therefore would not help because when one of the prettifier modes is active, then each and every third-party caller of fit-buffer-to-window would have to pass that optional argument. This is the advice I currently use: (defvar-local moody--size-hacked-p nil) (defun moody-redisplay (&optional _force &rest _ignored) (unless moody--size-hacked-p (setq moody--size-hacked-p t) (redisplay t))) (advice-add 'fit-window-to-buffer :before #'moody-redisplay) Of course fit-buffer-to-window itself could be changed to do that and it could also be taught to only do so iff the user opted in to doing it. ---- Creating and displaying a new buffer and creating and resizing a new window surely *already* causes a "redisplay" without the programmer having to explicitly call `redisplay'. So if we explicitly tell fit-window-to-buffer to redisplay, then that means that we are redisplaying twice, right? I am under the impression (but this is just wild speculation) that redisplay only performs some of the necessary size calculations before doing the actual redisplaying. But some other calculations (including those concerning the mode-lien) are done only after the actual redisplaying has already happened. That is too late for this redisplay round but causes the values to be in place for all subsequent redisplays. So the fix could be to do the mode-line based calculations earlier? From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 10:59:31 2019 Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 15:59:31 +0000 Received: from localhost ([127.0.0.1]:39604 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW0Tz-0006l1-FY for submit@debbugs.gnu.org; Sat, 16 Nov 2019 10:59:31 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46714) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW0Tx-0006kp-Md for 38181@debbugs.gnu.org; Sat, 16 Nov 2019 10:59:30 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50684) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iW0Tr-0007af-W8; Sat, 16 Nov 2019 10:59:24 -0500 Received: from [176.228.60.248] (port=2938 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iW0Tr-0000sC-EW; Sat, 16 Nov 2019 10:59:23 -0500 Date: Sat, 16 Nov 2019 17:59:21 +0200 Message-Id: <838sof7qxy.fsf@gnu.org> From: Eli Zaretskii To: Jonas Bernoulli In-reply-to: <87bltbooqq.fsf@bernoul.li> (message from Jonas Bernoulli on Sat, 16 Nov 2019 15:54:53 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <87a78xnrp0.fsf@bernoul.li> <835zjl2mzs.fsf@gnu.org> <87eey8og08.fsf@bernoul.li> <83o8xc6wsn.fsf@gnu.org> <87bltbooqq.fsf@bernoul.li> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Jonas Bernoulli > Cc: 38181@debbugs.gnu.org > Date: Sat, 16 Nov 2019 15:54:53 +0100 > > > If this is to make the mode line prettier, then it should be done > > once, at the beginning of a session, right? In that case, why calling > > redisplay after loading the package or enabling a feature is not a > > solution? > > No that won't work. Each buffer has its own mode-line so when > a new buffer is created, then its height has to be calculated. Ouch! > In practice all mode-lines have the same height, so if Emacs could > use the height "that all the other buffers/windows are using" when > it does not know the actual height, then that would help. fit-window-to-buffer doesn't use (or know, really) the height of the mode line in the scenario you presented. Instead, it gets the height of the window's text area (which excludes the mode line and the header line) from the data stored in the window object. The problem is that this data is recalculated only when the window is redisplayed, so without the call to 'redisplay' we use stale data until the next redisplay cycle. However, if all the mode lines have the same height, then the problem shouldn't have happened, and so now I wonder what am I missing. If you simulate the situation where the mode line changes, while keeping its height (even if that height is unusually large), does the problem with fit-window-to-buffer still happen? From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 11:20:20 2019 Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 16:20:20 +0000 Received: from localhost ([127.0.0.1]:39613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW0o7-0007Fc-M3 for submit@debbugs.gnu.org; Sat, 16 Nov 2019 11:20:19 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48132) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW0o6-0007FO-30 for 38181@debbugs.gnu.org; Sat, 16 Nov 2019 11:20:18 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50859) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iW0o0-000768-4u; Sat, 16 Nov 2019 11:20:12 -0500 Received: from [176.228.60.248] (port=4186 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iW0nx-0005Ue-DU; Sat, 16 Nov 2019 11:20:11 -0500 Date: Sat, 16 Nov 2019 18:19:55 +0200 Message-Id: <837e3z7pzo.fsf@gnu.org> From: Eli Zaretskii To: Jonas Bernoulli In-reply-to: <878sofon8v.fsf@bernoul.li> (message from Jonas Bernoulli on Sat, 16 Nov 2019 16:27:12 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <878sofon8v.fsf@bernoul.li> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: rudalics@gmx.at, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Jonas Bernoulli > Cc: Eli Zaretskii , 38181@debbugs.gnu.org > Date: Sat, 16 Nov 2019 16:27:12 +0100 > > >> Could fit-window-to-buffer invoke > >> 'redisplay' internally, perhaps? > > > > It could but it's called way too often to warrant such behavior by > > default. But we could give it a separate optional argument so users > > can avoid the advice. I think Jonas could easily write and a test a > > patch along this idea. > > Again, the mode-line-prettifiers are not the ones who create new buffers > and then call fit-buffer-to-window. It's arbitrary other packages that > do that. So how are mode-line-prettifiers triggered by those packages creating and showing new buffers? > Of course fit-buffer-to-window itself could be changed to do that and it > could also be taught to only do so iff the user opted in to doing it. Can you suggest a way of knowing that this situation happened? > Creating and displaying a new buffer and creating and resizing a new > window surely *already* causes a "redisplay" without the programmer > having to explicitly call `redisplay'. So if we explicitly tell > fit-window-to-buffer to redisplay, then that means that we are > redisplaying twice, right? Yes. But if you don't call 'redisplay' _before_ fit-window-to-buffer, that function will use stale data about the window's text area height, computed before the mode line was updated. You are right saying that displaying a window causes a redisplay, but keep in mind that redisplay triggered by that happens _after_ the command which enlarged the mode-line height finishes, and by that time fit-window-to-buffer will have already run (using stale window dimensions). > I am under the impression (but this is just wild speculation) that > redisplay only performs some of the necessary size calculations before > doing the actual redisplaying. But some other calculations (including > those concerning the mode-lien) are done only after the actual > redisplaying has already happened. That is too late for this redisplay > round but causes the values to be in place for all subsequent > redisplays. So the fix could be to do the mode-line based calculations > earlier? If you look at the code of redisplay_window, which is the function that handles redisplay of each window, you will see that it indeed calls display_mode_lines near its end (because the mode line includes constructs that depend on position of point and other state, and that could change as result of redisplaying a window). However, if after calling display_mode_lines we detect that the height of the mode line changed, we schedule an immediate thorough redisplay. So your theory doesn't sound correct, at least not when taken at face value. And once again, please keep in mind that by the time redisplay runs (without an explicit call to 'redisplay' inside the recipe you posted), 'fit-window-to-buffer' was already called, and it already used stale value of height stored in the window object. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 14:28:31 2019 Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 19:28:31 +0000 Received: from localhost ([127.0.0.1]:39717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW3kF-0003Kt-FO for submit@debbugs.gnu.org; Sat, 16 Nov 2019 14:28:31 -0500 Received: from mout.gmx.net ([212.227.17.21]:45509) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW3kD-0003Kg-Is for 38181@debbugs.gnu.org; Sat, 16 Nov 2019 14:28:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573932491; bh=bXj7kQ/7KmAooHkByXAxVnXCvBEW54gx7NOSXpWqxGs=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Gn9eIO5dhkrQLDPOfK0eFe1JGFdqZ9ftby0kDArsiI2/uKJqkOXGIpfHjXeo7OtuR eIf72kuDkNEmaa+FL2y7jmbecgKggivmkagjBqNV3RJlVTG4xfGdvc4UBDDTfpLGr7 Zi0Uj6GDy5nHQIhDD5KrUH83OzHFlujvhv8i+Q0c= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([212.95.5.86]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N7zBb-1hkblY1cxP-014zWw; Sat, 16 Nov 2019 20:28:11 +0100 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <83k1806qca.fsf@gnu.org> From: martin rudalics Message-ID: Date: Sat, 16 Nov 2019 20:28:10 +0100 MIME-Version: 1.0 In-Reply-To: <83k1806qca.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:cz5Vu7DjdRzUtgJ/L2q82y4zpP8RHKUCaIqrmcMjTNZXNcHx14t LFsX54FCp2mExS1PnMrvnUnaEQS1DmaDwzeiI8L0Om+Pj5e7eMi2keMbD41a2wjfF/jmbuZ PpNTx+xAZqKm2zmtQZFDRmjr1RQufWSUeYyOSkIDp/yzaKmEtUyi4Hz8Zm1OgAcGEZoBBUF qrItCE3EQggqtbQWs59Ag== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:gy9lw3gma14=:tSRYBvqNV4ddWKWgjGvcLI PLdlMehfB7AiRAXKMyDAKENjkjp7qe/yfO7v+J8VJsEduLrifjXDxqQhQMGr1Hm/Ljdlgpkdo n+lBbz0EH7v7VGnDCF5ZoocPhEAQE7322GLn8ddFb6EVwtGe1tc6Uh0v3vsep+bb0v7nEjT+r AJ4zHE5wYX8/7mcyLPhOrRdzb7rYutMHhkHC0OjDsXmx5qe5xIbDgqTrOx8DVDNOqlzgtiCdU kYpBisbILB+zJbyZGjCvB2p0oyh/BHPzhiv51x7uqzc4/uyiwzlO4e7nWO/NldZlcd5UPtJWm JIsbHB50Gta3N88ea+wdSSFKwH+pk4kTwwTF5xdi3ib1c7mpZN3/7NjPTrWnm0SINnsNrMP2v qjoV3ofg6OadggerCAf3UedOJbhYWs2IP5YULS8RIaHTwtxhQYKCGzJc/pkKlxRWhvTcCwJIm WTEk3HbU1T3xEM+9anjfb9kc/xYWlFZLN6PSEJtSgC6cTyZDd4WqAiuzjgWEi3F2V26AjtUkO /GK+RomosFymBp9XiX9CJ5Vjsk19wHgUF+0BvdpkkAwIoaqAfTBug9CUYHbBWzKa0SIWGriYB KdRohacDx2LZ/SRWJLWmnoQhKmV2rKqhKcPwNd8/QqsQAPpc/qmQ7nBJ1QLt/bYqDjAcsJzts 78Va/YgAtDb8MMu9WSa6x2lWwhT4SlviVIEQp6/8ZdLR778RRQOHU4ZW7HWyknUcfChKvIEYt CEzdZzXjXh/RzVrXdduMxDxuljg4iXLWvR6TZ/hq8DIDYutxQExNHemtLohoAsZEOh90twCxY u8L5Z/a9hSu8bcwjpUCXB2Jav4oCkoBQXe6eods6BiNDsd2ErDU/mZaa52W/u34PQXj4m1QC+ j+qj7pS0QPlfkUM+uXP6S1oeEFovlWUvvanEwJjAYbFTSmlOKzn3Y1lThfZv9S98S0Sy+TiLz o8OK3Nm+ztFhzOMKJYRGbrEx5VFN6KuwLwIBrninx+tsw/vo1FrbVFpBP95NGiMTvSrKCp18W YEofXwjDEJR+oAomYm0DF6GFpNuY5+fsoCTW4uUpNmeQ6Oe7kWJ6kPDfs1dfkfc1AfoW4kTE8 K2GLoIaGj9yE6s+kVkX3jaR4q7po21hK1iGQOoYAY8SpnKY8mA4ZJOwyjvKdyQqAoqn2FpsLQ XwXji+OtDe2g/Bo8R11571Tnma9ZW3M+Cksf9bSjfCE4e1RRHrrh3RLosateEIni9ML8xQRVx jWl+zH3inqEFfydIb1feYeG8Y1CxgDFAiDBzpjDZ/XsaQm7/Yv0CjtCHFiXo= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > What are the frequent calls? Help and completions windows come to > mind, but those are interactive, and so I'm not sure I see why calling > redisplay would be a bad idea there. Are there other callers which > I'm missing? The functions for displaying temporary buffers when 'temp-buffer-resize-mode' is on. I do not think that the overhead for calculating the mode line height is excessive. It's just that IIUC even Jonas changes the mode line height only once per window/buffer assignment so even for him this overhead is practically always lost. >> Right. But that same program could also redisplay all windows in >> these cases, right? > > I meant that calling redisplay should do this automatically. By calculating the mode line before drawing the scroll bars? martin From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 14:30:22 2019 Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 19:30:22 +0000 Received: from localhost ([127.0.0.1]:39722 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW3m1-0003P4-Tq for submit@debbugs.gnu.org; Sat, 16 Nov 2019 14:30:22 -0500 Received: from mout.gmx.net ([212.227.17.21]:40805) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW3ly-0003Oo-DT for 38181@debbugs.gnu.org; Sat, 16 Nov 2019 14:30:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573932612; bh=tl0HPEOMgL3TiqpXTd2dLaeXLQrrsdj6XehvjdUHjV4=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=RD9a6xEYGByO0zM1HHS/sp44kZxAHl7Oe9VFHyDtjcBU+OuIS16aJDDCbz5VOhrLA KxbHAecG887cx+7MQfSqDQKFpbB8CISTZDSNyexiFgEhtieUV3aDPEbd0CWQvCUjQA vIez6g324SIsegaKsO2JnUzoWUdnqruv6B7XihVM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([212.95.5.86]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MKbg4-1iHg9Q1LjQ-00KxRk; Sat, 16 Nov 2019 20:30:12 +0100 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Jonas Bernoulli References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <878sofon8v.fsf@bernoul.li> From: martin rudalics Message-ID: Date: Sat, 16 Nov 2019 20:30:11 +0100 MIME-Version: 1.0 In-Reply-To: <878sofon8v.fsf@bernoul.li> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:earPChNY/BcSwyL4PTkabyUhnpO99Td+eMfvJjjk7fnfFcIQ7La 5l2OBEHrCMFnJrdTAnXVTjjgc6ap+dGboHpFZ+dlgC0HOTaC1RYC1xNNJXeBiUtZtTM6v3q 9FtirHM6ZtSKOKSkG4A+6AUtZ9boLPJ6dp12gs93N9YrL8H6Q8mlFAlAlpfnS6Z7HufO7L3 AvPGo2zf8bfw5Oa8IiibA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:iB7oetm4dOM=:dYmKu/q47L+l5aAZynqtjy EXljYHy/MQcwPkvDGebPScK8bbD4jJE70GJn56H6OfZS3UC41SjTw2QNhJw7UHj82ma4XY925 JlaGUCwbDsF4uk5dI+SvQZ170YhQ2+osWmH/qTJxKUXsbL9wSd4VAhO7q/G8vEETDRJYEkKzd T3xobpDfZlBVcYgRvaR1aKudq/Ag3CK5qR3GOTeRBEK/BU+0udis4wKsyEtp3+tbTljJg15Qj zNJv149qcoZzjHF6tWSxzaiXliXAJCuvP8eX4e6nqpnbIcMu6UpWYvhumgFluI25rtcAJhTxv hy8q53yQqsFiyfrc/xUTM6GJXQKIS0eQ+3R43CelWc52p+ymGWIVjBA1J7GmjtgooyWjSCzvx m/SX1W8g8qgpWzbfXNoAiRo4Or3wVDSOEowIJn6bt/BJS7oEy2fBSrKzzKo4WTxJPymdPWuyx UfHgX3QTlMVsVuKU2BJ4sQSeMYS3RPDV49vChH41obJQmI9n1klqawiocHuXVH2WePidRzQ4q iNKDfoKvjpsAZTxCrs6cQi6c7Kyr4ndC10Ge5IhmHAwh24yDfWxe6xjhhGHUPlPZra6VhqfMy XFsAgkes3zBTUiYM3iYbza/iejnuqZHWkzSSkSLJpNobaKRpQBUnu2wDV8jGn5xYZLqqBqrwv WH9LfZM3iWzdrdkqjZ3lsdW50lTo4iZZVFFdT08q6ynAtQz3ivYdNiVa/2muuXvM/gA0voL0S ZKkVjlaF6Lut/8jGWDpANw+lx+RwccBfzHNMZR14WLnETsi91+G3NucdgHAVjhFaSnZSG+yWv RVh8agpr7ZLFzl2842gyPyJYcGCpZJWrQReB9UtXrXQMaI4NPlQdSzXtbgkj9QAVJxeBJhKGy SroGEHzyqISgTIdZ8K675w3FuyLxwB9f3YNVm3ZcqTAGJXGcOK7/coOJN90+s47r1pxKNO6kL qZRBaloJpNaNHh0UZRy+PInBOS9JaReXbQxqcWDTiHx4B9ZaVUBlogCgshsOzVKKY8aALgK5d k9t33L5RMwEwBbVEPn+MIp0a6mhk0IZdm52zQXkrfZHitrYrG1R+Nb9WRMuzOMqTsQcgEZ/ar a1if2SWKbBi0PlAx3+UhLpP887YTdPD3JWqXui3uhpiCmFz6CcrI5aaZp4KLJIhsrqQBCgBl2 VJol61nzSW6ZFM6p2XwnGfHWmSyD8jMLZ0Ex8VmzBEIrol/A8jftsQxvBGC6181vtvtXsZxI2 rD6vWNsKQFWuLO10znkHE3NGwmsYmQ6RcizhrvaQMHzTL64olxk8nAWmstGg= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: Eli Zaretskii , 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Again, the mode-line-prettifiers are not the ones who create new buffers > and then call fit-buffer-to-window. It's arbitrary other packages that > do that. An optional argument therefore would not help because when one > of the prettifier modes is active, then each and every third-party > caller of fit-buffer-to-window would have to pass that optional > argument. I see. Maybe a function 'set-default-mode-line-format' would be useful here. Anyway: At the time you prettify a mode line or show a new buffer in a window with a to be prettified mode line, would doing an immediate redisplay work around future problems? > This is the advice I currently use: > > (defvar-local moody--size-hacked-p nil) > > (defun moody-redisplay (&optional _force &rest _ignored) > (unless moody--size-hacked-p > (setq moody--size-hacked-p t) > (redisplay t))) > > (advice-add 'fit-window-to-buffer :before #'moody-redisplay) > > Of course fit-buffer-to-window itself could be changed to do that and it > could also be taught to only do so iff the user opted in to doing it. If we don't want 'fit-window-to-buffer' to do that always we'd need some variable, either buffer local or even a window parameter, that 'fit-window-to-buffer' would inspect once and reset immediately in order to perform only the redisplay call that's really needed. > Creating and displaying a new buffer and creating and resizing a new > window surely *already* causes a "redisplay" without the programmer > having to explicitly call `redisplay'. So if we explicitly tell > fit-window-to-buffer to redisplay, then that means that we are > redisplaying twice, right? I think so. Maybe 'fit-window-to-buffer' could use the string returned by 'format-mode-line' instead and calculate its height without redisplaying anything. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 14:31:13 2019 Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 19:31:13 +0000 Received: from localhost ([127.0.0.1]:39726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW3mr-0003QX-BL for submit@debbugs.gnu.org; Sat, 16 Nov 2019 14:31:13 -0500 Received: from mout.gmx.net ([212.227.17.22]:32879) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW3mp-0003QJ-4I for 38181@debbugs.gnu.org; Sat, 16 Nov 2019 14:31:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573932655; bh=PCPFyDuMkL0MIQtVvf8BHP9BbGFx5CW8I2pAScdR48s=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Yq6dcQ4J30n4+Sa4io6u9Nq+fhhbC50+59M9MQxkQV2XJpRx/I/BLmbUP5WMc0cYG TefP6SSFC3E2pueXblL2fglQXqr/GbSmUf5TuTqdplgqtyXYKBlVTlvSuPkbB6NH+4 wUJhvie3iFBzf2eZyac6NVyDLsiXpa3EU/r3l5u4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([212.95.5.86]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MzQgC-1hawxT1HAe-00vN7k; Sat, 16 Nov 2019 20:30:55 +0100 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii , Jonas Bernoulli References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <878sofon8v.fsf@bernoul.li> <837e3z7pzo.fsf@gnu.org> From: martin rudalics Message-ID: Date: Sat, 16 Nov 2019 20:30:55 +0100 MIME-Version: 1.0 In-Reply-To: <837e3z7pzo.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:+VGC5EwaExBeqsmOoaX6JZyhouhOjsqgwA1zB/QkhI4aVm/OMGF F+RnAtt/dq4EdxqFtCSSXOGzICv7dZqUfPgNSRDHX9vcWAaQWqm8DPHaVNGrtqug4+oeghQ F+XNLYrQ56xLZOpuCOV5XEooSPym4wf+UoR0UnlNnfBkWF2OviSWTkaKHXFx4EuvW7VhhHN iV+K/6ABmuiPg/CUPtH7Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:OIWFvKqLtxo=:XW0Uu1AsEn8k6aeNBvhOiZ tVzmUAQ0o5MVq244F1E4akMJw2QgY6XJMM2aJMWYYzmVo7Kao+/CecEkLCnthaOZhNQkUl2V+ kNoBVpjIkZSSOYYtzIBJBPWhFOyeimNTSYc5aTlW8cYdPzv8iDuQWSHsONNaYhvubaDuH2N+X k6X9anuur5hOQj3gMcGjw16P087eO+bfpFmQIbgWebbty89mbruIvzlDF0qsQ0cbaYLnSEpyu NSJxLwjBWJDsTlcdtCOQV32xbiTPOvHt/pGvVCgmwCsNxsqfJr4z9DwwVGOjBDrz193GDyHCh fUmoNLdIqs2Q/XILuPZNWRVeBdMcTQ6Kq/Tw59HDNlyeQyKb5Idfonbfc7yHJwv9LPXtctVET YrMyGkWh3neIlYoaxLcBXRKYigm6LWZKXv+u4Kvui1kvc+bJ0uA18ZHu7etWyKkZM+d69fz9w h2x4K5aQwBdOA36elKgDSp9hCVqEtIXERXYojgfnBxiMxOzwkPOgqpLUHqHjUZw76fCVp/jCv UiMLQDEz4k5Cn1Yulgw3tZi61FjF5kfMftf3IVdHBpo82nXnufgsSRzmde1kPcdRq4QOsFzp/ /XHW4OlegW14nlkHDSahAYR6UZxA00Sz2jxZDtmxEt+Yn5vCi7doNqtPFVTA0lSR3C2c7otGO nfdkKmWDYMLl+gmqUHVWhcKD2X5oPSgzhkOb+tLMxH8xATHlxo2dT8hW1JwXLee+gvjrfDi+4 /5WfnAzTFiRWRGmlWPOz/WiR/KTuj/5cX43dL1VrUcyYebUaRgXWcDmFrY7cI3G8C4G0Y1qOR ETCVQ5UgnWH8OAkm0xHjKgxpqrJhDvKcviHvQjt9192bzxh5rmg4j0WRQT6tzVh00C2eQDs64 cO3Vrz9LjdgnQ/WNRl5Pexx2HprKRdcryK8mPUD3Xjs5wh+GJH9+TnAH+TPODrc37LUDzfSJi HjBuRY5ConmIAUMh+MvsqElDRaKTHejV3NfWJgI9fPq7Lr4eBQLvwgrWN8k0Jtg+qRDFPnCPX MSWni3po+tz842EnZDRqYoaX1NFYg4UZkreiz/9A8KV2D989zJeh94sF1hAbDyIQcoKzx0Ndb Fkoia43NREI01HofF9z2LSWVm/Txpm7DspHZdwAR43/C4qoJKJ8MR5ylubFh8Vm0rkB51VVdy is/dKiDi7CwIZuLGTveQItO6ufX5KrKyvFK3d9GVC+hpMqLH/cZNQqaLqgtS4netelkuDFfYC uAEIz3TcszGw0SjWnjaTWIUIzwCaaNKyQkoZQtLY2qYPU1g974v9OIv2QgRc= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > However, if after > calling display_mode_lines we detect that the height of the mode line > changed, we schedule an immediate thorough redisplay. =2E.. which, unfortunately, will not re-run =E2=80=98fit-window-to-buffer= =E2=80=99 but just use its earlier computed values. Theoretically, 'redisplay' could check the 'preserve-size' parameter of each window and try to preserve the text height when resizing the mode line. But I wouldn't want to think of all the tricky details of such an approach. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 14:44:34 2019 Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 19:44:34 +0000 Received: from localhost ([127.0.0.1]:39735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW3zl-0003if-Vh for submit@debbugs.gnu.org; Sat, 16 Nov 2019 14:44:34 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38952) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW3zk-0003iQ-7w for 38181@debbugs.gnu.org; Sat, 16 Nov 2019 14:44:32 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52401) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iW3ze-0003Fx-Di; Sat, 16 Nov 2019 14:44:26 -0500 Received: from [176.228.60.248] (port=1204 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iW3zd-0003Qm-Gj; Sat, 16 Nov 2019 14:44:26 -0500 Date: Sat, 16 Nov 2019 21:44:24 +0200 Message-Id: <8336en7giv.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-reply-to: (message from martin rudalics on Sat, 16 Nov 2019 20:28:10 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <83k1806qca.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Sat, 16 Nov 2019 20:28:10 +0100 > > > What are the frequent calls? Help and completions windows come to > > mind, but those are interactive, and so I'm not sure I see why calling > > redisplay would be a bad idea there. Are there other callers which > > I'm missing? > > The functions for displaying temporary buffers when > 'temp-buffer-resize-mode' is on. I do not think that the overhead for > calculating the mode line height is excessive. It's just that IIUC > even Jonas changes the mode line height only once per window/buffer > assignment so even for him this overhead is practically always lost. But I thought we'd established that mode-line height calculation is not the culprit, the culprit is the fact that a window's height is not recomputed when the mode-line height changes. Did I misunderstand? > >> Right. But that same program could also redisplay all windows in > >> these cases, right? > > > > I meant that calling redisplay should do this automatically. > > By calculating the mode line before drawing the scroll bars? No, by triggering redrawing of scroll bars when we detect that the mode line changed its height. In this place of redisplay_window: display_mode_lines (w); /* If mode line height has changed, arrange for a thorough immediate redisplay using the correct mode line height. */ if (window_wants_mode_line (w) && CURRENT_MODE_LINE_HEIGHT (w) != DESIRED_MODE_LINE_HEIGHT (w)) { f->fonts_changed = true; w->mode_line_height = -1; MATRIX_MODE_LINE_ROW (w->current_matrix)->height = DESIRED_MODE_LINE_HEIGHT (w); } Or maybe in redisplay_internal, when we see that f->fonts_changed is set. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 14:45:26 2019 Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 19:45:26 +0000 Received: from localhost ([127.0.0.1]:39739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW40c-0003kf-EV for submit@debbugs.gnu.org; Sat, 16 Nov 2019 14:45:26 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39092) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iW40a-0003kT-Ee for 38181@debbugs.gnu.org; Sat, 16 Nov 2019 14:45:24 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iW40V-0003nu-9X; Sat, 16 Nov 2019 14:45:19 -0500 Received: from [176.228.60.248] (port=1257 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iW40T-0003WX-RG; Sat, 16 Nov 2019 14:45:18 -0500 Date: Sat, 16 Nov 2019 21:45:15 +0200 Message-Id: <831ru77ghg.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-reply-to: (message from martin rudalics on Sat, 16 Nov 2019 20:30:55 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <878sofon8v.fsf@bernoul.li> <837e3z7pzo.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 38181@debbugs.gnu.org > From: martin rudalics > Date: Sat, 16 Nov 2019 20:30:55 +0100 > > > However, if after > > calling display_mode_lines we detect that the height of the mode line > > changed, we schedule an immediate thorough redisplay. > > ... which, unfortunately, will not re-run ‘fit-window-to-buffer’ but > just use its earlier computed values. Maybe fit-window-to-buffer should set some hook, which redisplay should call if it finds out that the mode-line height changed? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 03:56:07 2019 Received: (at 38181) by debbugs.gnu.org; 17 Nov 2019 08:56:07 +0000 Received: from localhost ([127.0.0.1]:40258 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWGLm-0000AU-RT for submit@debbugs.gnu.org; Sun, 17 Nov 2019 03:56:07 -0500 Received: from mout.gmx.net ([212.227.17.21]:46237) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWGLk-00009z-RR for 38181@debbugs.gnu.org; Sun, 17 Nov 2019 03:56:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573980948; bh=EYgOeHX2UiTJkW+hu/cmR4wbxG14NzdV0oCpen/Xk34=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=UFy2IwXODp65sfvDma30AtC9XttWR7r9c8cztYD8dvGNKVxFH11KW9hurc3d8WcEO NOfANyX5vay7J8qqmTPCrvt1zJQfAyM10yH/FW6ATlJZGlHnuv9rle2gRhSiLa7A3s 9S0maEi3gOJAalMWJoy69aM9nehT5oqR0nJxOhHA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.103] ([212.95.5.179]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MRTNF-1iBB7R2v6D-00NQuz; Sun, 17 Nov 2019 09:55:48 +0100 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii 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> From: martin rudalics Message-ID: <81264049-4f88-fae7-6448-e0ac5d977268@gmx.at> Date: Sun, 17 Nov 2019 09:55:47 +0100 MIME-Version: 1.0 In-Reply-To: <8336en7giv.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:Zg0Sg/8BxSR5czgSTvIJE4IMbXD7QU8n+A+uxSHbUdSQfi8PQWb IgEdirn9EFBOGBvQHMVaFEMVpS+JDgx+J8ndu+U7dGCylzVj9cEVW7Te/hLKDekZR0DJEgW tCTvLWS9ssoDqTMQhWGrLBDS7McNvrOWXiAZfrueDY9DsaLHWyFLxU5h/N7G9BdUTcHNSFI V5vtfH58tqDVq6cbh7Gaw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:ZevKaqskI0g=:VUdMGWWG3vcdkK3PIIj0lx H3eUFTc9oIN7z053Xq43+dtIGYLtsfeOZtmv6B8ozaKwfGCUL3db0vd34/qmQUY+3PX4SDEPx KLLvL8em/f/Vd1exd6QLoIfaEfReXx/zt+T40+3S/36bYTv6dkb5dJZxSjF/E/7WENNTYLHCl u2uW+YAOpdE2qF/12nbsujPxGeVQvmla0RnXmPUD4dRfED6vXFQwy1ndRH/4QxENUYkmKiVoM SNL0Mj0h/cmH4vazr6xnlMaPclBc8cyleHbBdkGQPM6zsuHB2VE5gychLtHfyZS+KYBvr+FTr gPakU7GWXc9+Zo5XN3FPQFIaBI/mnMd3RRJCY0oA0VWgPuEjck0dY69OM6v/gMxH4N1RxbpqZ LjJLsVOvZ2TR/JrWx3ckOOv1vJOgGYDvigl4xp9X9YF5LusOSRt4XA67PtBw8aex//tMLsc+7 2BENWGWHsAJDrASduzelVbS752Q+cpzzJLL4/wMDE3Unm063mTYO9VdXC+utglfnvuvvUkIFk 50OIVC3Jqb91MVFUZ/Mf+bk8cvPVdF98FD0kQdiXB+8N/zsWD4DuCoFW/7U8LABg2xLGcWOsM Wkevyab1ytRsgfQE/M+Klr+EkUUkCGUJq5BBHRQ4V5N4VFNRR9yv4pBDKVXJZkD/ZYpE6VUek AnBECPGZXlNoK/Tn5ueqjkIV49osj3SyxI0qDDTPqidicayDpbfBBtHpw+T+4+NYjmClqEl/3 AuZh2jv04upupWqCpe3mYQ3Y+f1ryf//mnrhNVXjPeZuSaus4atMKDvWOGOUfCmj5D7jV2tOi ydiWnU+WGDAgMW9k9lQ8EP/jaEXfreGx9X0wu5vxXYoK9UED9QiRojCyrDVtgvy2hMCf4NApa OohTBDBOkx5f/wQS0tRgfHTV6lcnU3O4QKEsjIF+bv7bv10d7GUXR7GzCuUltWjp9+twrhMTO 8K6Fu+Cqc5NV8750g60ncLpiusIXZKrLSrGfecbEvJZLgXQB6Nkkprb7UWg833a5C97oEINJn wuuj5I7Hx9tRV8/CvHqQvnYfOXEjTE3KXi93ybgCLhlay0CZ/w2KPl7o8AlCRGfGGg5tHb1kU l+IPBmTHgOkupusnH5LwM3V9Vyo9RxkSQja31+RUeokYMflHt8eeQfhv+HBu7EUn9YHFeeweA qbM5SnfDyB6dJJOUxtuODJwY7ksUV5hYjntbXgSzHMwMyf4m4fBtJw+qIgwLDJzg6TukHzmvK XJqvRpYguhPx2bTSSj0s3CJKMpuadN6S9CaHdpZ8rOOWO64SxpjDHIe0UPd8= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > But I thought we'd established that mode-line height calculation is > not the culprit, the culprit is the fact that a window's height is not > recomputed when the mode-line height changes. Did I misunderstand? I don't think we contradicted each other's sayings here. To recapitulate what we found out so far: (1) To operate correctly in the user's sense, 'fit-window-to-buffer' has to know the height of the mode line of the window it operates on as it will be shown by the next redisplay. (2) When users or applications (maybe implicitly) change the mode line appearance, they have no generally established way to tell Emacs that this happened. The display engine has to find out by herself but then it's already too late for telling 'fit-window-to-buffer'. The question we yet have to resolve is now "only" _whether_ we can safely recompute a window's height after redisplay detects that the mode line height has changed. This may easily trigger window change functions which might easily change the mode line height again ... martin From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 04:01:58 2019 Received: (at 38181) by debbugs.gnu.org; 17 Nov 2019 09:01:58 +0000 Received: from localhost ([127.0.0.1]:40265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWGRS-00021p-4A for submit@debbugs.gnu.org; Sun, 17 Nov 2019 04:01:58 -0500 Received: from mout.gmx.net ([212.227.17.21]:49667) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWGRQ-0001w4-2K for 38181@debbugs.gnu.org; Sun, 17 Nov 2019 04:01:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573981305; bh=RePeYdgb1sbk1BjcfPz0ShTwgIGCD30OJMBDbnZTME4=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=QUlei22XUUrT/JVTv/zZAjdc/Zuqn+GSwa3z0jWoUtPj7tuuYshfyTvDboMq+Gqwz w3ujjuePEVbEnF7L6Reh28ps7b5Yf13OOXauill4lcCoKthXPsUufBM3DC69JoevTD aja5ZEYadoo3PBmBEYdtwymLSbKfS8J6v8vV8ipU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.103] ([212.95.5.179]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M6Udt-1iTnaj3ykT-006zPk; Sun, 17 Nov 2019 10:01:45 +0100 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <878sofon8v.fsf@bernoul.li> <837e3z7pzo.fsf@gnu.org> <831ru77ghg.fsf@gnu.org> From: martin rudalics Message-ID: <9700fac4-b75d-cd6e-3360-78bd0f8c7db0@gmx.at> Date: Sun, 17 Nov 2019 10:01:44 +0100 MIME-Version: 1.0 In-Reply-To: <831ru77ghg.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:9MFuOhzYrOYl+RdcNDITTOJ1mr5Cu3vopvjxVlShcH449b8/b3B SDiUSxwgxVUPy8azXBa1/PqIhXZS7CZRYT6j1HLd8Z8Q8AhOVu/hTwrN3Ic3NiwpUfdfO/A tc8Cg4BlQKz+dQD/FRb0NJ+pBi0chgHgNhqmfRstIZ8ugRIycsbekyHUR+YYr87oWvhN3Ds PIM0i+0fox6OesIgAYCbw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:+9iNtlQ0eQ4=:dLUotddIwrchA+DcZEuBO2 CcgN08hr+DSkwMemZ8EThLyZh+oceTPRk5V48fa8jXaEjnad4CNajdOnt+5Z2aGjgrna5Xvou cs+kT42HU9AuW8OOaPJeXaq8TLNdCH3ejwRgviiuEqjCzbpH4LsjldUydgQUVqVPzn+o/DXGF LJDSyxmaRJICMQ5nHezrfIDrfH/wJfhjN0xCOJfBj2GLn8TBlABLa30r8P11e0gRNrEmKfKoO gKq3bQNvdJ8HbYirzSJWx/uIuGcN/4VNMcn8N6rr323YiecPI7A2hsqpwRIxlTIXVgA+Avu1t XJhGZnM6KEthn+K59wSjCTadX6YNaB2FyMBh8m0sNzbFG4Hgm1V8ej24pQoaQafa8bg4G6uyJ hVngkQA78BYAjfDRuoaofH1oq0tf0qRa+o4rjy6Odb/o3wpDbextLyptjE9alsp6MvD6aqj7h P44sWDxBGbSt/BrjMo+VYZta20U8GzxaWROjbwVllW6AwZBeC5celDheJQ2HTxrykbvTPBRaV x3U8o2CJEHHHLPlIMezPtMMf62RzlV4OXhpPk8yUh9eRaobQJCd1+9vDk7fF4ZwX0vrt7Fiif v6F1dcXzgCuy7r05Oq00/0uh1W+MIq7bFC98pqfXDD4XXXJEBhnTCg5MZ852jf4x6yEveDhai 9KyfBxBxZk5eCz8r9U8ASBaLx7Za5fLJX7SqEfJTbsSwoxOFPqxIndiohxY4jMipYTqmN9JA5 LFEkPxwzQC9TcU5Oy6u7jQGJpI0WUVcWa/VoVreOEPhnB07DDIpcr8gjOQTVvqt2mKmM6FfKR 1EKNocGVwlqXs8djzmlE3E7AE8NJT+ivCZeX2qiYU6CZlKzuAWtpfK5V0Kcr6Z/wfiupXNu1a btwgq6Lfja6gI+er67LtZrkAnwmZvzks5Kro1X6+vaU5bwG/Yjm8mAJhpsfVjXL+Ek+EfZM7T ajbi61NvF5fPMQEyOSXuAnXx/XL8kdhFymO7bpy3jByScii5rEMoMCXrUD9kaE22++pVOf5sr TERAjRjeROfUox4sa3sQngjzn+DXz3Ohm8S0HzlJvJIr7IsTl9IMKB4w2FTE1+BBXdsiG4vmC Ec1ZjnMhboGzCAonKkKWua7L5Kxiqu8N50Sqv/nq7J1b8n+IL2ZuVfWu7nNjLwYCnGfS4ekBw pO4siGV/KTDI+HOSyNKq5VtUIVN8cW2MssnBfND5nFc3xs/bpxHaWoiAuhkhY3w9piJvcc6ss UTEjwvvalvfcF8g8blIbE9IXM6DIh36sTi0SklW9g8Ig5xsrW6VYdoKlIcfU= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Maybe fit-window-to-buffer should set some hook, which redisplay > should call if it finds out that the mode-line height changed? Maybe a two-bits sticky bit-field in the window structure called refit_window_to_buffer. The Lisp interface to it is a function called 'refit-window-to-buffer' setting refit_window_to_buffer to 1 if it is zero. 'fit-window-to-buffer' always calls 'refit-window-to-buffer'. display_mode_lines sets refit_window_to_buffer to 2 provided it is 1 and the mode line height of this window has changed. The display engine eventually calls 'fit-window-to-buffer' for all windows that have refit_window_to_buffer equal 2 and sets it to 3. When the display engine is done with redisplay it resets refit_window_to_buffer for all windows to 0. This might be tricky for windows stored in configurations and states. And always remember the fact that in one and the same display cycle 'fit-window-to-buffer' may have been called for two windows above each other. So this is definitely not for Emacs 27. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 11:17:41 2019 Received: (at 38181) by debbugs.gnu.org; 17 Nov 2019 16:17:41 +0000 Received: from localhost ([127.0.0.1]:42450 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWNF6-0005m6-Uq for submit@debbugs.gnu.org; Sun, 17 Nov 2019 11:17:41 -0500 Received: from mail.hostpark.net ([212.243.197.30]:48520) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWNF5-0005lx-3l for 38181@debbugs.gnu.org; Sun, 17 Nov 2019 11:17:39 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id B1DEB16620; Sun, 17 Nov 2019 17:17:37 +0100 (CET) X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10124) with ESMTP id BZJGF0NolHKc; Sun, 17 Nov 2019 17:17:37 +0100 (CET) Received: from customer (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 426501660F; Sun, 17 Nov 2019 17:17:37 +0100 (CET) References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <87a78xnrp0.fsf@bernoul.li> <835zjl2mzs.fsf@gnu.org> <87eey8og08.fsf@bernoul.li> <83o8xc6wsn.fsf@gnu.org> <87bltbooqq.fsf@bernoul.li> <838sof7qxy.fsf@gnu.org> User-agent: mu4e 1.1.0; emacs 27.0.50 From: Jonas Bernoulli To: Eli Zaretskii Subject: Re: bug#38181: Actual height of mode-line not taken into account In-reply-to: <838sof7qxy.fsf@gnu.org> Date: Sun, 17 Nov 2019 17:17:36 +0100 Message-ID: <87mucua34v.fsf@bernoul.li> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: > The problem is that > this data is recalculated only when the window is redisplayed, so > without the call to 'redisplay' we use stale data until the next > redisplay cycle. > > However, if all the mode lines have the same height, then the problem > shouldn't have happened, and so now I wonder what am I missing. I think the culprit is that we are not reusing some existing window to display a new buffer but actually split an existing window in two and then display the new buffer in the new window which never had its mode- line height calculated. > If > you simulate the situation where the mode line changes, while keeping > its height (even if that height is unusually large), does the problem > with fit-window-to-buffer still happen? No, if the mode-line (height) can be "reused", then there is no problem. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 11:21:21 2019 Received: (at 38181) by debbugs.gnu.org; 17 Nov 2019 16:21:21 +0000 Received: from localhost ([127.0.0.1]:42459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWNIf-0005sN-5I for submit@debbugs.gnu.org; Sun, 17 Nov 2019 11:21:21 -0500 Received: from mail.hostpark.net ([212.243.197.30]:48862) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWNIc-0005sF-QH for 38181@debbugs.gnu.org; Sun, 17 Nov 2019 11:21:19 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 364D516651; Sun, 17 Nov 2019 17:21:18 +0100 (CET) X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10124) with ESMTP id 48JWTTOvrer7; Sun, 17 Nov 2019 17:21:17 +0100 (CET) Received: from customer (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id A45D016620; Sun, 17 Nov 2019 17:21:17 +0100 (CET) References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <878sofon8v.fsf@bernoul.li> <837e3z7pzo.fsf@gnu.org> User-agent: mu4e 1.1.0; emacs 27.0.50 From: Jonas Bernoulli To: Eli Zaretskii Subject: Re: bug#38181: Actual height of mode-line not taken into account In-reply-to: <837e3z7pzo.fsf@gnu.org> Date: Sun, 17 Nov 2019 17:21:17 +0100 Message-ID: <87k17ya2yq.fsf@bernoul.li> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: rudalics@gmx.at, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: > You are right saying that displaying a window causes a redisplay, but > keep in mind that redisplay triggered by that happens _after_ the > command which enlarged the mode-line height finishes, and by that time > fit-window-to-buffer will have already run (using stale window > dimensions). Thanks for that reminder. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 12:23:03 2019 Received: (at 38181) by debbugs.gnu.org; 17 Nov 2019 17:23:03 +0000 Received: from localhost ([127.0.0.1]:42521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWOGL-0002qh-Cm for submit@debbugs.gnu.org; Sun, 17 Nov 2019 12:23:02 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWOGJ-0002qU-Tk for 38181@debbugs.gnu.org; Sun, 17 Nov 2019 12:23:00 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iWOGD-0006M2-WF; Sun, 17 Nov 2019 12:22:54 -0500 Received: from [176.228.60.248] (port=4559 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iWOGD-0002mL-9x; Sun, 17 Nov 2019 12:22:53 -0500 Date: Sun, 17 Nov 2019 19:22:54 +0200 Message-Id: <83blta5sep.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-reply-to: <9700fac4-b75d-cd6e-3360-78bd0f8c7db0@gmx.at> (message from martin rudalics on Sun, 17 Nov 2019 10:01:44 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <878sofon8v.fsf@bernoul.li> <837e3z7pzo.fsf@gnu.org> <831ru77ghg.fsf@gnu.org> <9700fac4-b75d-cd6e-3360-78bd0f8c7db0@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Sun, 17 Nov 2019 10:01:44 +0100 > > > Maybe fit-window-to-buffer should set some hook, which redisplay > > should call if it finds out that the mode-line height changed? > > Maybe a two-bits sticky bit-field in the window structure called > refit_window_to_buffer. The Lisp interface to it is a function called > 'refit-window-to-buffer' setting refit_window_to_buffer to 1 if it is > zero. 'fit-window-to-buffer' always calls 'refit-window-to-buffer'. I'd prefer a hook, because the problem probably isn't limited to fit-window-to-buffer. Wait, don't we already call window-size-change-functions in this case? If not, would it help if we did? > display_mode_lines sets refit_window_to_buffer to 2 provided it is 1 > and the mode line height of this window has changed. The detection of the change in mode-line height is outside display_mode_lines, see the snippet I posted up-thread. > The display engine eventually calls 'fit-window-to-buffer' for all > windows that have refit_window_to_buffer equal 2 and sets it to 3. We need to figure out the "eventually" part. It should happen after the windows have their dimensions updated due to the mode-line changes. Do you know where this happens? > This might be tricky for windows stored in configurations and states. Why tricky? A stored configuration shouldn't be affected by any changes after it's tored, no? > And always remember the fact that in one and the same display cycle > 'fit-window-to-buffer' may have been called for two windows above each > other. Mmm... actually, it could be that we cannot resize windows during redisplay at all. See, for example, how resize_mini_window does its tricky job. We may need to call this outside of redisplay. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 12:26:35 2019 Received: (at 38181) by debbugs.gnu.org; 17 Nov 2019 17:26:35 +0000 Received: from localhost ([127.0.0.1]:42526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWOJm-0002wH-Rb for submit@debbugs.gnu.org; Sun, 17 Nov 2019 12:26:35 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58702) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWOJe-0002vx-La for 38181@debbugs.gnu.org; Sun, 17 Nov 2019 12:26:33 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36741) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iWOJZ-00009y-Hq; Sun, 17 Nov 2019 12:26:21 -0500 Received: from [176.228.60.248] (port=4774 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iWOJY-0003IW-I4; Sun, 17 Nov 2019 12:26:21 -0500 Date: Sun, 17 Nov 2019 19:26:21 +0200 Message-Id: <83a78u5s8y.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-reply-to: <81264049-4f88-fae7-6448-e0ac5d977268@gmx.at> (message from martin rudalics on Sun, 17 Nov 2019 09:55:47 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account 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> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Sun, 17 Nov 2019 09:55:47 +0100 > > > But I thought we'd established that mode-line height calculation is > > not the culprit, the culprit is the fact that a window's height is not > > recomputed when the mode-line height changes. Did I misunderstand? > > I don't think we contradicted each other's sayings here. To > recapitulate what we found out so far: > > (1) To operate correctly in the user's sense, 'fit-window-to-buffer' > has to know the height of the mode line of the window it operates > on as it will be shown by the next redisplay. I didn't see where fit-window-to-buffer looks at the height of the mode line. What did I miss? > (2) When users or applications (maybe implicitly) change the mode line > appearance, they have no generally established way to tell Emacs > that this happened. The display engine has to find out by herself > but then it's already too late for telling 'fit-window-to-buffer'. 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? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 13:15:59 2019 Received: (at 38181) by debbugs.gnu.org; 17 Nov 2019 18:15:59 +0000 Received: from localhost ([127.0.0.1]:42550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWP5b-000474-7d for submit@debbugs.gnu.org; Sun, 17 Nov 2019 13:15:59 -0500 Received: from mout.gmx.net ([212.227.17.20]:57927) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWP5Z-00046p-Me for 38181@debbugs.gnu.org; Sun, 17 Nov 2019 13:15:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574014544; bh=5D4Zoc1sgeO/OGr0wI4OiEE6A3LuSNSTHzErBgBtqs0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=QPOFTZYCTBR739csauiCgN4XE1wN1pZN/FaQY00qRpUeOKldYlIV5Rk+GKJmQbOD5 SjxZSc8+hXE3/Y5N51mow6FZWo+82dZqvf3+AHEpBFOH6SA6mCJFwW7yf632k8b/s2 tpj2r6z3X5v9YtgQQYR1W3lOoE2rVCLpM91puUTM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.100] ([46.125.249.38]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MJE6F-1iHL2p0o6F-00KgQg; Sun, 17 Nov 2019 19:15:44 +0100 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii 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> From: martin rudalics Message-ID: <17cbad77-efb8-9e9e-9a14-99e2e2bc5782@gmx.at> Date: Sun, 17 Nov 2019 19:15:44 +0100 MIME-Version: 1.0 In-Reply-To: <83a78u5s8y.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:5kcSupGYz/jipbUFDFRlS9Zp/RtMG8gRdm6714peSnvT9MGfQq6 +xHdigUMjio1fVMN6dgGLface0hQuYX754oUXapa6DPxTJ31metuRg1DFkZgTBpHRxoF805 H2sXq1Un0hwRerT+sP2S0g0XhNqJfQ6Fc8bilKnIcJar5h+E/Ea2W9eXGZOdZhhtuV7/uJx cGuVMwKNx56w193qrkJUg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:tuiZwnASH68=:M6wnvZir9LcE6qcLgyCxSg k2TfZcGudOADI7OkffkJ95JgbzpY5nLvaCbkM0qGViJJLPtcSCb6mOyyS4IhHQubX6yHCbPrO p9FPg7IFVLyhboKiPebBbQ+e/P5u482Q7NPKCpo2Ov5qvVKKjnpAW0ogf9mKogsIeWLesU1IG a4LZ3370+hnvaaycCsH9bYQ1J8I59QQmQEkMsT5rGkm6E0kM2W3lyV2tWOuQDFLUTkIbuKnMv 6hyzZ1jnxZ4gKaJQ5lfeZRM72UWOG8xNEFI8GVblXjCG5VknuKkrmndusXAMFtak2sa1Ub7nF d/TvwIIscLP1RgtfpdiJoNjN5VFhESudOQNAR/q5XbsKLmUd8SsvD+J2bX7Y8EDAedtigLrLm g7h9CY/NRHAl4E4I3edPcI0qgBoPoZ+E6GTJXkiCJ2SDy2xxhI23w1ZJy8bYIwmhM1A7g6Dzn zzBMCCx0Type0BaYjMhDtmVgb94NjneeQU7krl1OsacpWI2UIlnehID50we/2CgVgDuX5TYI4 XSuLpWJ2kVikTHyEZYL+/BEpyU9ZvdikBi+hm2QtsfYW8i70s0f7jS1jQZtcSUGFmSynkcc3q Qy6tP77zRQyndTJsm+BF3JE07ItVgGTYDHH5Isa2oRl+4gnuaZL2NpF/nWkQXCWo8jZqxg9F9 blLsr0zT/8xGywbYMXL/aX4JE5rFyGaqrRVQ+ULmO2gt3OaNN07uWFtyjMjU4vIL8BOBMT0II zN7iCOksIGT3he/MXdR3qu8QMHGRCVkV+Vkr8p0AlEP9w0WRPuVg52r7ajYO+3qEAUGqYA6ic CCC4d0v6JfELY+C8r+pzahCKjY2JSmpBF9SoF102EJx6aTvJtDHQu9zqpu7peTTNyeQzFeI3S g2y6llVps5PPEkTeopGqhxHm/7AzgKxQAHKfwMqfb5DbB2uiPzeISg3Og4OgkRCFHpk9j42EQ xidyvw6Ic7fVgQz38ZhbXfkFQoSEoPDEBYVZiZK8qT7FOQS4qtep2q1wBl4OIpETXHP92a8VD DBiLJtb0xHqgSHs1ZkhAIEbElZCR0D6MjU+TZIc86WeCHWlXz1pXCx7Eiyt0+mJPuwzAnQVox zH/FNuOJxUzEiUEJOAe0nFxk5i9xgd4ASZ19uL006JnG0a2uFN17Q5HyUzEhD3fY/inJq/IV0 S2Do0ejEzETKb04Ae7ONKSYqT+QTX4eSZuSmaLY5aJdaZvEMnkqJ6QF18wL1rC/wtgQjJ9sii 4zRAuvqzaHPETsFQStWsPJmCpAxgGSjPRoCU2cQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > I didn't see where fit-window-to-buffer looks at the height of the > mode line. What did I miss? 'window-text-pixel-size' does it (triggered by the sixth argument MODE-AND-HEADER-LINE non-nil). > 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? Possible, I think. If we pass it on to 'window-text-pixel-size', it wouldn't even have to be Lisp-callable. Still, it will penalize every =E2=80=98fit-window-to-buffer=E2=80=99 call (without a redisplay, though)= =2E martin From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 13:21:55 2019 Received: (at 38181) by debbugs.gnu.org; 17 Nov 2019 18:21:55 +0000 Received: from localhost ([127.0.0.1]:42560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWPBL-0004Ge-Ec for submit@debbugs.gnu.org; Sun, 17 Nov 2019 13:21:55 -0500 Received: from mout.gmx.net ([212.227.17.20]:35155) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWPBK-0004GR-5i for 38181@debbugs.gnu.org; Sun, 17 Nov 2019 13:21:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574014906; bh=CGkocnsRVG5+T5ekQSgp4mSsatN0B/8NWwbgNu1Q+7M=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=WPXys4vFSAbK1ANblOfbG5uj/04nX+bHZ6/eilgyi3bjJd6hkguS8QpGXfU2OVewM tWh082iBzEiLrbfLZ3kCPeEauXRED6HzE4oU6osRnG45y4NnpvJ/MmlBx7JeG/IeuM +LX3SWCVcMtUD7BF3SvuMvBmFXWCWi84LhIZnAV0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.100] ([46.125.249.38]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MTAFb-1iRGfT3XKh-00UYCb; Sun, 17 Nov 2019 19:16:28 +0100 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <878sofon8v.fsf@bernoul.li> <837e3z7pzo.fsf@gnu.org> <831ru77ghg.fsf@gnu.org> <9700fac4-b75d-cd6e-3360-78bd0f8c7db0@gmx.at> <83blta5sep.fsf@gnu.org> From: martin rudalics Message-ID: <5db0ddbf-7473-ca8e-8279-7f8435297771@gmx.at> Date: Sun, 17 Nov 2019 19:16:32 +0100 MIME-Version: 1.0 In-Reply-To: <83blta5sep.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:jxdhMrZ9ORwFcOsazYZnqxdn3BnZgux0tNlpoW0Ha333BW2Aqhj fW/XTIyMvT4vQ0qlafGUA3znOTWU9NG/aIfHBIMKY46KjWccJkqkvgskkhCgmUJ2imFglgp hhO70pCiCWyEQYLnP/nLHmDaRKb1s9MxRlFTf3E1qxXHEpcM1qANkVyHTJ68JuogXFqFqlk 0+yy+t3/St2A3MfVGSVew== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:VN6dN/I1QHQ=:Z9OGC/KMYL3XsuebFT9mLK lf0lTU8em+rqNnxRXK5wSXXSew1dDW4c51oiTiJA3HBSzfSuoNPGB1a3fR4TSnuztL2wntjMO f3nz1AGf6RG10ioHBvvXCLRJ3QmFZrdqu4Mm0jR2cEu/tVhWZs2ENTPTStMFD0w0Ccfx9J6ye O+zRq89B6AaRconBEZWnWpjijj2h5lrpUVV/SDdJsjkI7WcrHFreOaDfm80UTvHL4yW5ngavQ kF+uzUXJthHd87IPaEal1E4BfVSYW+6ZEp6EpbsKafUVNe/4r5HHD42cu9BjUkD6q60cTGh8+ NQy80wpx5FeXUz//b58qLaYz+dCLoxnDAEkluvTey3CA1R3WmHKWEId5DWi0fxa/HFnuD+5oc l1m/XIwUnk2UfB2X63SiMisViGdhpOCX7wghbt1SH1nCCYH7K3jyah1u384asVPMxMvxD+w2R LDms6UuUjw9x9xHt0eRWM8StbIMZIGbM7iCas/NwUQEmzCDl/87E97uGi2NY7ZNfeCM5+frGW GJ4bG1B04Y9oKf/KWCkYs70fdpigxhodEA1knHTTdQZeak/20rMtc6vj2T3mvdFekF9NKgmGP wPdp59cF57maDgXtAtlCZc4jiNzKZ1uFSbbVZEp70roQn3oB47fiGpipxnETNwQNsgkbqjxU5 MmTxYKSmHiY1n1ffOetk6TAOtyFbgo18DweMhUYFzAomCovuWgCoQLU9L6Lj+HdopI1RY+P4B kYySkf+/Klgch/1iOeZ1wQ6UZprfprW38uXi8hCYlg94dT39AwH4qc1Un2TbS6r0wMwb3SbKi ytW0D6Dx0P2ZkLksBvqd2bxPsDpSNR0v5/kmqdLin82qlunPEQTtHqT9MyJsbo2JrAjfLyzWs 0pZWJYNQZIR00t9FvlcF4FrO+iVYOSMhIg1C+Gn2bdkenj5PBgVKcyqDcbTJSIXwTAR+ebDf0 f+g807omW0LeGave3aBZQzMQu1MgE191JkC2m90habUcv0MoMwerBGBIWSpzx5Qac7Kffa7Xd iCDNikUOv8c57JSkGigyFydhMQqlPElRE30zXg7iOFjlXtTFq+vFCO7oGJH4eWODJua0V3eeq OQnnrV6wyhqYiB8n7kyiM7M1LT04eA2Vk+ccmrT3Fzxsk54u6Z+/TrOyzPwOc9hx+i7DhfLDX KCOgEGF4+44BuSJeowKqO8GbFxJpiJTfNJ+IAidK7yCwpVSq8/kBwbuPdRzsTJtPh1CgQ9Xwm moQS0RhJtlVCOozyKGqmU+1TPYW25Ef5ezl4iJ3JHNStU+YfGQfqTmzxwExY= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > I'd prefer a hook, because the problem probably isn't limited to > fit-window-to-buffer. The display engine has to be able to ultimately control the behavior to avoid ending up in an infinite loop. Hooks are dangerous (though evaluating the mode line can be dangerous too IIRC). > Wait, don't we already call window-size-change-functions in this case? > If not, would it help if we did? That's precisely what I would like to avoid. Note that we do not re-run window change functions when they, for example, change the size of a window. Such changes are, in a sense, lost to the next redisplay cycle. >> display_mode_lines sets refit_window_to_buffer to 2 provided it is 1 >> and the mode line height of this window has changed. > > The detection of the change in mode-line height is outside > display_mode_lines, see the snippet I posted up-thread. Right. It should be done there. >> The display engine eventually calls 'fit-window-to-buffer' for all >> windows that have refit_window_to_buffer equal 2 and sets it to 3. > > We need to figure out the "eventually" part. It should happen after > the windows have their dimensions updated due to the mode-line > changes. Do you know where this happens? Nowhere, hopefully. Managing the mode-line happens in the display engine only. Note that a function like 'window-text-height', for example, detracts the mode line, header line and now even the tab line heights on-the-fly from the stored pixel_height and might even use estimate_mode_line_height. The stored text_height _does_ include mode and header line. >> This might be tricky for windows stored in configurations and states. > > Why tricky? A stored configuration shouldn't be affected by any > changes after it's tored, no? When we restore a configuration we probably should nullify the bit-field to avoid unwanted re-runs. Or not nullify to ensure re-runs? > Mmm... actually, it could be that we cannot resize windows during > redisplay at all. See, for example, how resize_mini_window does its > tricky job. We may need to call this outside of redisplay. Inherently, resize_mini_window does what 'fit-window-to-buffer' does and it gets called from redisplay_internal. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 13:36:06 2019 Received: (at 38181) by debbugs.gnu.org; 17 Nov 2019 18:36:06 +0000 Received: from localhost ([127.0.0.1]:42598 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWPP2-0004da-8X for submit@debbugs.gnu.org; Sun, 17 Nov 2019 13:36:06 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWPOz-0004d7-Tj for 38181@debbugs.gnu.org; Sun, 17 Nov 2019 13:36:02 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38496) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iWPOu-00081I-Cy; Sun, 17 Nov 2019 13:35:56 -0500 Received: from [176.228.60.248] (port=1115 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iWPOt-0001vd-Eu; Sun, 17 Nov 2019 13:35:55 -0500 Date: Sun, 17 Nov 2019 20:35:55 +0200 Message-Id: <83v9ri4agk.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-reply-to: <17cbad77-efb8-9e9e-9a14-99e2e2bc5782@gmx.at> (message from martin rudalics on Sun, 17 Nov 2019 19:15:44 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account 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> <17cbad77-efb8-9e9e-9a14-99e2e2bc5782@gmx.at> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Sun, 17 Nov 2019 19:15:44 +0100 > > > I didn't see where fit-window-to-buffer looks at the height of the > > mode line. What did I miss? > > 'window-text-pixel-size' does it (triggered by the sixth argument > MODE-AND-HEADER-LINE non-nil). Thanks. So the only thing that's missing is that it should call display_mode_lines, and then look at DESIRED_MODE_LINE_HEIGHT instead of WINDOW_MODE_LINE_HEIGHT? > > 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? > > Possible, I think. If we pass it on to 'window-text-pixel-size', it > wouldn't even have to be Lisp-callable. Still, it will penalize every > ‘fit-window-to-buffer’ call (without a redisplay, though). Why "penalize"? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 17 13:39:27 2019 Received: (at 38181) by debbugs.gnu.org; 17 Nov 2019 18:39:27 +0000 Received: from localhost ([127.0.0.1]:42602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWPSI-0004i9-TA for submit@debbugs.gnu.org; Sun, 17 Nov 2019 13:39:27 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38561) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWPSH-0004hx-Ha for 38181@debbugs.gnu.org; Sun, 17 Nov 2019 13:39:25 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38556) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iWPSC-0001hd-Cn; Sun, 17 Nov 2019 13:39:20 -0500 Received: from [176.228.60.248] (port=1322 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iWPSB-00021U-Lz; Sun, 17 Nov 2019 13:39:20 -0500 Date: Sun, 17 Nov 2019 20:39:20 +0200 Message-Id: <83tv724aav.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-reply-to: <5db0ddbf-7473-ca8e-8279-7f8435297771@gmx.at> (message from martin rudalics on Sun, 17 Nov 2019 19:16:32 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <878sofon8v.fsf@bernoul.li> <837e3z7pzo.fsf@gnu.org> <831ru77ghg.fsf@gnu.org> <9700fac4-b75d-cd6e-3360-78bd0f8c7db0@gmx.at> <83blta5sep.fsf@gnu.org> <5db0ddbf-7473-ca8e-8279-7f8435297771@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Sun, 17 Nov 2019 19:16:32 +0100 > > > Mmm... actually, it could be that we cannot resize windows during > > redisplay at all. See, for example, how resize_mini_window does its > > tricky job. We may need to call this outside of redisplay. > > Inherently, resize_mini_window does what 'fit-window-to-buffer' does > and it gets called from redisplay_internal. And it immediately returns if that happens while redisplaying a window. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 18 04:45:09 2019 Received: (at 38181) by debbugs.gnu.org; 18 Nov 2019 09:45:09 +0000 Received: from localhost ([127.0.0.1]:43183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWdam-0004yv-It for submit@debbugs.gnu.org; Mon, 18 Nov 2019 04:45:08 -0500 Received: from mout.gmx.net ([212.227.15.19]:53837) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWdaj-0004t2-VJ for 38181@debbugs.gnu.org; Mon, 18 Nov 2019 04:45:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574070297; bh=w93Pvvq1MNmJPHCFEMV9vdi7GZstcoKn92mUD7UVMGY=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=X852GiIfVj0SsIakvftLKdlec0Hlb0SVMMoo0N+na0XZ2XgR9Jf1vZnk5xufdFjuj LK6kIu5Srzoo1Dpv+DlDdPbAkuabL+txvcEczQWZ1gYJ82VUfpqPGNCJayNraAGnCS vU1JL0MyVp3MUULVUKNYNW6iePW/Z2WTTt2WArQg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.103] ([212.95.5.110]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MI5Q5-1ibqvO0291-00FEtx; Mon, 18 Nov 2019 10:44:57 +0100 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii 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> <17cbad77-efb8-9e9e-9a14-99e2e2bc5782@gmx.at> <83v9ri4agk.fsf@gnu.org> From: martin rudalics Message-ID: Date: Mon, 18 Nov 2019 10:44:56 +0100 MIME-Version: 1.0 In-Reply-To: <83v9ri4agk.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:7scP1lg9YLRJzvMqPl4Gdcg5syVKstVmNlFJ5XfaK7+kyn1Fj13 6VTb2IFOd7O+49sqxEpCiCcTBg6U2tdZB5jhkXazRbhQtmU7n4WU2aeGq7AjcfCrUWiCNyi /ydYOivEKyWQxH83MQnc0hv77ETD8c9wx21EwiH1KZIe502o6R/rG6rYWYg5m7tkDpnaTwk v6wVU7qdAm+tOKCR3JMZQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:xg+2UHIPtY4=:mIFg7vIwd8iZrunOGpy5a7 QyUhn+pOHYei8v6z9TcVXGV20YRFIVsvET0g2SUXnDaSR/z++dQwVJyReGDTLyg1fQMd+B8wv WGYU5DRzKtUyiaQqNrB9DaOUDzu5Mi3gqCoQFXGq0hzfirqUHLYSX7hiYleIqGUPl3d2kk+lB CvHRlZyset3NSEmpUZQzCbdnfAEUWxionhC5myoQi/wegqOWg2wlZPAsVlh9MEbdRANpLmgAf /xJSg0XtjwVV8OWxi4OEbFYx1jXn3L2CGUPPuK3akFwUeY2pkip7+5KzHvUFI1CRPdCUvpFyU VkpHedq35ZC6WKqTU1DYe373ViM4ENZ6F8D3yx5xiw17DLxA/F17d37z59SHAQl8SGMf4tT7e J1UB3Jz0ipsJWrRlNw7Gx0OzfgUUCsB5rg8n+QcaCX1QlmTOOZlvFD6s/puhEixbBMtLMe2JM gS+98gCfmXmjQPlNOcqZELjTsfZv6pX2W4zoGd8WD7YMYbzDlIJzwVtj1yeQdwyO+QiqRSNWh MeaRxlIxDzZc2acUD3JcQeRDSyEoHHsbVdmpbZFQEest4Hn01kW1aLqoIGzTko+V3FtZMp01g iaSvEJWLZAeD5X5uBz2qJkDMEB9aAczLtHUCfXErRDtFdnrp5YQl2eo/W66yGS5UlNNm5pV5p +UlLcysFVPZpcTZpTk3xaZceVSVAzYyJlnWiHSSNQZfplI7vQrMAF4NIewhsqZ0nGYMGYdvvo E9Pmfyz1wWVIX8Vu0eyXplhWv3Zq86CCBhop9pYL0G0tIe0dmcNmpsPit5nk/qsetER1JORdx bEwq0P1azzgM+ZAx2maQwUYVN6BhL0aR3AzTBYCtucieyplSXdjOKt+tfUtXEZfK5JMnZtC8i Psxr+J52gsLC/np4y6GQSgbmsCzCwlLfdE4N7o0pLn/USKR6CZO+iloxl3UMoC349lUMWMJks mWsq7oiI4Yhs1NtVOHIucWKyGLGrRaQ2GcJleNzTJkdZWQWysji+7h1cEGtD6JIsPNCzjtwIV AI6O3PwBwF/SK+99BGv9sb5vcp65WyAq0gsjOngmhp+t0PE851MjG+SPMwhhVIK3NGU6etBjT hbLeLR9uyQFbiXnBrl9kFkKD8spv1BFc5p3LoQ13rSdCoEhjbLu+fbcxCU9H+H5tYgJSc8YS3 C0EjO5xQamZlzT+mGOIhppoARg+tmVzo6xdiUiy4JFbefujJl2d6N41k0yaHPcPH6nJQFEDux 9TiSQGlKw283RDB937KYGnYTmg7PCxlEk49zEkC6E19x0/qLWiVKuM3k4Tmo= X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Thanks. So the only thing that's missing is that it should call > display_mode_lines, and then look at DESIRED_MODE_LINE_HEIGHT instead > of WINDOW_MODE_LINE_HEIGHT? I suppose so. But please always keep in mind that the window code does not handle problems caused by specifications in the mode and header lines immediately. For example, it will not auto-resize a one-line window when its mode line height is increased to more than its text height. Try with a one-line window and Jonas' (set-face-attribute 'mode-line nil :height 250) >> Still, it will penalize every >> =E2=80=98fit-window-to-buffer=E2=80=99 call (without a redisplay, tho= ugh). > > Why "penalize"? Because 'fit-window-to-buffer' now has to calculate the mode line height which it didn't before and which for the majority of users never changes. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 18 04:45:20 2019 Received: (at 38181) by debbugs.gnu.org; 18 Nov 2019 09:45:20 +0000 Received: from localhost ([127.0.0.1]:43187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWdax-0005AD-V0 for submit@debbugs.gnu.org; Mon, 18 Nov 2019 04:45:20 -0500 Received: from mout.gmx.net ([212.227.15.18]:55057) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWdaw-000546-W5 for 38181@debbugs.gnu.org; Mon, 18 Nov 2019 04:45:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574070310; bh=1ZTIkTQTrmIz7mc4S3IGQEuOS9uy2V233iJpyuu+m8g=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Znshcr3XCGa1iJ5OYdXOn+W3x2ztc06SRlL2pcAajpCAP1vrDQWAzeuDEDllTDOEm AiQAJfk0576x1qZFBObtZHWLRzAuN9UbmEr9NOoUVuhUqh9gPxim8RjHIYPomxzx8a 8mhHZdyd7smldpjmJFhIAQ1bp1N9NwFzWqgvm6QU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.103] ([212.95.5.110]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M4b1o-1iXC5Y1QZi-001kcf; Mon, 18 Nov 2019 10:45:10 +0100 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <878sofon8v.fsf@bernoul.li> <837e3z7pzo.fsf@gnu.org> <831ru77ghg.fsf@gnu.org> <9700fac4-b75d-cd6e-3360-78bd0f8c7db0@gmx.at> <83blta5sep.fsf@gnu.org> <5db0ddbf-7473-ca8e-8279-7f8435297771@gmx.at> <83tv724aav.fsf@gnu.org> From: martin rudalics Message-ID: <19634a53-d8a2-0e85-bfd8-2cd636c6ae3c@gmx.at> Date: Mon, 18 Nov 2019 10:45:13 +0100 MIME-Version: 1.0 In-Reply-To: <83tv724aav.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:WxnLZtSTOMPicXoJKcglJZtFjC2cDKimvQhI5n+yUc6Y0fnEHa6 FFsIbjHMxyZMg1gscv8f6khvy18VDsIMQp+XUJceKCLVQlGtf9QkiZ3MqzZVqxvC+joa6Ga HDmaOnyICdI5dH7fFfYmV+1kGpTh/Cvf84zM7ep5BQ60KlY81KXF71qcNgiv03Fagg4letF /XVigPiHJ+yCe4rlKg2ag== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:ZEpkBxMrwV0=:BB4K9olCo/CmC0UwT+bTVG hINfgZB1/Kw1qXvWJaD5mRjHapPvZ1tYXpx+fdwZb4iZRdcTx5vLsTpOSa/fAEnd0elLYd1Ve /DO3yffgkdaLORtB8bItNmXbqk4I+ARe5LUX5Y+Eo1rwxvOrwfBDyKZV8aiiMtmkMzYFZwnrZ ApRluP0gEFPR8B2ze9fHSfMK6gk8cZe2bSgnlQbxFTyRZSL58+wyQhFmAzW7nVD4IswrOicW8 g+m21VYzgYITuneqm34TRFSsU1Vsa6OE0E/TVFsFtD2T2SsmBXzWPp7AT+gRBOUEqndlqqvRJ ZofSIC+57Cc1pyfi/vAUpRUr8pYtgxNsc4Qx6UCRxKDPO4O+FOz+jlLuYkftPly4hbkSik++o r+kZ8T25+A3e/A/2k1yuZlYJKSNHErKI/6ERWAZ4G/RYqowDmy4afyJ/T8u+VfxB1vJZAjVSI g/6T+FYbkgi7fHtge3eh9lGISwNH9f4PC7t25Wr+F+ntCGJcQW33jkR56J8GtkG74jvC5sAkM FgQ7OYwDftGxOlr81qyltNQULuAER76NBsily9CTNCh5Xz5w1GozAEyNDmotpiaAKzESk+/nY ZK3yMnJw6hnEzQwskrfQv/lo8XOxWCO3KH460BIXUprq3SpQ2mr5YUvGd4tIS0FnnWWFR3E0F CFZpN8TAhl6J7HJOvlD8G56eXqa2b+YVxVJq/H8wu4apLUG1l0SyvzeuRkdAMKfmySOtLz1he 0ufahbNtMII+y0dNEPrQYHIKRVrX/2jpu1EPXoK+ntm2GogEKUHAy9KoPltl8C5C2fynRl8af J1KMIksC97f4PDsSf38R9bNTQkhDHgQrsL9XyKkRwN+WsmQXKzL/sXrl49JfjdjbH4uiVdb/b dt230IR7M0Oy4lcezZ/spJDIbs+T/1d2yzdJ9AGoiJ2q8mF31PxSePH2k8s46EJUy71cgIWp8 REuBsq75hZfCqhd95ASH2t88ZgAub3zuJE9s1pigYScpJlPDxqVBPDI0L/HACf2p0n4ttTVT5 MtR2hsrnrzzGwMAW8o1pyX7MeZIXM/5sfSJRYtH6MEmXCGl+12qzmFTVuvaYjrJrxrhFZlV7/ /eNe7NRshAglvePVbAAevuavj0TYgooGlvNcNiNVYb7W6dFGSw8boaozwNuuoN4vhTShrYStz 6DqBm9ZzfbPuEbipLWrw+1JDLSTuulqlI3VjIbEqwzT8NtKsqVeeR8zrnHH3HvgLLzwV/MqtW +Yz8uwUXfFmtlEN/cNteilhMW/XvrWm/ijKiFJA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> > Mmm... actually, it could be that we cannot resize windows during >> > redisplay at all. See, for example, how resize_mini_window does its >> > tricky job. We may need to call this outside of redisplay. >> >> Inherently, resize_mini_window does what 'fit-window-to-buffer' does >> and it gets called from redisplay_internal. > > And it immediately returns if that happens while redisplaying a > window. But IIUC in neither of our proposals we would have done that. I'd even say that we should resize windows when redisplay finds out that the mode line height has been increased and would obscure the window above, not leave at least one line of its window's text visible (see the example in my other mail), ... martin From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 18 10:43:03 2019 Received: (at 38181) by debbugs.gnu.org; 18 Nov 2019 15:43:03 +0000 Received: from localhost ([127.0.0.1]:46083 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWjB9-0001ab-GP for submit@debbugs.gnu.org; Mon, 18 Nov 2019 10:43:03 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59107) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWjB2-0001a2-5J for 38181@debbugs.gnu.org; Mon, 18 Nov 2019 10:43:01 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iWjAw-0003WG-AM; Mon, 18 Nov 2019 10:42:50 -0500 Received: from [176.228.60.248] (port=2437 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iWjAv-0003wB-H2; Mon, 18 Nov 2019 10:42:50 -0500 Date: Mon, 18 Nov 2019 17:42:53 +0200 Message-Id: <83a78t42de.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-reply-to: (message from martin rudalics on Mon, 18 Nov 2019 10:44:56 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account 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> <17cbad77-efb8-9e9e-9a14-99e2e2bc5782@gmx.at> <83v9ri4agk.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Mon, 18 Nov 2019 10:44:56 +0100 > > > Thanks. So the only thing that's missing is that it should call > > display_mode_lines, and then look at DESIRED_MODE_LINE_HEIGHT instead > > of WINDOW_MODE_LINE_HEIGHT? > > I suppose so. But please always keep in mind that the window code > does not handle problems caused by specifications in the mode and > header lines immediately. What kind of problems are we talking about? > For example, it will not auto-resize a one-line window when its mode > line height is increased to more than its text height. That's a separate issue, isn't it? > >> Still, it will penalize every > >> ‘fit-window-to-buffer’ call (without a redisplay, though). > > > > Why "penalize"? > > Because 'fit-window-to-buffer' now has to calculate the mode line > height which it didn't before and which for the majority of users > never changes. Is that a significant problem? It's not like fit-window-to-buffer is expected to be called in a tight loop, right? Displaying a mode line is no more expensive (actually, even usually expensive) than calling vertical-motion to move one line, and we would never think twice before adding a call to the latter, right? From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 18 10:46:29 2019 Received: (at 38181) by debbugs.gnu.org; 18 Nov 2019 15:46:29 +0000 Received: from localhost ([127.0.0.1]:46087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWjES-0001g6-3G for submit@debbugs.gnu.org; Mon, 18 Nov 2019 10:46:29 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWjEQ-0001fu-7i for 38181@debbugs.gnu.org; Mon, 18 Nov 2019 10:46:26 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iWjEL-0005uj-2L; Mon, 18 Nov 2019 10:46:21 -0500 Received: from [176.228.60.248] (port=2645 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iWjEF-0004FC-2e; Mon, 18 Nov 2019 10:46:17 -0500 Date: Mon, 18 Nov 2019 17:46:19 +0200 Message-Id: <838sod427o.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-reply-to: <19634a53-d8a2-0e85-bfd8-2cd636c6ae3c@gmx.at> (message from martin rudalics on Mon, 18 Nov 2019 10:45:13 +0100) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <878sofon8v.fsf@bernoul.li> <837e3z7pzo.fsf@gnu.org> <831ru77ghg.fsf@gnu.org> <9700fac4-b75d-cd6e-3360-78bd0f8c7db0@gmx.at> <83blta5sep.fsf@gnu.org> <5db0ddbf-7473-ca8e-8279-7f8435297771@gmx.at> <83tv724aav.fsf@gnu.org> <19634a53-d8a2-0e85-bfd8-2cd636c6ae3c@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Mon, 18 Nov 2019 10:45:13 +0100 > > >> > Mmm... actually, it could be that we cannot resize windows during > >> > redisplay at all. See, for example, how resize_mini_window does its > >> > tricky job. We may need to call this outside of redisplay. > >> > >> Inherently, resize_mini_window does what 'fit-window-to-buffer' does > >> and it gets called from redisplay_internal. > > > > And it immediately returns if that happens while redisplaying a > > window. > > But IIUC in neither of our proposals we would have done that. I wouldn't be so sure: the code fragment I've shown that detects mode-line height changes is inside redisplay_window. > I'd even say that we should resize windows when redisplay finds out > that the mode line height has been increased and would obscure the > window above, not leave at least one line of its window's text > visible Some might dislike such side effects, I think, for the same reason some dislike the resizing which happens due to mini-window growth. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 18 13:46:08 2019 Received: (at 38181) by debbugs.gnu.org; 18 Nov 2019 18:46:08 +0000 Received: from localhost ([127.0.0.1]:46251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWm2J-0000cq-8p for submit@debbugs.gnu.org; Mon, 18 Nov 2019 13:46:07 -0500 Received: from mout.gmx.net ([212.227.17.20]:55603) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWm2H-0000bn-7C for 38181@debbugs.gnu.org; Mon, 18 Nov 2019 13:46:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574102753; bh=mGOEcaY0c52cQGDHOannbGcHXvcqTK0aLIgiuc2YVYo=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=csVeQ5rSBfzJC66SeMARGJxz33xargV1Qzz+x5O+6D7VtVaO1/PousYnHlG3jW7+s S+dfRH/cPO5lYvIyW7/gxRu4VMZiOUmtROGFle5sfdrVKsjJvDA8qEoTOHtv+MYQXK m/uWYJ41o9pSZ0YIPyTuxPSo2mM4tY8rHIJmS7j0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.103] ([212.95.5.110]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N0G1n-1hcCuM2PAN-00xIR9; Mon, 18 Nov 2019 19:45:53 +0100 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii 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> <17cbad77-efb8-9e9e-9a14-99e2e2bc5782@gmx.at> <83v9ri4agk.fsf@gnu.org> <83a78t42de.fsf@gnu.org> From: martin rudalics Message-ID: <792e250c-07b1-60ce-82d1-596b1db2a3f3@gmx.at> Date: Mon, 18 Nov 2019 19:45:50 +0100 MIME-Version: 1.0 In-Reply-To: <83a78t42de.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:VpmP/5mdChYOoCj40RzTvAfL9r8axLJ8F3wQlqwySjK39gNjOSJ tE4QsvvYCZXaYCfpi3s+7o518IvHuudPqIuuGU1CDjr1S6fF0m6+vVAkS8CMIL/WSfCJwHv yXzYrNnYJ7jD2A3F5hghwZLB9TDgfHHjyiO18p0gK4+EMOoiFkGqQsYBgGxVyMPJYK2e9WG uXWqKEUcofVzHlhcibxRw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:gulK8y03TAY=:jT9pKBJzepuquCFDKNf1in W2JobsTpGn5SoDkFpaE/ZJDvciqkt/tx1yaAArYxuf+OiHmusfXhA7tNb2CrkW8f1WEjud+sq tYmXSIMQZDl012F3hqsKkwNxim5waabmDXKYe4Rv6w1LTf3olfZ6DSroae68r7slkF3WIWhzk fjhyCShL63xqnI+Mubs+hhp7z1NOYuYXaxmU8p7N6xAiwEsGCGUxcj4Q2+vdUs32N4InuL+My K8pQpR1qqK6K7qtg2HCf6WuicafAxI1Qko0IBY14ZXQU/hq24g5h0aYtdcD4PJysxZAsUVj9R kyjbeaXYeJzfcQ6CGINoQ5X7IkRGHRZYzXv3vrXpFdKI8Ev3t4EaBxb6vTtEEHrFgR8xL+j7A KnDw7x738jxT8tCMEqQOpFSfXwY278opcLxaW5hX1pQr7grvSjQhI3/B+SQvEhXpCdLPcGRjE dcQe0/s/km+goLsTo2jsgCIf0fVOMekkQFt+pa2m+2ID3AeuHy0l78y3DNBBn2SRMuQAWuGVI f3VyJ5Gi6dhZn+lkvTE1leOkF89xjQYPkfOyQbNw/AEbNMrpekQIzQKRIb+pM5ANyzCbKSruN Q+Ue1qgngmv366yTs2x+TlZ54pxqO4uabpVRMukhQXocRQ3G+Bvi9MPqPI1n7n3USAXXMwfZ5 eFzYShL6RiC1z/zGhPxEEbFtl92Ync+xfK57ig1KhBlW/QszcrPHJtlmT8Fknffi3i+h4DhzG j37Oi3y2D9+lxFsu3LjgYRQqzFADkBmANQKusTSM1txkQNrPm/qEBZ5BzT5LlKL/Owc3AVNz9 2ABcU022NmxGuPDqjgMqxJZWlfWOmfF1vuPg1vJy2eh934QdzZX9fle+WzzmIl2+YMUjWgELa 4nuOa0dZrDFDNAH2/JtubWdKT0PTvcvgOn+YkL5q1etNNy6b9HDyZxYNkwpclX6z38hHLVnb2 gaY/VTVvX4FkirFRFSSfrdck72+xJ46NZQzlauZIvdwuIMmf6nbQg5d/h624gysCL23RfVlA4 a4UHimTStu4dod570GzXqZGTDTfrSGUJaWqrnaKPmzGzUxtvZmHUm7RpA17SGHROrMjZri5hH lBRNbTxBqEe/NiiNSdfU8jwx0P0CpOIoSCULH2WM4TrEL+sKpMB20WS6/1xxLZIjtInYn09ev TB2ltVuwkji2mtpH/tYbqAKdZ5vRJ3PqIsWAG5F2rKQHGufHj+WV6O6wvAunM6uf9xHlEnI4p ainy46hnkzTXOdtepovB371kBbnFZ7oT6lvEm7kN8+FG0znWK+X94OjU6Rcw= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> I suppose so. But please always keep in mind that the window code >> does not handle problems caused by specifications in the mode and >> header lines immediately. > > What kind of problems are we talking about? Any problems with the minimum size of windows as the one described in the next sentence. >> For example, it will not auto-resize a one-line window when its mode >> line height is increased to more than its text height. > > That's a separate issue, isn't it? It's similar, at least. The scroll bar issue is another similar one. >> Because 'fit-window-to-buffer' now has to calculate the mode line >> height which it didn't before and which for the majority of users >> never changes. > > Is that a significant problem? I hope it isn't. > It's not like fit-window-to-buffer is > expected to be called in a tight loop, right? Displaying a mode line > is no more expensive (actually, even usually expensive) than calling > vertical-motion to move one line, and we would never think twice > before adding a call to the latter, right? Agreed (I suppose you meant to say "even usually less expensive" above). martin From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 18 13:46:41 2019 Received: (at 38181) by debbugs.gnu.org; 18 Nov 2019 18:46:41 +0000 Received: from localhost ([127.0.0.1]:46254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWm2r-0000da-46 for submit@debbugs.gnu.org; Mon, 18 Nov 2019 13:46:41 -0500 Received: from mout.gmx.net ([212.227.17.20]:48283) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iWm2p-0000dO-4b for 38181@debbugs.gnu.org; Mon, 18 Nov 2019 13:46:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574102793; bh=Q5gjJmZjJqaaNDuLdFDT1qlqku4hknq17Rf2/EzqsUg=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=NkdCFdRbsGfD49IRny9MXc5yLs8/DgfRIP5nwaxUiJK09Ek5d5d1J4VdiBcd2wwYi danFMl6U57sf3434UfK0ZAadfUpK5V9e0K+V4acLVqOpu37exebs/ETmHS7Q69txVQ yWc1WpDUfkBknDMEDG43fk2eRfqZty61qkn88fQM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.103] ([212.95.5.110]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N33ET-1hs7C14A7p-013Jd6; Mon, 18 Nov 2019 19:46:33 +0100 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <878sofon8v.fsf@bernoul.li> <837e3z7pzo.fsf@gnu.org> <831ru77ghg.fsf@gnu.org> <9700fac4-b75d-cd6e-3360-78bd0f8c7db0@gmx.at> <83blta5sep.fsf@gnu.org> <5db0ddbf-7473-ca8e-8279-7f8435297771@gmx.at> <83tv724aav.fsf@gnu.org> <19634a53-d8a2-0e85-bfd8-2cd636c6ae3c@gmx.at> <838sod427o.fsf@gnu.org> From: martin rudalics Message-ID: Date: Mon, 18 Nov 2019 19:46:30 +0100 MIME-Version: 1.0 In-Reply-To: <838sod427o.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:IpduCTlbom+lX+bMtKXFk5yYcpiZ7OjQMxclhm2rc3rz6EEKWKe JAXRyvIKmQEi0X6oGtKV/mICDWgp4uERN9uvybhSYg+wSEjBk0KPYfg3Pv6ud8rvBl+nfbG suOhG5pQNd0ELpeTiheSZZp3kkCVXdhYemzaPLc7PXijm7ygr6FztO9EsaqHCzTZNB3DnBc 9eLIC3O17mDPH7Yg0xTLw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:aR+kxBKn1lg=:95RONF6q16G86gygWvn8Lm DMAhIPCiI+JUgPAEndpPapfVSb0cF9ivEjAg0KKVr87dUG7Ig3ZPbMXJonc+CfYJNoUixcC7Z eUjrBk6hEWJYQEij6pX3+zLnXXS3I0v+PzdusUrhChtZpbEjr4ax21gtH+74TuyhDgVAHQbLj onJxuUiavoLlFt4JammwqeZCxxgsQRHi5mOgh00amtYihJxVekVLB2nnn9UsEn0XQyIJ80y2V f/ehZjpLSWuCQznbEHlIXuCntX1J74ifKHQdyxsOk2AkSpnJJjQPlxYT5CmaMr7XEgWtP2DqE lP7qQQiw83EFMdzBjVwVU6Fg8ky84s/oZ1jgnQeBQk1Idm2kBXEfgPodaR7K3VgbIKYSBwe+z scF1GSyDmlX8DxpVEEhJWWQDNbYw+jhPJrJksS6MZbtXx7mZPS/PqpxXmcS9RHg1Giv/V0BYX 3jDQ1W90RxQmcb3S//Imxe4NgNoGx+PPWiseD0kpHxOziXmrkK8G86GNXV6VkECpghuh9yXg8 nFK3hrw1lbxrwws6agpE1ZFyUXu4ifdhN6iR7THoZKKKrYA/OI95g62ZfU6MH0OIsbC8Wo6zx xqVm828hIc2jCu9P5ZHrU0gD4BtuOFGu5Dl4Y0Nz67L4egOytxZdWxSlVvtkEB9zeEvg2XSIo EYnsK5gIsXIGBtBmtM1pNZBS4NVnThAOLbK/jHDQOZgO7n88m7b490FOdwyKSACjNacbDcBDu E2F6s1vi3UK43YsD/nl+aUlZsCjIjA+bVS6lgYYmRGN0o3U0q+gLOkN2gPUTKdWBz5OXwFXAy XQK25owdYrTEXEHL44KBk7IO48TX/S/Lhvk9SUUZUtHuxQS2VFE5UcoGE8XC8Kjc98kf4eeCT LTBiLE2P/y0kp0bKx6skxOCZuW9tuFYighyKUtXhBYd3WUIrNL5YoDl0zHrDakgbm5KkTBfms jbP1l7i6tcPaTGu0gNmgdJ2P/l+on7s6WacXS5iKTWY1+f4bj3Ko+IjUMXbQqNe0AtlkaDb7D CWfeAwFuhOSMkxpxuAFRHnC+xx5tBC+/Uio7B4RIT4zWIymfmn/fSmtaF7ytbNaZOWpBvGQQb +Byh5FIoquB3oRhBxls5sboNIl+pAg18B2Egzi36WSLfafm0Fue6ruQpoPKEy7+pTl09bV9ET aGAzO0+HMcWx9SYXsH3g5aOsifUWO2SUGF5xwDP/oNu9bLd7LZ1grQLKuNolsgIfd6mz/6cn4 K1+EH/4kg8BOvzg8yDRbPhMjoNQ0fpt7bmwgbLqiOnMqoAZzUuXiikUVOzL0= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> But IIUC in neither of our proposals we would have done that. > > I wouldn't be so sure: the code fragment I've shown that detects > mode-line height changes is inside redisplay_window. But we should collect evidence from all windows first before redisplaying again. >> I'd even say that we should resize windows when redisplay finds out >> that the mode line height has been increased and would obscure the >> window above, not leave at least one line of its window's text >> visible > > Some might dislike such side effects, I think, for the same reason > some dislike the resizing which happens due to mini-window growth. You probably misunderstood. I meant the example from my other mail where enlarging the mode line covers the entire text area of its window. In that case we sooner or later will resize anyway, that is when the window resizing code becomes aware of the fact. martin From debbugs-submit-bounces@debbugs.gnu.org Sat May 02 14:07:02 2020 Received: (at 38181) by debbugs.gnu.org; 2 May 2020 18:07:02 +0000 Received: from localhost ([127.0.0.1]:53895 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUwXO-0008Gl-6S for submit@debbugs.gnu.org; Sat, 02 May 2020 14:07:01 -0400 Received: from mout.gmx.net ([212.227.17.22]:48299) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUwXM-0008GX-EU for 38181@debbugs.gnu.org; Sat, 02 May 2020 14:06:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588442805; bh=cgEYCFMw25uqAlNgc/cASXpU70E/msIP6Sx4CBmxe60=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ho/usGw6gqNJHTVUkpgpjT1cuJ/VkBXks7H1ysimJYqgPfANzGxk0xm054iPIt7Wt M69QVFISSocZc3DS30Vo6TmvK9NA4uFx4BfuizLbgrqQSPTBigNUvNO8VRWpixtiZC Q1W+viUXYihjqUJK1vJvrFhCWD2DRw6HTb880oC0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([46.125.249.13]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MbRfl-1it8sW1uyf-00buSW; Sat, 02 May 2020 20:06:45 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii 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> From: martin rudalics Message-ID: <01cee2f7-aeb5-4eb1-b2d5-e056c91eab8b@gmx.at> Date: Sat, 2 May 2020 20:06:38 +0200 MIME-Version: 1.0 In-Reply-To: <83a78u5s8y.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:PQSMEpvH7A3+9QOJbbGD38GVZVTUOKiTS6gQOgLXyXuGkAqN1j+ 1Xiiivem9ATt0QOxdtjm23X81eyyy6gu6UulB9ETeo4MqgFHTfR7GvVeSl/4nuLR3FQsVkL IFTAHUQOaLKDcY0CPIacyrJYDBplV7om+afHO79s565IYOnMocvToGp0Z7vxh8OLdnzxGF5 nz/QIVVNtMAgZcARQYz9A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:E29Z7oLjKfk=:0QO0BxyHXw7laKWDxBzlBJ Kcbx+9BQYGSVfKKiICLLhP628PXxoD6JtYLfcEkqwA2AFHfGtQ140BZlT0Mqc1mPnjYm5KEFH qOwLKoxj7XiBhQSSHaB6BHRU7rBQTvmWwPCc5gHkoznBhWT9IC1D4nZEaGh0EVxjs+tNFsPQR XVsx9ohO2dr7N9iD8Wuzk1pBINN/fNiEmmZTJQz7bJvKktZHa3VgR426c3fXh/RfgWENNcW1s GkFfYXDIc89AEN7Ps043ejCbqrAf48uIG3qWleKYHZIlMu8ioN9nht4i16C3Cd4Ymuk6K3GDE wIbh7P2+cjF9wVWMrsfj6DZukQW+ljsh3hkq/2UJF4Z5+SA5/xiCsJB6linsRBFprfz6Pcs63 PGhxh4NaWhWm8ZGAT5FhPdiV3wRLhogoxdg/TwrPJjog6yoOjuTgLLDY/atasCpKCRshW449k 0tE5aG7e6agZPx3E6lalefMdHfvnpWncU7ABRvVuoGtwli1GDyxqNl35pqnOm+VoXcsZJTWht 8+t0iZxEr8A38C/e70CpiLodVRqwtTH2AG29vP2JPdIo1wLown+euBXNgPiXaLL7KgXgk+Whe zKsO+mzCEclu5ABHgoIjCkGQQALwiCE/T8JqkNtgVAtpgJwJqGJOj6Y0dtiNcHWcLtMsV3h4N OlriTE5MiiBbsU9bV2NahCudzTZHjNCCisGmCZ62FLzqxgjCIOk1NY3eRRcX7er03aZTn8F5G IKNnc310Ud/mgysf+8i1Vr9CrgV1mTtB/bYvf67Y1XlDatpay41hpFSOyuxgcu32TqOskt+XZ EAaX/YchK0MlmYFdYpkd0oPfV36swUc5UioWQB8yGu18HyrqdeO5EjYnPCTFohyYRRgYpXdxJ LRqEGOPF8XY42+g0VhAMT9uxhwDz6TSRheCaXC9wNrJ/a58BM3TKthJNmjuZmP37FQ/ovlh4z w3HG+8fvmirgtHmRJtXhX/lKJnAYaMRCEssk+EfihdkbTBDnticAVs1DRVKdBivmllATvMaDk kVDK9TcFj8tCER0oBkkos17cOKz+AJNZztUaA6qSzGwgNwio6ax8+bVraJws7XY08+WlfWD3U Mp57cpG9YC/HPIwIAvgCiikbyT2TQIFmxf4nIHlC166U4YrhXDEpn+z+PAZxyGPaoPOw6rPix cEEL8LmLVTlIT6NWbgkbEFPrOo4Lvqh/NTK2Z2kYCKRql17vXKqgY1gd5HSEizxTZSpQq+5cV ngbIUorGXZsyaF+JM X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > 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 (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. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Mon May 04 09:46:41 2020 Received: (at 38181) by debbugs.gnu.org; 4 May 2020 13:46:41 +0000 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 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 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 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 Date: Mon, 04 May 2020 16:46:27 +0300 Message-Id: <83wo5rolsc.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-Reply-To: <01cee2f7-aeb5-4eb1-b2d5-e056c91eab8b@gmx.at> (message from martin rudalics on Sat, 2 May 2020 20:06:38 +0200) Subject: Re: bug#38181: Actual height of mode-line not taken into account 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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? From debbugs-submit-bounces@debbugs.gnu.org Mon May 04 11:04:30 2020 Received: (at 38181) by debbugs.gnu.org; 4 May 2020 15:04:30 +0000 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 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 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 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii 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> From: martin rudalics Message-ID: Date: Mon, 4 May 2020 17:04:18 +0200 MIME-Version: 1.0 In-Reply-To: <83wo5rolsc.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:ofTt6udl1RH/Rpc8q5fm7L96Z85r3fZjLmv9/T/o+AGIxfCTUVn uwnc5XUXTtxD5q9XCylEQadysAmdchCkwbiQG7Ew/pCq33a8wgHreFfGIkwa0F/rE2/G4qQ FnxFNVKMo/PnsUGVnBSAT+laQTL9MmVwRUHpfEvjAkUEHCO+E82dyTBTsgLL7hRRRxOwom7 CzYo7/bj8F9BtGP9NG+Pw== X-Spam-Flag: NO 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+WGm VXCkp+eOhGaXj0N29DirTcYUtfbRZvd76CLsrq33zgZnwNro7SA80WfhQ/hF+yG9JmUdmLsdw gYQX9YHMU6VFdfRLkg//dXSST5nO/ggC98wFqtqBepScPOmaFltLkIHdf/1iRF2gZFn0ksV5t XEdOVP5mwIUzAeGiiHPbNWutLoUfJNDFo6yRffbuk9/0voSZJuhWi/AaGyHaowvjT/VhUySkC kmmsuujgnm5iiZvwAPMSh6mPIiJu6b/skh8fP0KoyURKAQmOh8n5GLH2+hXf5JU1cQLt/bPM9 T4GkGKZgiq7o38p/f5prXu/3OM441DNtDRu7yE4kfDbVdAgxirPQRPG85RYrwwiKT1+GQKFUK qX0iyOQP+wuRi/wE5U0Zn1cUdq1NcQ4h/1ClRvn/KBTDNcx8bo8JJ4b8nsSFeSBuFtXxkbXZR ustyOiCCxn/JLKOLd X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > 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 From debbugs-submit-bounces@debbugs.gnu.org Mon May 04 13:05:24 2020 Received: (at 38181) by debbugs.gnu.org; 4 May 2020 17:05:24 +0000 Received: from localhost ([127.0.0.1]:33858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVeWy-000195-1B for submit@debbugs.gnu.org; Mon, 04 May 2020 13:05:24 -0400 Received: from mout.gmx.net ([212.227.15.19]:54311) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVeWv-00018n-KB for 38181@debbugs.gnu.org; Mon, 04 May 2020 13:05:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588611914; bh=mWkkzWhXPSVG94tmZtGWQLHw/ihd5+hD6uenmT7HiMY=; h=X-UI-Sender-Class:Subject:From:To:Cc:References:Date:In-Reply-To; b=W94EORBGyqfumOAwRnSMVIvh/2Evhmr7LPu5yJZYwOXe05w7Oyllxf0YUucdjg89H xbuJWKm1xtcxGn4Qb+TPK/ClUrjuU/Wv1H1+nai+O8eOUF5eRf8GFXOY9VUenYnpVw n21r/FxZYzUlOWpOiIiD382PNgzVCgY5WoxUFD/o= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([46.125.249.121]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mk0Ne-1iq1Fy28yG-00kQJx; Mon, 04 May 2020 19:05:14 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account From: martin rudalics To: Eli Zaretskii 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> Message-ID: <4682372c-e25a-dc62-842f-c3971f79bb16@gmx.at> Date: Mon, 4 May 2020 19:05:12 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:h85gVHOHF6OgRdVfGih3/ALJWaQNvQrLSGt+xVTg/I6CMC3ba0a sHZjoFAWvutfnfFsHjVO1nkP9wIRcc1qL/EOm7yGzx9HUTeKHrvlBEVADAOn9scxBANkQeX +VX3o4kn0FslRWfZ8f+mPpiiB9fNdhV6McofVeubaOn6HR1c9HNfh8wdUiyFpW+ormodbsR Pj+yjxplbWT2AroaKPwRQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:ZDRKC3cGvto=:DBoI1jLeo/h46qx5O9PW+X Qu8vFolH0yp8pj1neiBHB1muLXmOw2VvtQZMkLziQVrkdUVslqv6r88c1WF6mrf1UXd0gTEF+ N8f9xsTC8kU223+JfmStbhRz9C2qx0sfHIQgjex9/+RuTfWIcrCxFwnganqbFiRBxeMTHC+Kc cvQ2NXCH+L2nLgw608RCvPn0LsSXxW6g/n3zu244lvDo0Ezl94a4Tt6Ajyichw5H9Pfj0KaVn pthLVrkPt+ln2zsd7flYUPkzwPDjIpwP7qatcfwkVlboQYgnm64EQk7o9X7wvrZbUIDSwQvuB kmKFww6SnC6CzqbPJnlojqTNKStgeFv+0A4zeoLn0aZDkuTcQaKuM2ONjwYxB/v7yJQyQ2tD4 43tWVKIJVPAMA3QAyLaWr6xwrk0fxnC4sXrCgOdIowmAuvm30D04juI8uKjFdyrKty49Xsb8C GL2o7DLBv0TMUNRnzDiR7mamP37HRqwD3zNrutsUoanLjyViv+z4c8GZwQkslmdffRw6/BXkh mlzANa0RSHSdbtaupiedb3sGJ4tYDwdQunig9BtwnAon+NlWvxRfyyTdZd4gw97Ttq3a0xTwF vYUS70YMHnTzgQhEqRwtuaDjUZKIBC8SxArdhGY/779BRLlXYtbwfATK3sdmGHxILjX9s3bMr 65vCXCe0jr+a05tqUHbPDpzI3JvBxEVj1ryohtPBv/5b24leWZ04kG35UzE9ZyyNJf6bhMESt vjdtB8vdt6b7xz7XTKHQyfCKOqomV3+gFvsN+CrRhtWh4ZLCS33bqsOoGaLNBckqLEqJWkk21 CGoK1VCe/e10bVpLP8/Y/3lvIKsAEFXNsTdl9XlvZ3k+EvLdWMQ2j5Euog5tHR3n7jkUoy816 2noDAGghkWPk8FjjdmOVGtFSStaTcx6UAhGZhQZL1rE22IuEuzLLpKOOPF9IYdagjrW+jH4Gh cMTP/pzP9l4ba1C7PayVdaB/9GK3WJ+HOsdKHjKJj+GQFk5iVy8IS7l0HF/W44lulNfcfoTBH /ZxTP6VV0r4U9OFJIl0iuk2IXFPoo6u/pfNgnK9kDBxs+rD2Cda3IMIsf+yx2F0BOv9QtkKei Xki0BxCIPmPTsIOobMPpjKrqcSUacYTJ6GQXRICq5xKk4g9aw/r4QSEFiov2m63FP0VRaNYrz 0uSOc76Q/sNnBcHi0tVOIrsOVAa0qCyzaGZNl9DTH20Ca/o7iy0tkxqMMpdBJNJqL/TIclc0R ym8ch3wuxacw63M8Z X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > So if I'm not > entirely misguided it must be somehow set by PRODUCE_GLYPHS outside of > redisplay_internal. Confirmed meanwhile. Something is utterly broken here. Removing the offending setting in PRODUCE_GLYPHS automagically fixes Bug#40639 and Bug#41071, for example. martin From debbugs-submit-bounces@debbugs.gnu.org Tue May 05 04:32:43 2020 Received: (at 38181) by debbugs.gnu.org; 5 May 2020 08:32:43 +0000 Received: from localhost ([127.0.0.1]:34695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVt0N-00057A-08 for submit@debbugs.gnu.org; Tue, 05 May 2020 04:32:43 -0400 Received: from mout.gmx.net ([212.227.17.20]:50687) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVt0K-00056w-EC for 38181@debbugs.gnu.org; Tue, 05 May 2020 04:32:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588667553; bh=C3xAxnTfQyJiEXEgLgwLhI2hClNLx1ZkBmqv58ZODrQ=; h=X-UI-Sender-Class:Subject:From:To:Cc:References:Date:In-Reply-To; b=iXmWLRqBbi1Z9ukpeHfkuscmNXf67cMO3mVLJ6+Jrtv+atVzBZ+37covfFrpIuvxn WoZ2R8sjGdi8PC2I8TzCThW/dW3jModIXiUiwSsK5LCHnfLe41jNJTPmAqZAZULuwp y9ylQKmTyJ+OnmCvmxNDd6oY8Xw44eaqmASs+MCo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([46.125.249.75]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MvbBu-1jG8nu3ax4-00scWU; Tue, 05 May 2020 10:32:32 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account From: martin rudalics To: Eli Zaretskii 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> Message-ID: Date: Tue, 5 May 2020 10:32:31 +0200 MIME-Version: 1.0 In-Reply-To: <4682372c-e25a-dc62-842f-c3971f79bb16@gmx.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:qwcZqnJukXxfDN0GMwP53NpsJhpkOz4Lr2/ge1XAVT7vXn5ho3E YjrEY3rFCaRWUjCcYw2tdE816n92B8dr4Wt1XXtKFrG77bENBb6H/a3oLfCEu51frU9gNsJ 2pxyCpGhnQH+HDFRyDkhWWb/9+MWWwY12B79xzuKeYExiSoQzzSS4d8LB0MAGTd2nq/O2Zt qHawwGf8mSpSoNQkj0gKg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:jXFgHUMMkv0=:Nz7xBMzWn2KFiVERCTgPq0 /qMerpQN7D/GvR7cZLc6bKeOb4JUjMpzFDIQAlVI/sAgSpElR8F19jaxQTTdoidivY+s0pG8W khfHd4o5wavnzwaNRopUtMrT3JvEGJvx1wO4JhBKugMTVDFaWAinxDgF74VBAvJdufsQ1Fmqx /k3TRRgSs8AtPdmBYl4cidHjRcdkgR7cNYZ0BO3KjYHN/cdsJhDcAbsWK8/4jJ3aoggaL64ek gcqfnIKRefa4mEYdnzJXzpxClyjhPEqQGmjl/VAD7qRGHQ01mj/IlIwsjlK2eXQuR3l5JxS+q tcYW3TkzNKgDtr1TELpXyFFp6y/eo8zU8B9UbSxrngjSCYGMtRQTwsmj7bBWIBpuJSyjxThuk tCrbAMdDTYnpGWMdwniR4l+9FzUZ3CWAnmDx7NSlbbUFfjCesbbssRf0t/OBYRJIamHIplZm7 xq6ZV2AaUx5NWjkHudKDIHreJeSom7bYEoJhoigH318qMSgGxnXGLSGxTpAayukvSbEmvRmrn tPE6zdSAD31+xg20jgZy3uPOzq6tqR8hErac5kA04DjNdSkCOG+6YLyiBPmvEke2oMzBDQjZP oRaZSxWNmhUYMBqRqXYYV8H/tBsnukSzIib9GUzvr8cj748kbVXRDDmwzkPJl58zuG+oB82IX Ky0WrJpIoSlD6lGAWwiP0i02I47trgFUL3hsd0Cqws8Iv491lXBW3Nomt61ZLLFK4c33olW3P SkRC8cfCMznbvOxNwb0vGn2+C5gtQIwvDP74gbBLYevVGAvWvLGhL805voHhf+QjOg2O2ip/m yIBw7QRp6bUhdj52vTBosMzye96cnx7NEennOJaH5NoOb4t/M44DMX/Mc4jCQb+/NH3y9Uumg seFw6bC/07qa1uYW6KGyVhHUu/1XEU5X8rKhsm1r22TS2rcKNXXLHEjFSJ2Ic8wq2/oJlcIRb ZSR6jsCAkwpnQEWH6U3g/eNl6Fws5DGxTtYuabSSKFI5PRwGU5GdZYi6Z64LNKNooZzpPnk9P eT4mGZi1/dq++HFRk6f47i2UHPpBgCp/SiHV6C3FL931BJGSFY5EnM0PWhP+piMJBoq888X/Y MMB4RR0tRy1O0DZ4XLMfSuxtxN6qGaz8D8yZLCkApnStm9hisXqQukAQLkhrkdOYmJZMJlkoZ KpYA1U0NIcW/5vNTh+pq+Rn/sZLLEgLXoKFn/l+eJa5a0pb4adWeYkI0qqYj+gPDt3b20kWyU 7p8zdPQq6Fx9sSjh6 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Below find two backtraces with emacs -Q where PRODUCE_GLYPHS here sets inhibit_free_realized_faces outside the scope of redisplay_internal (that is, while redisplaying_p is nil) such that these will not get caught by the unbind form in redisplay_internal. do_inhibit_free_realized_faces is the function I used to trap these. It's defined as void do_inhibit_free_realized_faces (void) { if (redisplaying_p) inhibit_free_realized_faces = true; else if (!inhibit_free_realized_faces) inhibit_free_realized_faces = true; } and gets called by PRODUCE_GLYPHS instead of setting inhibit_free_realized_faces directly. The first one comes initially: #0 0x000000000046f836 in do_inhibit_free_realized_faces () at ../../src/xdisp.c:2043 #1 0x000000000057098e in display_line (it=0x7fffffffab00, cursor_vpos=0) at ../../src/xdisp.c:23311 #2 0x00000000004c1a8e in try_window (window=XIL(0x12c2db5), pos=..., flags=0) at ../../src/xdisp.c:19180 #3 0x00000000004a1029 in display_echo_area_1 (a1=19672496, a2=XIL(0)) at ../../src/xdisp.c:11552 #4 0x00000000004a0270 in with_echo_area_buffer (w=0x12c2db0, which=0, fn=0x4a0f3d , a1=19672496, a2=XIL(0)) at ../../src/xdisp.c:11314 #5 0x00000000004a0ee8 in display_echo_area (w=0x12c2db0) at ../../src/xdisp.c:11510 #6 0x00000000004a4520 in echo_area_display (update_frame_p=true) at ../../src/xdisp.c:12023 #7 0x000000000049f59e in message3_nolog (m=XIL(0x12b6be4)) at ../../src/xdisp.c:11016 #8 0x000000000049f26b in message3 (m=XIL(0x12b6be4)) at ../../src/xdisp.c:10946 #9 0x0000000000834154 in Fmessage (nargs=2, args=0x7fffffffc210) at ../../src/editfns.c:2859 #10 0x00000000008456b1 in funcall_subr (subr=0xe0e680 , numargs=2, args=0x7fffffffc210) at ../../src/eval.c:2847 #11 0x0000000000845287 in Ffuncall (nargs=3, args=0x7fffffffc208) at ../../src/eval.c:2794 #12 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff4225264), vector=XIL(0x7ffff4225135), maxdepth=make_fixnum(7), args_template=make_fixnum(0), nargs=0, args=0x7fffffffc728) at ../../src/bytecode.c:633 #13 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff422510d), nargs=0, arg_vector=0x7fffffffc728) at ../../src/eval.c:2989 #14 0x00000000008452cb in Ffuncall (nargs=1, args=0x7fffffffc720) at ../../src/eval.c:2796 #15 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff42252a4), vector=XIL(0x7ffff4223e0d), maxdepth=make_fixnum(25), args_template=make_fixnum(257), nargs=1, args=0x7fffffffd0d8) at ../../src/bytecode.c:633 #16 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff4223ddd), nargs=1, arg_vector=0x7fffffffd0d0) at ../../src/eval.c:2989 #17 0x00000000008452cb in Ffuncall (nargs=2, args=0x7fffffffd0c8) at ../../src/eval.c:2796 #18 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff4229434), vector=XIL(0x7ffff42254f5), maxdepth=make_fixnum(14), args_template=make_fixnum(0), nargs=0, args=0x7fffffffdc18) at ../../src/bytecode.c:633 #19 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff42254c5), nargs=0, arg_vector=0x7fffffffdc18) at ../../src/eval.c:2989 #20 0x00000000008452cb in Ffuncall (nargs=1, args=0x7fffffffdc10) at ../../src/eval.c:2796 #21 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff422a0fc), vector=XIL(0x7ffff4229605), maxdepth=make_fixnum(12), args_template=make_fixnum(0), nargs=0, args=0x7fffffffe250) at ../../src/bytecode.c:633 #22 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff42295d5), nargs=0, arg_vector=0x7fffffffe250) at ../../src/eval.c:2989 #23 0x0000000000845b42 in apply_lambda (fun=XIL(0x7ffff42295d5), args=XIL(0), count=4) at ../../src/eval.c:2926 #24 0x0000000000843d3e in eval_sub (form=XIL(0x7ffff4385a83)) at ../../src/eval.c:2318 #25 0x00000000008430ce in Feval (form=XIL(0x7ffff4385a83), lexical=XIL(0)) at ../../src/eval.c:2102 #26 0x0000000000764b7f in top_level_2 () at ../../src/keyboard.c:1100 #27 0x000000000084126b in internal_condition_case (bfun=0x764b5c , handlers=XIL(0x90), hfun=0x76455b ) at ../../src/eval.c:1355 #28 0x0000000000764bc7 in top_level_1 (ignore=XIL(0)) at ../../src/keyboard.c:1108 #29 0x000000000084071f in internal_catch (tag=XIL(0xd200), func=0x764b81 , arg=XIL(0)) at ../../src/eval.c:1116 #30 0x0000000000764aa6 in command_loop () at ../../src/keyboard.c:1069 #31 0x0000000000764042 in recursive_edit_1 () at ../../src/keyboard.c:714 #32 0x000000000076423a in Frecursive_edit () at ../../src/keyboard.c:786 #33 0x00000000007603bd in main (argc=2, argv=0x7fffffffe7c8) at ../../src/emacs.c:2035 Lisp Backtrace: "message" (0xffffc210) "display-startup-echo-area-message" (0xffffc728) "command-line-1" (0xffffd0d0) "command-line" (0xffffdc18) "normal-top-level" (0xffffe250) (gdb) After now evaluating (setq inhibit-free-realized-faces nil) the second one comes up as: #0 0x000000000046f836 in do_inhibit_free_realized_faces () at ../../src/xdisp.c:2043 #1 0x000000000057098e in display_line (it=0x7fffffffa4c0, cursor_vpos=0) at ../../src/xdisp.c:23311 #2 0x00000000004c1a8e in try_window (window=XIL(0x12c2db5), pos=..., flags=0) at ../../src/xdisp.c:19180 #3 0x00000000004a1029 in display_echo_area_1 (a1=19672496, a2=XIL(0)) at ../../src/xdisp.c:11552 #4 0x00000000004a0270 in with_echo_area_buffer (w=0x12c2db0, which=0, fn=0x4a0f3d , a1=19672496, a2=XIL(0)) at ../../src/xdisp.c:11314 #5 0x00000000004a0ee8 in display_echo_area (w=0x12c2db0) at ../../src/xdisp.c:11510 #6 0x00000000004a4520 in echo_area_display (update_frame_p=true) at ../../src/xdisp.c:12023 #7 0x000000000049f59e in message3_nolog (m=XIL(0xf07bf4)) at ../../src/xdisp.c:11016 #8 0x000000000049f26b in message3 (m=XIL(0xf07bf4)) at ../../src/xdisp.c:10946 #9 0x0000000000834154 in Fmessage (nargs=2, args=0x7fffffffbd48) at ../../src/editfns.c:2859 #10 0x00000000008456b1 in funcall_subr (subr=0xe0e680 , numargs=2, args=0x7fffffffbd48) at ../../src/eval.c:2847 #11 0x0000000000845287 in Ffuncall (nargs=3, args=0x7fffffffbd40) at ../../src/eval.c:2794 #12 0x00000000008440f9 in Fapply (nargs=3, args=0x7fffffffbd40) at ../../src/eval.c:2381 #13 0x00000000008456b1 in funcall_subr (subr=0xe0f100 , numargs=3, args=0x7fffffffbd40) at ../../src/eval.c:2847 #14 0x0000000000845287 in Ffuncall (nargs=4, args=0x7fffffffbd38) at ../../src/eval.c:2794 #15 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff402e244), vector=XIL(0x7ffff402e075), maxdepth=make_fixnum(7), args_template=make_fixnum(385), nargs=2, args=0x7fffffffc238) at ../../src/bytecode.c:633 #16 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff402e045), nargs=2, arg_vector=0x7fffffffc230) at ../../src/eval.c:2989 #17 0x00000000008452cb in Ffuncall (nargs=3, args=0x7fffffffc228) at ../../src/eval.c:2796 #18 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff402e9cc), vector=XIL(0x7ffff402df45), maxdepth=make_fixnum(5), args_template=make_fixnum(256), nargs=1, args=0x7fffffffc6e8) at ../../src/bytecode.c:633 #19 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff402df15), nargs=1, arg_vector=0x7fffffffc6e0) at ../../src/eval.c:2989 #20 0x00000000008452cb in Ffuncall (nargs=2, args=0x7fffffffc6d8) at ../../src/eval.c:2796 #21 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff4031b2c), vector=XIL(0x7ffff40318ed), maxdepth=make_fixnum(4), args_template=make_fixnum(0), nargs=0, args=0x7fffffffcbb0) at ../../src/bytecode.c:633 #22 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff40318bd), nargs=0, arg_vector=0x7fffffffcbb0) at ../../src/eval.c:2989 #23 0x00000000008452cb in Ffuncall (nargs=1, args=0x7fffffffcba8) at ../../src/eval.c:2796 #24 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff4031b6c), vector=XIL(0x7ffff4031865), maxdepth=make_fixnum(1), args_template=make_fixnum(0), nargs=0, args=0x7fffffffd1e0) at ../../src/bytecode.c:633 #25 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff403183d), nargs=0, arg_vector=0x7fffffffd1e0) at ../../src/eval.c:2989 #26 0x00000000008452cb in Ffuncall (nargs=1, args=0x7fffffffd1d8) at ../../src/eval.c:2796 #27 0x0000000000844088 in Fapply (nargs=2, args=0x7fffffffd1d8) at ../../src/eval.c:2377 #28 0x00000000008456b1 in funcall_subr (subr=0xe0f100 , numargs=2, args=0x7fffffffd1d8) at ../../src/eval.c:2847 #29 0x0000000000845287 in Ffuncall (nargs=3, args=0x7fffffffd1d0) at ../../src/eval.c:2794 #30 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff438e57c), vector=XIL(0x7ffff438e445), maxdepth=make_fixnum(10), args_template=make_fixnum(257), nargs=1, args=0x7fffffffd730) at ../../src/bytecode.c:633 #31 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff438e415), nargs=1, arg_vector=0x7fffffffd728) at ../../src/eval.c:2989 #32 0x00000000008452cb in Ffuncall (nargs=2, args=0x7fffffffd720) at ../../src/eval.c:2796 #33 0x0000000000844bb7 in call1 (fn=XIL(0xcf30), arg1=XIL(0x172d2f5)) at ../../src/eval.c:2654 #34 0x000000000076e3ae in timer_check_2 (timers=XIL(0), idle_timers=XIL(0x170e5b3)) at ../../src/keyboard.c:4340 #35 0x000000000076e4e3 in timer_check () at ../../src/keyboard.c:4402 #36 0x000000000076c242 in readable_events (flags=1) at ../../src/keyboard.c:3401 #37 0x0000000000778a4e in get_input_pending (flags=1) at ../../src/keyboard.c:6800 #38 0x0000000000781f2b in detect_input_pending_run_timers (do_display=true) at ../../src/keyboard.c:10361 #39 0x00000000008aeb95 in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at ../../src/process.c:5701 #40 0x000000000042a466 in sit_for (timeout=make_fixnum(30), reading=true, display_option=1) at ../../src/dispnew.c:6077 #41 0x0000000000769957 in read_char (commandflag=1, map=XIL(0x1709e33), prev_event=XIL(0), used_mouse_menu=0x7fffffffe13f, end_time=0x0) at ../../src/keyboard.c:2738 #42 0x0000000000780011 in read_key_sequence (keybuf=0x7fffffffe2d0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9547 #43 0x00000000007653c8 in command_loop_1 () at ../../src/keyboard.c:1350 #44 0x000000000084126b in internal_condition_case (bfun=0x764f4c , handlers=XIL(0x90), hfun=0x76455b ) at ../../src/eval.c:1355 #45 0x0000000000764b31 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091 #46 0x000000000084071f in internal_catch (tag=XIL(0xd200), func=0x764b04 , arg=XIL(0)) at ../../src/eval.c:1116 #47 0x0000000000764acf in command_loop () at ../../src/keyboard.c:1070 #48 0x0000000000764042 in recursive_edit_1 () at ../../src/keyboard.c:714 #49 0x000000000076423a in Frecursive_edit () at ../../src/keyboard.c:786 #50 0x00000000007603bd in main (argc=2, argv=0x7fffffffe7c8) at ../../src/emacs.c:2035 Lisp Backtrace: "message" (0xffffbd48) "apply" (0xffffbd40) "eldoc-minibuffer-message" (0xffffc230) "eldoc-message" (0xffffc6e0) "eldoc-print-current-symbol-info" (0xffffcbb0) 0xf4031838 PVEC_COMPILED "apply" (0xffffd1d8) "timer-event-handler" (0xffffd728) (gdb) And below is one where I load my usual customizations #0 0x000000000046f836 in do_inhibit_free_realized_faces () at ../../src/xdisp.c:2043 #1 0x000000000057098e in display_line (it=0x7fffffff8a30, cursor_vpos=0) at ../../src/xdisp.c:23311 #2 0x00000000004c1a8e in try_window (window=XIL(0x12c5db5), pos=..., flags=0) at ../../src/xdisp.c:19180 #3 0x00000000004a1029 in display_echo_area_1 (a1=19684784, a2=XIL(0)) at ../../src/xdisp.c:11552 #4 0x00000000004a0270 in with_echo_area_buffer (w=0x12c5db0, which=0, fn=0x4a0f3d , a1=19684784, a2=XIL(0)) at ../../src/xdisp.c:11314 #5 0x00000000004a0ee8 in display_echo_area (w=0x12c5db0) at ../../src/xdisp.c:11510 #6 0x00000000004a4520 in echo_area_display (update_frame_p=true) at ../../src/xdisp.c:12023 #7 0x000000000049f59e in message3_nolog (m=XIL(0xeef4b4)) at ../../src/xdisp.c:11016 #8 0x000000000049f26b in message3 (m=XIL(0xeef4b4)) at ../../src/xdisp.c:10946 #9 0x000000000049f891 in message_with_string (m=0x9a619d "Loading %s...", string=XIL(0x7ffff3d31104), log=true) at ../../src/xdisp.c:11089 #10 0x0000000000881110 in Fload (file=XIL(0x7ffff3d31104), noerror=XIL(0), nomessage=XIL(0), nosuffix=XIL(0), must_suffix=XIL(0)) at ../../src/lread.c:1440 #11 0x0000000000845883 in funcall_subr (subr=0xe11c40 , numargs=1, args=0x7fffffffa3c8) at ../../src/eval.c:2879 #12 0x0000000000845287 in Ffuncall (nargs=2, args=0x7fffffffa3c0) at ../../src/eval.c:2794 #13 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff3d4ef0c), vector=XIL(0x7ffff3d4ec45), maxdepth=make_fixnum(14), args_template=make_fixnum(257), nargs=1, args=0x7fffffffa960) at ../../src/bytecode.c:633 #14 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff3d4ec15), nargs=1, arg_vector=0x7fffffffa958) at ../../src/eval.c:2989 #15 0x00000000008452cb in Ffuncall (nargs=2, args=0x7fffffffa950) at ../../src/eval.c:2796 #16 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff3d4f8f4), vector=XIL(0x7ffff3d4e9ad), maxdepth=make_fixnum(15), args_template=make_fixnum(385), nargs=142, args=0x7fffffffaf00) at ../../src/bytecode.c:633 #17 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff3d4e97d), nargs=142, arg_vector=0x7fffffffaef8) at ../../src/eval.c:2989 #18 0x00000000008452cb in Ffuncall (nargs=143, args=0x7fffffffaef0) at ../../src/eval.c:2796 #19 0x00000000008444c3 in Fapply (nargs=3, args=0x7fffffffb518) at ../../src/eval.c:2424 #20 0x00000000008456b1 in funcall_subr (subr=0xe0f100 , numargs=3, args=0x7fffffffb518) at ../../src/eval.c:2847 #21 0x0000000000845287 in Ffuncall (nargs=4, args=0x7fffffffb510) at ../../src/eval.c:2794 #22 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff3d213dc), vector=XIL(0x7ffff41be795), maxdepth=make_fixnum(5), args_template=make_fixnum(128), nargs=141, args=0x7fffffffb930) at ../../src/bytecode.c:633 #23 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff41be765), nargs=141, arg_vector=0x7fffffffb930) at ../../src/eval.c:2989 #24 0x0000000000845b42 in apply_lambda (fun=XIL(0x7ffff41be765), args=XIL(0x1631ab3), count=36) at ../../src/eval.c:2926 #25 0x0000000000843d3e in eval_sub (form=XIL(0x1631b23)) at ../../src/eval.c:2318 #26 0x0000000000882b74 in readevalloop_eager_expand_eval (val=XIL(0x1631b23), macroexpand=XIL(0x7ffff31f4a98)) at ../../src/lread.c:1912 #27 0x00000000008833a7 in readevalloop (readcharfun=XIL(0x168c415), infile0=0x0, sourcename=XIL(0x13b67b4), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=XIL(0), end=XIL(0)) at ../../src/lread.c:2094 #28 0x00000000008836d2 in Feval_buffer (buffer=XIL(0x168c415), printflag=XIL(0), filename=XIL(0x13b67b4), unibyte=XIL(0), do_allow_print=XIL(0x30)) at ../../src/lread.c:2167 #29 0x0000000000845883 in funcall_subr (subr=0xe11cc0 , numargs=5, args=0x7fffffffc1d0) at ../../src/eval.c:2879 #30 0x0000000000845287 in Ffuncall (nargs=6, args=0x7fffffffc1c8) at ../../src/eval.c:2794 #31 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff3d5d664), vector=XIL(0x7ffff3d5cfe5), maxdepth=make_fixnum(6), args_template=XIL(0), nargs=0, args=0x0) at ../../src/bytecode.c:633 #32 0x00000000008464a0 in funcall_lambda (fun=XIL(0x7ffff3d5cfb5), nargs=4, arg_vector=0x7ffff3d5cfe5) at ../../src/eval.c:3067 #33 0x00000000008452cb in Ffuncall (nargs=5, args=0x7fffffffc740) at ../../src/eval.c:2796 #34 0x0000000000844c98 in call4 (fn=XIL(0x7ffff2eda6a0), arg1=XIL(0x13b67b4), arg2=XIL(0x13b67b4), arg3=XIL(0x30), arg4=XIL(0x30)) at ../../src/eval.c:2676 #35 0x0000000000880f40 in Fload (file=XIL(0x13354d4), noerror=XIL(0x7ffff2edac10), nomessage=XIL(0x7ffff2edaa68), nosuffix=XIL(0), must_suffix=XIL(0)) at ../../src/lread.c:1376 #36 0x0000000000845883 in funcall_subr (subr=0xe11c40 , numargs=3, args=0x7fffffffcaf8) at ../../src/eval.c:2879 #37 0x0000000000845287 in Ffuncall (nargs=4, args=0x7fffffffcaf0) at ../../src/eval.c:2794 #38 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff422855c), vector=XIL(0x7ffff42282c5), maxdepth=make_fixnum(18), args_template=make_fixnum(769), nargs=3, args=0x7fffffffd0d8) at ../../src/bytecode.c:633 #39 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff4228295), nargs=3, arg_vector=0x7fffffffd0c0) at ../../src/eval.c:2989 #40 0x00000000008452cb in Ffuncall (nargs=4, args=0x7fffffffd0b8) at ../../src/eval.c:2796 #41 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff4229434), vector=XIL(0x7ffff42254f5), maxdepth=make_fixnum(14), args_template=make_fixnum(0), nargs=0, args=0x7fffffffdbf8) at ../../src/bytecode.c:633 #42 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff42254c5), nargs=0, arg_vector=0x7fffffffdbf8) at ../../src/eval.c:2989 #43 0x00000000008452cb in Ffuncall (nargs=1, args=0x7fffffffdbf0) at ../../src/eval.c:2796 #44 0x000000000089cd03 in exec_byte_code (bytestr=XIL(0x7ffff422a0fc), vector=XIL(0x7ffff4229605), maxdepth=make_fixnum(12), args_template=make_fixnum(0), nargs=0, args=0x7fffffffe230) at ../../src/bytecode.c:633 #45 0x0000000000845f0b in funcall_lambda (fun=XIL(0x7ffff42295d5), nargs=0, arg_vector=0x7fffffffe230) at ../../src/eval.c:2989 #46 0x0000000000845b42 in apply_lambda (fun=XIL(0x7ffff42295d5), args=XIL(0), count=4) at ../../src/eval.c:2926 #47 0x0000000000843d3e in eval_sub (form=XIL(0x7ffff4385a83)) at ../../src/eval.c:2318 #48 0x00000000008430ce in Feval (form=XIL(0x7ffff4385a83), lexical=XIL(0)) at ../../src/eval.c:2102 #49 0x0000000000764b7f in top_level_2 () at ../../src/keyboard.c:1100 #50 0x000000000084126b in internal_condition_case (bfun=0x764b5c , handlers=XIL(0x90), hfun=0x76455b ) at ../../src/eval.c:1355 #51 0x0000000000764bc7 in top_level_1 (ignore=XIL(0)) at ../../src/keyboard.c:1108 #52 0x000000000084071f in internal_catch (tag=XIL(0xd200), func=0x764b81 , arg=XIL(0)) at ../../src/eval.c:1116 #53 0x0000000000764aa6 in command_loop () at ../../src/keyboard.c:1069 #54 0x0000000000764042 in recursive_edit_1 () at ../../src/keyboard.c:714 #55 0x000000000076423a in Frecursive_edit () at ../../src/keyboard.c:786 #56 0x00000000007603bd in main (argc=2, argv=0x7fffffffe7a8) at ../../src/emacs.c:2035 Lisp Backtrace: "load" (0xffffa3c8) "custom-load-symbol" (0xffffa958) "custom-theme-set-variables" (0xffffaef8) "apply" (0xffffb518) "custom-set-variables" (0xffffb930) "eval-buffer" (0xffffc1d0) "load-with-code-conversion" (0xffffc748) "load" (0xffffcaf8) "startup--load-user-init-file" (0xffffd0c0) "command-line" (0xffffdbf8) "normal-top-level" (0xffffe230) (gdb) martin From debbugs-submit-bounces@debbugs.gnu.org Tue May 05 10:58:38 2020 Received: (at 38181) by debbugs.gnu.org; 5 May 2020 14:58:38 +0000 Received: from localhost ([127.0.0.1]:37035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVz1p-0000tJ-Kj for submit@debbugs.gnu.org; Tue, 05 May 2020 10:58:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVz1n-0000t3-Tc for 38181@debbugs.gnu.org; Tue, 05 May 2020 10:58:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55767) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVz1h-0007oo-Tu; Tue, 05 May 2020 10:58:29 -0400 Received: from [176.228.60.248] (port=2704 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jVz1e-0007qA-Hi; Tue, 05 May 2020 10:58:27 -0400 Date: Tue, 05 May 2020 17:58:05 +0300 Message-Id: <838si6mnsy.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-Reply-To: (message from martin rudalics on Tue, 5 May 2020 10:32:31 +0200) Subject: Re: bug#38181: Actual height of mode-line not taken into account 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: martin rudalics > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > Date: Tue, 5 May 2020 10:32:31 +0200 > > Below find two backtraces with emacs -Q where PRODUCE_GLYPHS here sets > inhibit_free_realized_faces outside the scope of redisplay_internal > (that is, while redisplaying_p is nil) such that these will not get > caught by the unbind form in redisplay_internal. Thanks. All of these enter redisplay via echo_area_display. That calls redisplay_internal, but only after it displays the mini-window. However, I had my doubts regarding the accuracy of my mental model. Namely, the part where I said that inhibit_free_realized_faces should never be non-zero outside of redisplay. So I looked at the code and its history, and it turns out I was wrong: the line that sets the flag in PRODUCE_GLYPHS was there since Emacs 21, and I see the flag set to non-zero all the way back to Emacs 22.1 (and probably earlier). So it sounds like we always were running like that. Therefore, I must turn the table and ask you to please describe in more detail, preferably with Lisp snippets to try, how the fact that this flag is non-zero gets in the way of something we need to do with faces, both in this bug and the other one you mentioned. I'd like to understand better how this flag interferes in these use cases. Thanks (and sorry for spreading misinformation: I was somehow confident that it was myself who added the setting of inhibit_free_realized_faces in PRODUCE_GLYPHS, but the truth is that it was Gerd, long ago). From debbugs-submit-bounces@debbugs.gnu.org Tue May 05 12:57:17 2020 Received: (at 38181) by debbugs.gnu.org; 5 May 2020 16:57:17 +0000 Received: from localhost ([127.0.0.1]:37239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW0se-0003wP-NY for submit@debbugs.gnu.org; Tue, 05 May 2020 12:57:17 -0400 Received: from mout.gmx.net ([212.227.17.21]:51311) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW0sc-0003w8-EA for 38181@debbugs.gnu.org; Tue, 05 May 2020 12:57:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588697827; bh=ngEO6D/GN77AE+F6iDbJ5RVlPNHGpYzM2vZrIm1PmHA=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=e5jsI3HZtNgd9bQF1/Hyb+Xc3fPT04aYXSSqRqhtjTyJAIHMZPmchwWYNt8UjaNCL JtYRL025cwlm+YkkzuWredX4roZOFjQnkIU5YGiiHZBUAhyZWVwYcEgEDDyVOqulDN KftkwGPptMGMUbaPUzslTtVAGyTlaUGrEvoZRbpY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([46.125.249.75]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mlw3X-1ioBbE0GUV-00j4xl; Tue, 05 May 2020 18:57:07 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii 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> From: martin rudalics Message-ID: <86491f07-ed68-2880-17a0-a60ed40d5059@gmx.at> Date: Tue, 5 May 2020 18:57:06 +0200 MIME-Version: 1.0 In-Reply-To: <838si6mnsy.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:xhWCKRFIGjdoO2QQ6bsy1Do2i8y9Z0j95rafhBIU7Ra+2rwKKGu hS973gHqkJHVrKQ9AISpMzN9JCgIxgYGQWNG7GDnGMBSFwYKBJjYaPVHmIOuoYqOtGiPS+S WoljerUMIUQwN8swRE8t9HB4qQgP2vFjMsuMIAX5PrVDW2OeRspUE+CWob7uM4IQHT5NwRd T4cQI/Wcw5xxRVCuE/ptQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:c1b2RoJ83RU=:9tqMmKdGiZ9CsASChv2IlK kh6FYtACXIP38xcpvFnMGvCtJ+rlovCde7vhnP1fFG5tRfTEigFIHBUL1q/o4YitOdeI8CFn+ gq2R309UZslvr7eiFbQav8AETECtniQPtTDeUZXfGYNIt2+zkvOIr7HfBjHW57m3bJ0ESeL3N LOorvRFQnZjRsh+p6sAe3mUWcN6g89aCaVYCUEWO5tRTuujL9D0x80jmMNQKogExX/aEwMXMU d7liX9w2HhLaFXXM3Druqb2T1j6lT/Wke4+tbtPW3OfpfuF6WcWGj1wuAHlZxyYt4zmk7OTwC LaNhUVKPWgSUWvocAbMquKMqNFWBL2u0qDasApagEjZl11QB5/DsTnG8fFjunmJZv7RK1ID1I WW6XgZKqliYqThUf+Zm5cuOz4pwhwIHAOIUWi5O7CCDp0QJtxlHgJNVep5q0waAxfe0LGzm+R N98zwoMtCD1agrVcmFeCtyD+GkKG55/wUDC9zuH+Q/TFR4bStsL2Eu4typrWTrpCLdWrW6/lQ wddAzBW1yF6EdXX8rqaoY6ViAAQ/zwLou+DgQEVG+eAmBnrBeTscihhaaPj7Da/Rsw7FD3qRW X9NPdNhFxfnGR8wVeKO99vd+yYj2zYU/3kIfFiFgla0FlCLoNzS8zGS0zxjTJBkmuQBSaueDp iiVBcqTqBIzT69BF+SPEr7mDNXEksJDj5yH1Ll4PZb8Mkjujy5495lDl0UH22oHjNo08Emu2q xodongrAL3tZyOeEKXFcA+hbSnI7dQM54E0NtN6UFQVLpv8H7cp8GFdaPC0Wl9UjHvMa7vP09 N+If8JGBYQCCVKUZgv3J/gZPfPqpyA7VRLkEEWGO5rEmFdz6DQkYVjoCBKge+Ra+cz1maC8pT bPHw0GpYwwI0pnhSc5RIfUPEdstN+7BT1ak50J3LtBm7JG2cQpOu3ya6wYwP64wttjMIbwG0S ONZ5gcStTwhJdWqKtpZhehf0rvpZMVIMr08wy2lPaDAmB/btoogtmib/TRPv8Xejo21xiNtrW oQ5x8zSSkC1NjQcN9VaToDmIKhw83EPjBxfma9TFBXAihPS/lNSgwJHfBGNIO9mL8Vp+/s29m UqWJuv6ps/cBpIjEAR5YfuZxcKzmf4Y4pUaxTAKXMOJY4AJytbKP7OI2M3e9ejziZhYeZCtf1 H0pjjpB36Y9AIGVSzxLuLutd8GQtviqS6IBu4rYapNllefoRg9LxybLSTXRafiR2Btvrom8dJ neEudQOHdvR5ysl+h X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> Below find two backtraces with emacs -Q where PRODUCE_GLYPHS here sets >> inhibit_free_realized_faces outside the scope of redisplay_internal >> (that is, while redisplaying_p is nil) such that these will not get >> caught by the unbind form in redisplay_internal. > > Thanks. All of these enter redisplay via echo_area_display. That > calls redisplay_internal, but only after it displays the mini-window. > > However, I had my doubts regarding the accuracy of my mental model. > Namely, the part where I said that inhibit_free_realized_faces should > never be non-zero outside of redisplay. So I looked at the code and > its history, and it turns out I was wrong: the line that sets the flag > in PRODUCE_GLYPHS was there since Emacs 21, and I see the flag set to > non-zero all the way back to Emacs 22.1 (and probably earlier). C-x v l told me it was commit 18155a1d5a93cec23255becab15f26e77cace9e7 Author: Richard M. Stallman Date: Thu Aug 29 14:41:28 2002 +0000 (PRODUCE_GLYPHS): Set inhibit_free_realized_faces when iterator is adding glyphs to a glyph matrix. but I didn't dig any further. > So it sounds like we always were running like that. Therefore, I must > turn the table and ask you to please describe in more detail, > preferably with Lisp snippets to try, how the fact that this flag is > non-zero gets in the way of something we need to do with faces, both > in this bug and the other one you mentioned. I'd like to understand > better how this flag interferes in these use cases. With Bug#40639 and Bug#41071 the situation is simple: The internal border changed face but when we enter init_iterator inhibit_free_realized_faces is true and we don't handle it. Redisplay takes care of the face change for normal frames only when it evaluates their titles and that strange incident is what I used to fix these bugs on master. The situation with the present bug is that I rewrote 'window-text-pixel-size' as DEFUN ("window-text-pixel-size", Fwindow_text_pixel_size, Swindow_text_pixel_size, 0, 6, 0, doc: /* Return the size of the text of WINDOW's buffer in pixels. WINDOW must be a live window and defaults to the selected one. The return value is a cons of the maximum pixel-width of any text line and the maximum pixel-height of all text lines. The optional argument FROM, if non-nil, specifies the first text position and defaults to the minimum accessible position of the buffer. If FROM is t, use the minimum accessible position that starts a non-empty line. TO, if non-nil, specifies the last text position and defaults to the maximum accessible position of the buffer. If TO is t, use the maximum accessible position that ends a non-empty line. The optional argument X-LIMIT, if non-nil, specifies the maximum text width that can be returned. X-LIMIT nil or omitted, means to use the pixel-width of WINDOW's body; use this if you want to know how high WINDOW should be become in order to fit all of its buffer's text with the width of WINDOW unaltered. Use the maximum width WINDOW may assume if you intend to change WINDOW's width. In any case, text whose x-coordinate is beyond X-LIMIT is ignored. Since calculating the width of long lines can take some time, it's always a good idea to make this argument as small as possible; in particular, if the buffer contains long lines that shall be truncated anyway. The optional argument Y-LIMIT, if non-nil, specifies the maximum text height (excluding the height of the mode- or header-line, if any) that can be returned. Text lines whose y-coordinate is beyond Y-LIMIT are ignored. Since calculating the text height of a large buffer can take some time, it makes sense to specify this argument if the size of the buffer is large or unknown. Optional argument MODE-AND-HEADER-LINE nil or omitted means do not include the height of the mode- or header-line of WINDOW in the return value. If it is either the symbol `mode-line' or `header-line', include only the height of that line, if present, in the return value. If t, include the height of both, if present, in the return value. */) (Lisp_Object window, Lisp_Object from, Lisp_Object to, Lisp_Object x_limit, Lisp_Object y_limit, Lisp_Object mode_and_header_line) { struct window *w = decode_live_window (window); Lisp_Object buffer = w->contents; struct buffer *b; struct it it; struct buffer *old_b = NULL; ptrdiff_t start, end, pos; struct text_pos startp; void *itdata = NULL; int c, max_x = 0, max_y = 0, x = 0, y = 0; CHECK_BUFFER (buffer); b = XBUFFER (buffer); if (b != current_buffer) { old_b = current_buffer; set_buffer_internal (b); } if (NILP (from)) start = BEGV; else if (EQ (from, Qt)) { start = pos = BEGV; while ((pos++ < ZV) && (c = FETCH_CHAR (pos)) && (c == ' ' || c == '\t' || c == '\n' || c == '\r')) start = pos; while ((pos-- > BEGV) && (c = FETCH_CHAR (pos)) && (c == ' ' || c == '\t')) start = pos; } else start = clip_to_bounds (BEGV, fix_position (from), ZV); if (NILP (to)) end = ZV; else if (EQ (to, Qt)) { end = pos = ZV; while ((pos-- > BEGV) && (c = FETCH_CHAR (pos)) && (c == ' ' || c == '\t' || c == '\n' || c == '\r')) end = pos; while ((pos++ < ZV) && (c = FETCH_CHAR (pos)) && (c == ' ' || c == '\t')) end = pos; } else end = clip_to_bounds (start, fix_position (to), ZV); if (!NILP (x_limit) && RANGED_FIXNUMP (0, x_limit, INT_MAX)) max_x = XFIXNUM (x_limit); if (NILP (y_limit)) max_y = INT_MAX; else if (RANGED_FIXNUMP (0, y_limit, INT_MAX)) max_y = XFIXNUM (y_limit); /* Recompute faces if needed. */ if (face_change || XFRAME (w->frame)->face_change) { Lisp_Object window_header_line_format = window_parameter (w, Qheader_line_format); Lisp_Object window_tab_line_format = window_parameter (w, Qtab_line_format); Lisp_Object window_mode_line_format = window_parameter (w, Qmode_line_format); if (((EQ (mode_and_header_line, Qheader_line) || EQ (mode_and_header_line, Qt)) && !EQ (window_header_line_format, Qnone) && (!NILP (window_header_line_format) || !NILP (BVAR (current_buffer, header_line_format)))) || ((EQ (mode_and_header_line, Qtab_line) || EQ (mode_and_header_line, Qt)) && !EQ (window_tab_line_format, Qnone) && (!NILP (window_tab_line_format) || !NILP (BVAR (current_buffer, tab_line_format)))) || ((EQ (mode_and_header_line, Qmode_line) || EQ (mode_and_header_line, Qt)) && !EQ (window_mode_line_format, Qnone) && (!NILP (window_mode_line_format) || !NILP (BVAR (current_buffer, mode_line_format))))) { if (face_change) { face_change = false; XFRAME (w->frame)->face_change = 0; free_all_realized_faces (Qnil); } else { XFRAME (w->frame)->face_change = 0; free_all_realized_faces (w->frame); } } } itdata = bidi_shelve_cache (); SET_TEXT_POS (startp, start, CHAR_TO_BYTE (start)); start_display (&it, w, startp); /* It makes no sense to measure dimensions of region of text that crosses the point where bidi reordering changes scan direction. By using unidirectional movement here we at least support the use case of measuring regions of text that have a uniformly R2L directionality, and regions that begin and end in text of the same directionality. */ it.bidi_p = false; int move_op = MOVE_TO_POS | MOVE_TO_Y; int to_x = -1; if (!NILP (x_limit)) { it.last_visible_x = max_x; /* Actually, we never want move_it_to stop at to_x. But to make sure that move_it_in_display_line_to always moves far enough, we set to_x to INT_MAX and specify MOVE_TO_X. */ move_op |= MOVE_TO_X; to_x = INT_MAX; } void *it2data = NULL; struct it it2; SAVE_IT (it2, it, it2data); x = move_it_to (&it, end, to_x, max_y, -1, move_op); /* We could have a display property at END, in which case asking move_it_to to stop at END will overshoot and stop at position after END. So we try again, stopping before END, and account for the width of the last buffer position manually. */ if (IT_CHARPOS (it) > end) { end--; RESTORE_IT (&it, &it2, it2data); x = move_it_to (&it, end, to_x, max_y, -1, move_op); /* Add the width of the thing at TO, but only if we didn't overshoot it; if we did, it is already accounted for. Also, account for the height of the thing at TO. */ if (IT_CHARPOS (it) == end) { x += it.pixel_width; it.max_ascent = max (it.max_ascent, it.ascent); it.max_descent = max (it.max_descent, it.descent); } } if (!NILP (x_limit)) { /* Don't return more than X-LIMIT. */ if (x > max_x) x = max_x; } /* Subtract height of header-line which was counted automatically by start_display. */ y = it.current_y + it.max_ascent + it.max_descent - WINDOW_TAB_LINE_HEIGHT (w) - WINDOW_HEADER_LINE_HEIGHT (w); /* Don't return more than Y-LIMIT. */ if (y > max_y) y = max_y; if (EQ (mode_and_header_line, Qtab_line) || EQ (mode_and_header_line, Qt)) { Lisp_Object window_tab_line_format = window_parameter (w, Qtab_line_format); if (!EQ (window_tab_line_format, Qnone) && (!NILP (window_tab_line_format) || !NILP (BVAR (current_buffer, tab_line_format)))) /* Re-add height of tab-line as requested. */ y = y + display_mode_line (w, TAB_LINE_FACE_ID, NILP (window_tab_line_format) ? BVAR (current_buffer, tab_line_format) : window_tab_line_format); } if (EQ (mode_and_header_line, Qheader_line) || EQ (mode_and_header_line, Qt)) { Lisp_Object window_header_line_format = window_parameter (w, Qheader_line_format); if (!EQ (window_header_line_format, Qnone) && (!NILP (window_header_line_format) || !NILP (BVAR (current_buffer, header_line_format)))) /* Re-add height of header-line as requested. */ y = y + display_mode_line (w, HEADER_LINE_FACE_ID, NILP (window_header_line_format) ? BVAR (current_buffer, header_line_format) : window_header_line_format); } if (EQ (mode_and_header_line, Qmode_line) || EQ (mode_and_header_line, Qt)) { Lisp_Object window_mode_line_format = window_parameter (w, Qmode_line_format); if (!EQ (window_mode_line_format, Qnone) && (!NILP (window_mode_line_format) || !NILP (BVAR (current_buffer, mode_line_format)))) /* Add height of mode-line as requested. */ y = y + display_mode_line (w, CURRENT_MODE_LINE_FACE_ID (w), NILP (window_mode_line_format) ? BVAR (current_buffer, mode_line_format) : window_mode_line_format); } bidi_unshelve_cache (itdata, false); if (old_b) set_buffer_internal (old_b); return Fcons (make_fixnum (x), make_fixnum (y)); } This takes any face change into consideration and works. But it obviously disregards inhibit_free_realized_faces and so I'm not sure whether it's TRT (rather, I'm quite confident that it is not TRT). At the very least I probably should set windows_or_buffers_changed. There is this comment in redisplay_internal /* If face_change, init_iterator will free all realized faces, which includes the faces referenced from current matrices. So, we can't reuse current matrices in this case. */ if (face_change) windows_or_buffers_changed = 47; which hints at that (without considering that f->face_change is not handled there). > Thanks (and sorry for spreading misinformation: I was somehow > confident that it was myself who added the setting of > inhibit_free_realized_faces in PRODUCE_GLYPHS, but the truth is that > it was Gerd, long ago). Nevertheless, the fact that inhibit_free_realized_faces is true when entering the iterator after a face change is IMO a bug. We apparently always run the iterator with the old faces first. Only after we have (incidentally?) detected some change that forces us to "retry", we have redisplay set inhibit_free_realized_faces to false itself and the face change will get applied in the next iteration. If so, the outcome of the previous iterations gets lost if a face changed there. Does such a strategy give us any gains? Again, the question I tried to ask earlier was: Does a current matrix in between two redisplays rely on the old realized faces? If so, the answer is that inhibit_free_realized_faces should be always true but for the small window within retrying in redisplay_internal. And maybe somewhere at the beginning of redisplay when a face change occurred for the window's frame and we clear all matrices therefore and avoid any redisplay optimizations. In either case, it strikes me as a strange idea that redisplay_internal saves and restores the value of a variable which is apparently always true when it is entered (I suppose redisplay_internal is not re-entrant given /* I don't think this happens but let's be paranoid. */ if (redisplaying_p) return; ) but maybe there are exceptions I don't know. martin From debbugs-submit-bounces@debbugs.gnu.org Tue May 05 13:11:49 2020 Received: (at 38181) by debbugs.gnu.org; 5 May 2020 17:11:49 +0000 Received: from localhost ([127.0.0.1]:37246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW16i-0005NG-Ru for submit@debbugs.gnu.org; Tue, 05 May 2020 13:11:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jW16h-0005N2-So for 38181@debbugs.gnu.org; Tue, 05 May 2020 13:11:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58727) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jW16c-0004uL-2a; Tue, 05 May 2020 13:11:42 -0400 Received: from [176.228.60.248] (port=2976 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jW16b-00009b-Bj; Tue, 05 May 2020 13:11:41 -0400 Date: Tue, 05 May 2020 20:11:21 +0300 Message-Id: <83v9lal32e.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-Reply-To: <86491f07-ed68-2880-17a0-a60ed40d5059@gmx.at> (message from martin rudalics on Tue, 5 May 2020 18:57:06 +0200) Subject: Re: bug#38181: Actual height of mode-line not taken into account 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Tue, 5 May 2020 18:57:06 +0200 > > With Bug#40639 and Bug#41071 the situation is simple: The internal > border changed face but when we enter init_iterator > inhibit_free_realized_faces is true and we don't handle it. Why do we need to enter init_iterator when the border face changes? And why do we need init_iterator to handle the face change? Thanks for the rest, I will look at that soon. From debbugs-submit-bounces@debbugs.gnu.org Wed May 06 02:50:16 2020 Received: (at 38181) by debbugs.gnu.org; 6 May 2020 06:50:16 +0000 Received: from localhost ([127.0.0.1]:38216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWDsl-0000tC-UN for submit@debbugs.gnu.org; Wed, 06 May 2020 02:50:16 -0400 Received: from mout.gmx.net ([212.227.17.21]:44009) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWDsk-0000sw-8f for 38181@debbugs.gnu.org; Wed, 06 May 2020 02:50:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588747807; bh=AEn/hwJsXK1LJBOGsvDd985Qr39UN23RQ7rzaefmfUY=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=jYJ7J4fODFTptdxOiAGiSNA1EmmGs8z1HiXvus09GUuLJu+0fIJiqdcIr5w8nOeVV T634ifN71tYRWJ7M4t6Fom0yFZdDe1m5g+oDmFoLP5yVQsqH2MycV0RzNnMC8DjptB xs5WSzrwfQfiL2u72tiPd+NZXCmxQnt8iMS3Y4KU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([212.95.5.196]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MEFzx-1jOpUw0g69-00AFBe; Wed, 06 May 2020 08:50:07 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii 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> <83v9lal32e.fsf@gnu.org> From: martin rudalics Message-ID: Date: Wed, 6 May 2020 08:50:06 +0200 MIME-Version: 1.0 In-Reply-To: <83v9lal32e.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:1Fpg8kha089VtACAdu2J4Osmg9RRpbno4Vu0t1JpVONxG9qixLe qSQiYPcYxGdqZ0Ov5w5KKzxwIC83S7YcPnlyV46a6bDuJS3cLAlbqw37QMhZ89bS3Mn4MR8 LcaiV1fxEiwLmwpyhgjpuHbOQHyoMSS0YJVkW7SLjsw0p4IsGgm2O6w7sWD2yteXHAkLNeH 9i7+xcFmlxV+jMwPdOE7A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Fu0++NgVoFw=:Ln+YOYrZByDwj5dfbcpj1E 06/exlWvUtpPxXcdSsxbaUF/daLN5Qkk8xXOOfHpolIoM1RriD6ZSvSmL8ofdxJF5P1V5bmLx RLfwOFkIZ1yLhztAiQoVUkE5Q2V2P9feZxLYBmrPNaFc9eQ9iEqJKYOkRufP6HoHOv4DeH6AK CngUSSWzjyJKMALOQIwDDOZkRUS3fjJnMsPRQpYzxi8GZjX+AuzD1rBd901VjbJyHzXZ+UsWs 3Q1RK6+MFnM8ajvBeID+gnH/H4JqfMbGWTaAcofC7XCH5NgiyDlw5TGUosXb0vO12NBGMKXNe YJ82phyAS7E54CKWfcdpq4kkwJ+jBRKn+97XvYjtVFCos+Zx6G7oXJ5aB7SYzXj49jKoTbHVm LlKBbwInvSulorjE+p+PaL7xQwdaSj0nUZ3lkC4h4qWOHtW5BAgIxkKGFgVoCrwCHXeEmkqlI 2fQlcQ34V1muCG4HAW+uJu7OtMSG2psaEZmeWuVEnNbpg6m8H7zQigDCyymTFrgE2NY/YAeGN aVn9ahbQUnc92caO5KjmVJqMriU5517huJa4SQ2XhXJ8UceAFr+FqgV+xB4nCTrCblEovPjqY sg0CvfddmxJ87VzyUIYeVJwyAdO0jE5xD5xCuCwC32LtjSKSoCTw+sAjKobt8dbI2fuQqRCUL w8jiYTW5AQ7sXkco8mO/LGyb7cuMp4ffP+/WsXLXUcTdeatD5j4slvSxN02ovoMNijmUhgMbO wusQFn3DxSc7fX9qtZONfgGW3z8lXu1wy60a+wgBWEXVmOzXDpHhfIUp+oRmEPKZAH/XY8iIT 8rDRPJsHZzqp34dXsZOTJwh6XNWhr8DadO4pV4ILotUyCcRBWd6IW1ckQ+PXgEfArAJ4PfFPc vFgrjs63Nyz4KK1PsEHIC+KEXaST/dl7sIJR/1b5HDEJzUT+K5K37ocxiapKKUdOnuq0MU8Z+ ypeI0WBzti8Ibocwq390vUAm+1bBr5jm7+J1+qbH9CvQ3WEGY9fGiMd4V8fH+aTmV8EhFdUxz qBUqNpG3X8vchTrhreNHCeejWzazobv7996SgaHiK+JW7NEqvRl2Xd8224XBy4xzIa3wJKOCQ WihGuIHo/N6q4CoA6tEfIiv14TwL3TIHWdXFUygS88d8/INS+ox9+4s47kWShCTWoO8KORx8g eQBT934H6h3ThquoOjb0yTMta/ItkghsqIj6aw9W4z+Y3W3qvgh/6pIORvOCI59ykVqXxUNv9 wnZWQqvccJDt1NBK8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Why do we need to enter init_iterator when the border face changes? > And why do we need init_iterator to handle the face change? If our only tool is a hammer ... Or should we call 'clear-face-cache' or 'redraw-display' whenever changing the border face? martin From debbugs-submit-bounces@debbugs.gnu.org Wed May 06 05:28:05 2020 Received: (at 38181) by debbugs.gnu.org; 6 May 2020 09:28:05 +0000 Received: from localhost ([127.0.0.1]:38543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWGLV-00077V-6H for submit@debbugs.gnu.org; Wed, 06 May 2020 05:28:05 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWGLS-00076d-9e for 38181@debbugs.gnu.org; Wed, 06 May 2020 05:28:02 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51441) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jWGLM-0000ot-EP; Wed, 06 May 2020 05:27:56 -0400 Received: from [176.12.151.155] (port=55147 helo=[10.161.128.100]) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1jWGLL-00078B-1B; Wed, 06 May 2020 05:27:55 -0400 Date: Wed, 06 May 2020 12:27:52 +0300 User-Agent: K-9 Mail for Android In-Reply-To: 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> <83v9lal32e.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: bug#38181: Actual height of mode-line not taken into account To: martin rudalics From: Eli Zaretskii Message-ID: <11D1C839-3EC3-4CAA-A6C9-3FC4E2A2B265@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On May 6, 2020 9:50:06 AM GMT+03:00, martin rudalics wr= ote: > > Why do we need to enter init_iterator when the border face changes? > > And why do we need init_iterator to handle the face change? >=20 > If our only tool is a hammer =2E=2E=2E Or should we call 'clear-face-cac= he' > or > 'redraw-display' whenever changing the border face? >=20 > martin I simply don't yet understand why updating the frame decorations that have= nothing to do with text layout needs init_iterator to run=2E What am I mi= ssing? Redisplay doesn't in general redraw the whole frame, it only redraw= s windows=2E From debbugs-submit-bounces@debbugs.gnu.org Wed May 06 05:44:36 2020 Received: (at 38181) by debbugs.gnu.org; 6 May 2020 09:44:37 +0000 Received: from localhost ([127.0.0.1]:38568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWGbU-0007X7-CT for submit@debbugs.gnu.org; Wed, 06 May 2020 05:44:36 -0400 Received: from mout.gmx.net ([212.227.15.18]:56737) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWGbR-0007Wt-Gh for 38181@debbugs.gnu.org; Wed, 06 May 2020 05:44:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588758266; bh=yzTllaGJfhjIzobJOIQgznxtxI6fOgJIfnTq5ltjw3o=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=idJ0BvL0LvAt0DFVCw9/2FYiDRSQ1EhyPcphyQPXlOs9kZHy2YkVaLTG8LQRrbSE7 Mo+8lytgg/pb2NA6SDLMliVRyzcGvYfZ9NxtQG424AVpd5DbVmJJA/ODvDphXaVc+/ MjRmFEWtAOVBaKf7tkRT9NMf5ax8TOVWoK0gwcRA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([212.95.5.107]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MGz1V-1jIqK12cNP-00E5Dj; Wed, 06 May 2020 11:44:26 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii 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> <83v9lal32e.fsf@gnu.org> <11D1C839-3EC3-4CAA-A6C9-3FC4E2A2B265@gnu.org> From: martin rudalics Message-ID: <22f9e918-63b1-fdb5-1d59-ee977813d6ca@gmx.at> Date: Wed, 6 May 2020 11:44:25 +0200 MIME-Version: 1.0 In-Reply-To: <11D1C839-3EC3-4CAA-A6C9-3FC4E2A2B265@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:PpsAFVrbi0wDaqRUpz7x8S1iXovRBJnUnU+UbSV3l4u2G650hQ4 YueMimZ4qHHdx7HApzRLNJcppXi1UbwUsdjDFdOrjakvoNKG08uePpOhyU8Dek96xYBn66m xjfaS2Wv98jIWnKwL+8cRvzSpk4Mm1rejRFy6Wnaj3l1yTDgl3I5Kpo0jwTebrQCtdR7R2C qxj5dDv829GwdF1pbMOZA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:r7R56js+bVk=:Bem78YKlwCzkTwy2QU4J6d HjYSBrrZOYrVE4LKvcU02DvPAJx8r7k3RM9vBJVdNrSUfbMOchfXd2lvZLf7a7GcN/bnnekBJ qv4izFtCo5v78XJ2SQPMReF2fo5C1poVF7pz9LJ6s/PCOqROIbZ5ImhBSMzCUIxqY3oMq8Ey1 P4FRODK//9ryKjqP9zTW6oOzIllJOD6nlMYolUwOt4hlmFC2/EvWE9ANJMm/sKYbXGqoQeCpl LnYAO3MZICKYv4B19REw9cqNy45o/jzTv+BLEnYk/VYF9sorDxdHvryN4IHUDcEmgbV09q/q1 qPbDMOrUazQlA15VHgS+JneFK+qly3fcztDB+wqRwIIi8S4Z7YFU9vujqclZvK3Ktvb41gHb1 9ZbnXjrif6zhVaTn6h3jBV/R2YOdawD0ZMRpWgFt63fBzY5ouK48EC97z7jVarMkawrynLrjV xBiGyRoMPI2cKVOJGm0KozZHbijQAOy1cyUPvRO48QqTO5fuWXnP8MzWmRy0D60JpeXSohY68 CJkMnQnu6tqzBFyO0h2I2MkgvpwWKRds2x4jz7kAEssT1BH8EXq+WXc6mX84une2bFkYKx0x4 /bhT5lwy5lX8Qg3dlNBdURyB1JiA3lFbiM24Z8sHYYzDMNwdX30B+OKcdlCZWYwB+XJ4h2QPc fAZK3VMwzwaGVksTl7J1vQTfHUxYDUJHaOmxCdDd/6NIkpZZ5wf0eTtzOPd733cI6Awr+inCc s+BBC2Pc5hRU8ZwD9xU40qinblmfJCOp5/ZAAPg0/ATsiCpOJYInwI1zll+unMyoEqAiWLfmT CuRLOhoRaOjI9C6Wr96+rIl1lzr6cfleZtH3IV6f0xF55PhwFWk+1ZDcSRaMVCbko6U5YoVyC nRFnFiQGU7bLI2Ei2UzHxQkgLlhr6OxhZwaBVSiJVRAds+j4MJGFe0CKHcFjBZLUpI9tcDSzf oGMNVweflHu/+lb9+ielWomj+ZIqxoJK+w0AqQ2NpUU90UB52J0eNAMcrtJxwTYcXfdWVUamX 204bblQ//0GlHbUEksMD1amrEGX7acnYSnuF09UfwncXgKckhK7/Du4eSTHfdmn7V7RFIStAj HYmofyOJNvvv1eVSSIExJ2wLQCtmmAR0r/LBdTiDXYh5TsuziqyKlZq4aFn7aY4Yjf/IwrXt1 w8j+4tS1dvAQh6ppHFTPCqVsnF+pEtB5mv/c2RdmdImRRs33EwY9xn3gqhN/ovfItysJeXUr6 SsPu6POoOnC1uMkry X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > I simply don't yet understand why updating the frame decorations that > have nothing to do with text layout needs init_iterator to run. What > am I missing? Redisplay doesn't in general redraw the whole frame, it > only redraws windows. I don't understand either. Fact is, that init_iterator is the only agent within redisplay that frees realized faces and causes the new border face to be realized. martin From debbugs-submit-bounces@debbugs.gnu.org Wed May 06 10:16:53 2020 Received: (at 38181) by debbugs.gnu.org; 6 May 2020 14:16:53 +0000 Received: from localhost ([127.0.0.1]:40782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWKqz-0002GL-MV for submit@debbugs.gnu.org; Wed, 06 May 2020 10:16:53 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWKqx-0002G9-OO for 38181@debbugs.gnu.org; Wed, 06 May 2020 10:16:52 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55901) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jWKqr-0000pL-J4; Wed, 06 May 2020 10:16:45 -0400 Received: from [176.228.60.248] (port=4132 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jWKqq-0005jN-FM; Wed, 06 May 2020 10:16:45 -0400 Date: Wed, 06 May 2020 17:16:28 +0300 Message-Id: <83h7wtkv2b.fsf@gnu.org> From: Eli Zaretskii To: rudalics@gmx.at In-Reply-To: <11D1C839-3EC3-4CAA-A6C9-3FC4E2A2B265@gnu.org> (message from Eli Zaretskii on Wed, 06 May 2020 12:27:52 +0300) Subject: Re: bug#38181: Actual height of mode-line not taken into account 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> <83v9lal32e.fsf@gnu.org> <11D1C839-3EC3-4CAA-A6C9-3FC4E2A2B265@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 06 May 2020 12:27:52 +0300 > From: Eli Zaretskii > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > > I simply don't yet understand why updating the frame decorations that have nothing to do with text layout needs init_iterator to run. What am I missing? Redisplay doesn't in general redraw the whole frame, it only redraws windows. Answering my own question: because the clear_under_internal_border method, which redraws the internal border, is called from redisplay_internal. From debbugs-submit-bounces@debbugs.gnu.org Wed May 06 10:44:56 2020 Received: (at 38181) by debbugs.gnu.org; 6 May 2020 14:44:56 +0000 Received: from localhost ([127.0.0.1]:40816 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWLI7-0002yl-L8 for submit@debbugs.gnu.org; Wed, 06 May 2020 10:44:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58566) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWLI5-0002yY-ND for 38181@debbugs.gnu.org; Wed, 06 May 2020 10:44:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56353) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jWLHz-0004uv-RN; Wed, 06 May 2020 10:44:47 -0400 Received: from [176.228.60.248] (port=1845 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jWLHz-0001nB-7F; Wed, 06 May 2020 10:44:47 -0400 Date: Wed, 06 May 2020 17:44:29 +0300 Message-Id: <83ftcdktrm.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-Reply-To: <86491f07-ed68-2880-17a0-a60ed40d5059@gmx.at> (message from martin rudalics on Tue, 5 May 2020 18:57:06 +0200) Subject: Re: bug#38181: Actual height of mode-line not taken into account 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Tue, 5 May 2020 18:57:06 +0200 > > > So it sounds like we always were running like that. Therefore, I must > > turn the table and ask you to please describe in more detail, > > preferably with Lisp snippets to try, how the fact that this flag is > > non-zero gets in the way of something we need to do with faces, both > > in this bug and the other one you mentioned. I'd like to understand > > better how this flag interferes in these use cases. > > With Bug#40639 and Bug#41071 the situation is simple: The internal > border changed face but when we enter init_iterator > inhibit_free_realized_faces is true and we don't handle it. Can you show the backtrace from this call to init_iterator? If it is called directly or indirectly from redisplay_internal, the inhibit_free_realized_faces flag should be reset to zero. So I'm guessing it is called in some other way. That other way is not necessarily the situation which should solve the delayed face refreshing, since the corresponding parts of the frame will not be redrawn until we enter redisplay_internal anyway, right? Or am I missing something. > if (face_change) > { > face_change = false; > XFRAME (w->frame)->face_change = 0; > free_all_realized_faces (Qnil); > } > else > { > XFRAME (w->frame)->face_change = 0; > free_all_realized_faces (w->frame); > } You don't really need to free the faces everywhere here, only for the window W's frame, right? I think we shouldn't throw away face caches of other frames in this situation, it's too radical. > This takes any face change into consideration and works. But it > obviously disregards inhibit_free_realized_faces and so I'm not sure > whether it's TRT (rather, I'm quite confident that it is not TRT). I think the only situation where it can hurt is when this code is called while redisplay_internal runs. IOW, we need to test the value of redisplaying_p. > At the very least I probably should set windows_or_buffers_changed. > There is this comment in redisplay_internal > > /* If face_change, init_iterator will free all realized faces, which > includes the faces referenced from current matrices. So, we > can't reuse current matrices in this case. */ > if (face_change) > windows_or_buffers_changed = 47; > > which hints at that (without considering that f->face_change is not > handled there). The call to free_all_realized_faces invalidates the current matrices of all the windows on the frame, so the stale face IDs will not be used after that on that frame, and therefore nothing else needs to be done in that case. If _all_ the face caches are discarded on all frames, we need windows_or_buffers_changed to force redisplay_internal consider more than just the selected frame. So if you modify your code to free faces only on the frame of the window for which you compute the mode-line height, the problem with windows_or_buffers_changed will disappear. > Nevertheless, the fact that inhibit_free_realized_faces is true when > entering the iterator after a face change is IMO a bug. We apparently > always run the iterator with the old faces first. Only after we have > (incidentally?) detected some change that forces us to "retry", we have > redisplay set inhibit_free_realized_faces to false itself and the face > change will get applied in the next iteration. If so, the outcome of > the previous iterations gets lost if a face changed there. Does such a > strategy give us any gains? I don't think I follow. redisplay_internal resets the inhibit_free_realized_faces flag to zero near its beginning. It is true that we also reset it when we retry, but the first try doesn't bypass this resetting. Am I missing something? > Again, the question I tried to ask earlier was: Does a current matrix in > between two redisplays rely on the old realized faces? Of course it does. The glyph matrices don't hold any face information, they only hold the ID of each face, and the ID is just the index of the face's cache slot. If the face cache is thrown away, we will not be able to use the current matrix. The current matrix is used for the following purposes: . outside of the redisplay cycle, for redisplaying portions of windows when we get expose events -- in this case we simply write to the glass the relevant portions of the matrix, without reproducing it . during a redisplay cycle, for decisions about redisplay optimizations . at the end of a redisplay cycle, for comparison with the desired matrix, which is needed for figuring out what to write to the glass For the first purpose, we have the following defenses: . expose_frame: if (FRAME_FACE_CACHE (f) == NULL || FRAME_FACE_CACHE (f)->used < BASIC_FACE_ID_SENTINEL) { redisplay_trace ("expose_frame no faces\n"); return; } . expose_window (called by expose_frame): if (w->current_matrix == NULL) return false; So this case is covered, i.e. you can call free_all_realized_faces, and the next expose event will be handled correctly. 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. So I think each function that might need to notice face changes as soon as they happened, should be able to reset inhibit_free_realized_faces, provided that (a) it makes sure redisplaying_p is zero, and (b) it only does that if necessary and for a single frame. The latter part is because clearing the face cache will cause all the move_it_* functions to work harder, because they will have to recompute all the faces. > If so, the answer is that inhibit_free_realized_faces should be > always true but for the small window within retrying in > redisplay_internal. I don't think I agree, but maybe I'm missing something. > In either case, it strikes me as a strange idea that redisplay_internal > saves and restores the value of a variable which is apparently always > true when it is entered (I suppose redisplay_internal is not re-entrant > given > > /* I don't think this happens but let's be paranoid. */ > if (redisplaying_p) > return; redisplay_internal is non-reentrant, but I see no harm in restoring the value on exit. From debbugs-submit-bounces@debbugs.gnu.org Thu May 07 04:34:54 2020 Received: (at 38181) by debbugs.gnu.org; 7 May 2020 08:34:55 +0000 Received: from localhost ([127.0.0.1]:42028 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWbza-0002i9-NO for submit@debbugs.gnu.org; Thu, 07 May 2020 04:34:54 -0400 Received: from mout.gmx.net ([212.227.15.18]:59603) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWbzZ-0002ht-Mn for 38181@debbugs.gnu.org; Thu, 07 May 2020 04:34:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588840487; bh=2mcBnnUPeHcAIHUVXeDIZptqi2JbczZd7KIXDg3TBJE=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=IWTuJl9/EyR87xcff4P7XvXmqAY/DYA0owUpjmM6olx2BZvcB/56VxRoB5gxYt7bV 8vm3TO+Mwd79HJfoftsWo4bYdtyzeiw5DZGV4DsBmz13Vskl2oAmV8/GVQJItJubAf 6KF3DN2Zmn3ZqBNS3aXfIpQolVZ5wpKa1LPm0jpg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([212.95.5.89]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1McpNo-1iwjH30EDa-00a1Ce; Thu, 07 May 2020 10:34:47 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii 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> <83v9lal32e.fsf@gnu.org> <11D1C839-3EC3-4CAA-A6C9-3FC4E2A2B265@gnu.org> <83h7wtkv2b.fsf@gnu.org> From: martin rudalics Message-ID: <6ca19f2b-a7c9-1574-63b1-e66fce30633e@gmx.at> Date: Thu, 7 May 2020 10:34:40 +0200 MIME-Version: 1.0 In-Reply-To: <83h7wtkv2b.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:qWBsfI0TJR6JoE6JLMkn9xhgCpz9vEiaCqM+5uXpphXI2Fu8roC rJqk4z9Opf0Gx3+KcdCCmTBfz2SslmWHFtrjLIBZjJSH71uxDGql+wMHDPlueLE8S6fR+Og 6/eTUTwPu2mTwpRirtWoV8FLmYKbQoN5BcBQrPzQfIWAhbHZlnJiF6a61NvHylNYYeCsOV7 ChG73ALBbMq/iZYmbfEEA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:NgSrrR3ZJc0=:hro+IpKE67PvxolpkhsFre WyCMS2y7nTtgYAu7UEyAJfm2b2t8Ii7YVvF4b+Zx5yc90vh5R3x8BrZRIJeG4g8/uIgCBFWle pl6iPf7T2YkRVaPqXexarACEf/2uMqW+ZwI5Y1vb/IR7wEq8Gdz5TuI7RMeO0M9WotxKIxspc JkzR9NMifMdSOpD0xoiPkcuUuYJ6DnD+S6EiaUDNmOe7edpbszrC/KmhOr9OF8uGpWotumf9N ORIdZwWLdsyPIpR0lKp69shGrHu10Clm/QXIXE/IyGDEKpx9ISdVKwmNqTYwgyzrn39H5qCKN W1nrMbXR7/Ca7gPoy1oCqGqy5qv5gKYUCbjnRnWfe4T9Zy3ndMSs0vAciFoYSjJKlssSrTtwe 9VpdwPsV/04hrXhxVC0GEkl5nyxwYmCt1SeLGjDU0hiZRP0ZZMSqziTLlm7Onq1G+P5jf71px rfGpbslzNaswxqOOwJlORR3eXownkW/zJAKAvwETFXD8YcUuoWjCWmqTDV/s0OgK8xw8z/UmY S1w5DV+NX7g+aTTklvueDvEqpMc4YxULpThywJVV87dvMiKUAEnBc+EIhUeiEkW5MEHIQ/kC0 KVXFVXladZS8iszbUOwhr1buNKUQrKzH4t+0NFiXGLSrMuIkRmr/8Z/P3IwQ0QdAfxwg0aPsQ FLG/hKKDdFPKDFuliLed4yhfIS2jKYYTJTTULu4Hw3qQXdPZ6qABRuWnjSV3ua4j5M9yz0S4u Sxrqz34p30+nMeMA797YLa/arcI5Vm40T0mjnG2QL6q6l5VXDZF7107yjwWgOilFKdHcyeLeH YnioP0Pps2aYIBFHEut4/Kc/Fl9uO3nWMGUzJl1Q3jL89R2MUEjkLKd5Y1Rm2INp4AQFiAa7t wQBchJPm1tHKXF4usPbOcfZQEJEoYG7veedana6WvNSbN2Kt6Bvs66xHo1nIdhPzYetGcmT+r xsiHfIVdS7tJ5lUR51uY0MgYi5o1zqVa/NMc/lBOTX/vh23WQy85GDehQZ8+rUyynQpY7cEx5 uMp2KN3hAFEvzZk393k8/ZKjiPPhf10BnNOUg3UVcMWIvpYeUor4KZPyzTXujc25JnWOKXddH 273l6eFGvfwkZAStgXcZxMgr4q3vvpDJZuEIZbipr3xA5svO0PlGu/+HvQutecoEie1BRrQZd cBdhY65AAITSBNfHTX8O8+GNyFd0zkQiIB7t6gLnYpCNuKOD/t4hlikn1TiiCHzvoyaiXUw/E vQNb0vWYJWoIs+byu X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> I simply don't yet understand why updating the frame decorations that have nothing to do with text layout needs init_iterator to run. What am I missing? Redisplay doesn't in general redraw the whole frame, it only redraws windows. > > Answering my own question: because the clear_under_internal_border > method, which redraws the internal border, is called from > redisplay_internal. That's only a secondary issue, I think. clear_under_internal_border is called from so many places. The real reason is, as I tried to explain before, to update the basic faces, however that is accomplished. martin From debbugs-submit-bounces@debbugs.gnu.org Thu May 07 04:35:03 2020 Received: (at 38181) by debbugs.gnu.org; 7 May 2020 08:35:03 +0000 Received: from localhost ([127.0.0.1]:42031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWbzi-0002iq-Tt for submit@debbugs.gnu.org; Thu, 07 May 2020 04:35:03 -0400 Received: from mout.gmx.net ([212.227.15.15]:41295) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWbzg-0002iA-5L for 38181@debbugs.gnu.org; Thu, 07 May 2020 04:35:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588840493; bh=MOTGxhTUx6U+IZdtGEghtMpIbRH258bseDvprT776Jw=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=c/Wago0Jwj6G8P+4L0huyKO10M42Nwko17fde/mlhgWPhfm5fXysHFw5lVsa1U/Hn c0zeRau2yylG/+hcKdvCpqzDnpE5r3T7QY6olI9FqTGHZvtcHhpMfvxWWSTGTY4NXR L2Y8SQnxHLL36tD4g2sHOCAXMUDgkRqy4SBPVGx4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([212.95.5.89]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MmDIo-1ioVnZ2lzk-00iEiW; Thu, 07 May 2020 10:34:53 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii 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> From: martin rudalics Message-ID: <6713049b-49e2-64ca-902d-1f972952f590@gmx.at> Date: Thu, 7 May 2020 10:34:53 +0200 MIME-Version: 1.0 In-Reply-To: <83ftcdktrm.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:iHiC1EofanmQ1vTFXcd+B5yW4MX5PsgWHtf+K1gruBs92YEp99f Vx3Gr6VNPW3MG6qXPZZgO1RZQzaWCq4mrtVvoN8I7NDsR1ilOHpTyzKAi+J1zE4o/tzzwIX cyrOPoSxpVCGGs6WvkXemaAZg531+3xJXP6xADxy/rAQiN+mpRBk4ONE8cWF/WgEHKUfJoz eE7zrukJWttD/irrO9NoA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:02eakfRHTgQ=:gsAUCbJF1QmjCPTCJpgRKr UbD4mHFSZyrknKLtj8MJxCDIhAl4lm32uPrw/Fh+TYPiA9EhZ68vxGDQ0zlKgBGOoMRye+G6n agqHehy7Iuwy0e91mZZKQTqJXkF/KmIRbF4ubWqlYR5rr4p6Bi+c5VO7g9wfcfk5335cxVriY Dx9agLvjGktwZc0RzfxdFV5Hbu+V78jV7H/D/bjYlcvPx7U3dbUzMhioIKLXmwiLXNUUMLobL QAK3WZIWngxqYIJ41m1C8plk3VfR0+pR9/Ds1yjKoYGHyIqDZeL7pf7HL7aQCa3KnZC2TTjHQ L1/Gy/GOjH1dJKu6kMDkmG4O2yBrJ/U4aDsqYNHUzjjYLIp+iQuJv6b/l53C6+XOiDEIPNqin ez3mIEXlwL3pLmSsA7V42l+ZFSZ454/ovMtVKOGsSzI5s+xwttmROagalyEvRkOl1WoJlSLVH STZkT6jZxzvxiNtBE/rw9RVE1CTiks28v63PYKbkDOfGVuMpui/IiRU5Rfxdv1PvuEKX/giwt Jxwe7f9cfJyvK98mIyF3AQO1XAtWRuAtbmTkr8Td1GHJ1LBvW7WjsBXskayQUZ8uXwkxVBJb5 HJNgNqniqF7yS0ioRJD7GvZ9s5+pBmOac363RfyOx1FK/pQCbAdfKaeI/VliJF+6OkT+pwYzP wOYwZhs3X2nBdCkVc9ZikOWTtHra6tVxL7NSbhYJ0cS31/a2cy1XTRXbYIiJdOxVz0CmUuEGP q+C7Vum1xZ4OMD6LWN5tDaBXlys8OKcX6PyJ4kT88Vyy8IWtV9Iq9K7heROG7mYmFBo5z9WFv 5X0773mMf0LvUtCc3RdiZJ0oSO1FOvA5iWa4cbnilwBY+uMl6xGDQQlO6qoXqKY8dzDYZhlFZ j390eTL1mgHrjbOk/yCzYuJ/3CzsTPL1YDhkg9ZzN9lHWSy6est+AcLn374UqBzQyLyYVZc1F hNFRE6h/GGS3yV15FE6gli1ynHJ3v/kPdCN+fj6FWglj5XBkTa5uNbQ0dhHA6b8c7sKsd1+aK 66j8tObduLOBEIeux2vrF43RaiqzSIMhTL+cPTMMVJhiinjFl5+oiK06y4080lB0Eg9qrBtlE wiCdo0cJXRJoq8XCGq9Q9QGJeN76E//JNbgoiiTHnrDzzfIyTBUMlzfkb4dHyQJwci+CplhZn RDpZnHRGUUH3rDy3JpIkZSi0uSq7fpXgaQNhlChTbO7ZEn89lVBROOyHq6CGL2NivZ3DRkaju J5eHyTS8CulGA5LZd X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> With Bug#40639 and Bug#41071 the situation is simple: The internal >> border changed face but when we enter init_iterator >> inhibit_free_realized_faces is true and we don't handle it. > > Can you show the backtrace from this call to init_iterator? I run emacs -Q and evaluate there the following form (progn (set-face-background 'internal-border "red") (select-window (display-buffer-in-child-frame (get-buffer-create "*scratch*") '((child-frame-parameters . ((left . 100) (top . 100) (height . 10) (width . 20) (minibuffer . nil) (internal-border-width . 50))))))) Now _if I remove the following two lines_ if ((IT)->glyph_row != NULL) \ inhibit_free_realized_faces = true; \ from PRODUCE_GLYPHS, evaluating the form above does pick up the face triggered by XFRAME (w->frame)->face_change true as #0 0x0000000000463cbf in init_iterator (it=0x7fffffff8c60, w=0x193e060, charpos=1, bytepos=1, row=0x1947f90, base_face_id=DEFAULT_FACE_ID) at ../../src/xdisp.c:2975 #1 0x00000000004652e8 in start_display (it=0x7fffffff8c60, w=0x193e060, pos=...) at ../../src/xdisp.c:3298 #2 0x0000000000497468 in try_window (window=XIL(0x193e065), pos=..., flags=1) at ../../src/xdisp.c:19120 #3 0x00000000004941e9 in redisplay_window (window=XIL(0x193e065), just_this_one_p=false) at ../../src/xdisp.c:18544 #4 0x000000000048be75 in redisplay_window_0 (window=XIL(0x193e065)) at ../../src/xdisp.c:16258 #5 0x00000000007af751 in internal_condition_case_1 (bfun=0x48be33 , arg=XIL(0x193e065), handlers=XIL(0x7ffff3e98ee3), hfun=0x48bdfb ) at ../../src/eval.c:1379 #6 0x000000000048bdcd in redisplay_windows (window=XIL(0x193e065)) at ../../src/xdisp.c:16238 #7 0x000000000048a7fb in redisplay_internal () at ../../src/xdisp.c:15706 #8 0x00000000004883f9 in redisplay () at ../../src/xdisp.c:14933 #9 0x000000000064edbd in read_char (commandflag=1, map=XIL(0x17e4f93), prev_event=XIL(0), used_mouse_menu=0x7fffffffe0ff, end_time=0x0) at ../../src/keyboard.c:2493 #10 0x0000000000661ce5 in read_key_sequence (keybuf=0x7fffffffe290, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9553 #11 0x000000000064b283 in command_loop_1 () at ../../src/keyboard.c:1350 #12 0x00000000007af676 in internal_condition_case (bfun=0x64ae07 , handlers=XIL(0x90), hfun=0x64a416 ) at ../../src/eval.c:1355 #13 0x000000000064a9ec in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091 #14 0x00000000007aeb2a in internal_catch (tag=XIL(0xd110), func=0x64a9bf , arg=XIL(0)) at ../../src/eval.c:1116 #15 0x000000000064a98a in command_loop () at ../../src/keyboard.c:1070 #16 0x0000000000649efd in recursive_edit_1 () at ../../src/keyboard.c:714 #17 0x000000000064a0f5 in Frecursive_edit () at ../../src/keyboard.c:786 #18 0x00000000006404fe in main (argc=4, argv=0x7fffffffe788) at ../../src/emacs.c:2054 Lisp Backtrace: "redisplay_internal (C function)" (0x0) (gdb) c With PRODUCE_GLYPHS unaltered, that breakpoint does _not_ trigger. Only if I set frame titles for child frames (as I do on master now) I can get a backtrace like the below #0 0x00000000004821dc in init_iterator (it=0x7fffffffb4a0, w=0x1a4b800, charpos=-1, bytepos=-1, row=0x0, base_face_id=DEFAULT_FACE_ID) at ../../src/xdisp.c:2988 #1 0x00000000004a575b in gui_consider_frame_title (frame=XIL(0x1a5e8f5)) at ../../src/xdisp.c:12447 #2 0x00000000004a5c07 in prepare_menu_bars () at ../../src/xdisp.c:12544 #3 0x00000000004aaeaf in redisplay_internal () at ../../src/xdisp.c:15392 #4 0x00000000004a9aeb in redisplay () at ../../src/xdisp.c:14977 #5 0x0000000000768eb6 in read_char (commandflag=1, map=XIL(0x1c5c3d3), prev_event=XIL(0), used_mouse_menu=0x7fffffffe10f, end_time=0x0) at ../../src/keyboard.c:2493 #6 0x00000000007800e3 in read_key_sequence (keybuf=0x7fffffffe2a0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at ../../src/keyboard.c:9547 #7 0x000000000076549a in command_loop_1 () at ../../src/keyboard.c:1350 #8 0x000000000084133d in internal_condition_case (bfun=0x76501e , handlers=XIL(0x90), hfun=0x76462d ) at ../../src/eval.c:1355 #9 0x0000000000764c03 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1091 #10 0x00000000008407f1 in internal_catch (tag=XIL(0xd200), func=0x764bd6 , arg=XIL(0)) at ../../src/eval.c:1116 #11 0x0000000000764ba1 in command_loop () at ../../src/keyboard.c:1070 #12 0x0000000000764114 in recursive_edit_1 () at ../../src/keyboard.c:714 #13 0x000000000076430c in Frecursive_edit () at ../../src/keyboard.c:786 #14 0x000000000076048f in main (argc=3, argv=0x7fffffffe798) at ../../src/emacs.c:2035 which also picks up the change of the internal border's background. With an unaltered release I can't get init_iterator to notice the face change without, in some clumsy way, switching to that child frame with the mouse or something the like. 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. >> if (face_change) >> { >> face_change = false; >> XFRAME (w->frame)->face_change = 0; >> free_all_realized_faces (Qnil); >> } >> else >> { >> XFRAME (w->frame)->face_change = 0; >> free_all_realized_faces (w->frame); >> } > > You don't really need to free the faces everywhere here, only for the > window W's frame, right? Right. > I think we shouldn't throw away face caches > of other frames in this situation, it's too radical. Agreed. > I think the only situation where it can hurt is when this code is > called while redisplay_internal runs. IOW, we need to test the value > of redisplaying_p. OK. >> At the very least I probably should set windows_or_buffers_changed. >> There is this comment in redisplay_internal >> >> /* If face_change, init_iterator will free all realized faces, which >> includes the faces referenced from current matrices. So, we >> can't reuse current matrices in this case. */ >> if (face_change) >> windows_or_buffers_changed = 47; >> >> which hints at that (without considering that f->face_change is not >> handled there). > > The call to free_all_realized_faces invalidates the current matrices > of all the windows on the frame, so the stale face IDs will not be > used after that on that frame, and therefore nothing else needs to be > done in that case. If _all_ the face caches are discarded on all > frames, we need windows_or_buffers_changed to force redisplay_internal > consider more than just the selected frame. So if you modify your > code to free faces only on the frame of the window for which you > compute the mode-line height, the problem with > windows_or_buffers_changed will disappear. OK. >> Nevertheless, the fact that inhibit_free_realized_faces is true when >> entering the iterator after a face change is IMO a bug. We apparently >> always run the iterator with the old faces first. Only after we have >> (incidentally?) detected some change that forces us to "retry", we have >> redisplay set inhibit_free_realized_faces to false itself and the face >> change will get applied in the next iteration. If so, the outcome of >> the previous iterations gets lost if a face changed there. Does such a >> strategy give us any gains? > > I don't think I follow. redisplay_internal resets the > inhibit_free_realized_faces flag to zero near its beginning. It is > true that we also reset it when we retry, but the first try doesn't > bypass this resetting. Am I missing something? 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. >> Again, the question I tried to ask earlier was: Does a current matrix in >> between two redisplays rely on the old realized faces? > > Of course it does. The glyph matrices don't hold any face > information, they only hold the ID of each face, and the ID is just > the index of the face's cache slot. If the face cache is thrown away, > we will not be able to use the current matrix. So if I set `inhibit-free-realized-faces' to nil at some arbitrary time things may go wrong. > The current matrix is used for the following purposes: > > . outside of the redisplay cycle, for redisplaying portions of > windows when we get expose events -- in this case we simply write > to the glass the relevant portions of the matrix, without > reproducing it > > . during a redisplay cycle, for decisions about redisplay > optimizations > > . at the end of a redisplay cycle, for comparison with the desired > matrix, which is needed for figuring out what to write to the > glass > > For the first purpose, we have the following defenses: > > . expose_frame: > > if (FRAME_FACE_CACHE (f) == NULL > || FRAME_FACE_CACHE (f)->used < BASIC_FACE_ID_SENTINEL) > { > redisplay_trace ("expose_frame no faces\n"); > return; > } > > . expose_window (called by expose_frame): > > if (w->current_matrix == NULL) > return false; > > So this case is covered, i.e. you can call ... from Elisp, at any time, I presume ... > free_all_realized_faces, > and the next expose event will be handled correctly. > 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. Sheer luck, I presume. Couldn't PRODUCE_GLYPHS set inhibit_free_realized_faces iff redisplaying_p is true? > So I think each function that might need to notice face changes as > soon as they happened, should be able to reset > inhibit_free_realized_faces, provided that (a) it makes sure > redisplaying_p is zero, and (b) it only does that if necessary and for > a single frame. The latter part is because clearing the face cache > will cause all the move_it_* functions to work harder, because they > will have to recompute all the faces. So it's not so entirely trivial to do that in Elisp. >> If so, the answer is that inhibit_free_realized_faces should be >> always true but for the small window within retrying in >> redisplay_internal. > > I don't think I agree, but maybe I'm missing something. 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? >> In either case, it strikes me as a strange idea that redisplay_internal >> saves and restores the value of a variable which is apparently always >> true when it is entered (I suppose redisplay_internal is not re-entrant >> given >> >> /* I don't think this happens but let's be paranoid. */ >> if (redisplaying_p) >> return; > > redisplay_internal is non-reentrant, but I see no harm in restoring > the value on exit. If someone sets it to nil now, observing the precautions you gave above, things change radically. We may restore the value to nil, which was hardly the case before. martin From debbugs-submit-bounces@debbugs.gnu.org Thu May 07 08:42:21 2020 Received: (at 38181) by debbugs.gnu.org; 7 May 2020 12:42:21 +0000 Received: from localhost ([127.0.0.1]:42367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWfr3-0006CF-13 for submit@debbugs.gnu.org; Thu, 07 May 2020 08:42:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45056) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jWfr1-0006C0-Kd for 38181@debbugs.gnu.org; Thu, 07 May 2020 08:42:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49543) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jWfqw-0004wL-2O; Thu, 07 May 2020 08:42:14 -0400 Received: from [176.228.60.248] (port=2513 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jWfqv-00082A-Dr; Thu, 07 May 2020 08:42:13 -0400 Date: Thu, 07 May 2020 15:41:59 +0300 Message-Id: <83v9l7kjc8.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-Reply-To: <6ca19f2b-a7c9-1574-63b1-e66fce30633e@gmx.at> (message from martin rudalics on Thu, 7 May 2020 10:34:40 +0200) Subject: Re: bug#38181: Actual height of mode-line not taken into account 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> <83v9lal32e.fsf@gnu.org> <11D1C839-3EC3-4CAA-A6C9-3FC4E2A2B265@gnu.org> <83h7wtkv2b.fsf@gnu.org> <6ca19f2b-a7c9-1574-63b1-e66fce30633e@gmx.at> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Thu, 7 May 2020 10:34:40 +0200 > > >> I simply don't yet understand why updating the frame decorations that have nothing to do with text layout needs init_iterator to run. What am I missing? Redisplay doesn't in general redraw the whole frame, it only redraws windows. > > > > Answering my own question: because the clear_under_internal_border > > method, which redraws the internal border, is called from > > redisplay_internal. > > That's only a secondary issue, I think. clear_under_internal_border is > called from so many places. The real reason is, as I tried to explain > before, to update the basic faces, however that is accomplished. What puzzled me was how init_iterator was involved: without its being called at least once, the call to clear_under_internal_border will not use the updated faces. From debbugs-submit-bounces@debbugs.gnu.org Sun May 10 10:34:08 2020 Received: (at 38181) by debbugs.gnu.org; 10 May 2020 14:34:08 +0000 Received: from localhost ([127.0.0.1]:50190 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXn1r-0001Kg-K2 for submit@debbugs.gnu.org; Sun, 10 May 2020 10:34:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXn1p-0001K6-Va for 38181@debbugs.gnu.org; Sun, 10 May 2020 10:34:06 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44016) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXn1k-00052U-3S; Sun, 10 May 2020 10:34:00 -0400 Received: from [176.228.60.248] (port=2436 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jXn1i-000176-Tg; Sun, 10 May 2020 10:33:59 -0400 Date: Sun, 10 May 2020 17:33:51 +0300 Message-Id: <83v9l3dflc.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-Reply-To: <6713049b-49e2-64ca-902d-1f972952f590@gmx.at> (message from martin rudalics on Thu, 7 May 2020 10:34:53 +0200) Subject: Re: bug#38181: Actual height of mode-line not taken into account 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Thu, 7 May 2020 10:34:53 +0200 > > >> With Bug#40639 and Bug#41071 the situation is simple: The internal > >> border changed face but when we enter init_iterator > >> inhibit_free_realized_faces is true and we don't handle it. > > > > Can you show the backtrace from this call to init_iterator? > > I run emacs -Q and evaluate there the following form > > (progn > (set-face-background 'internal-border "red") > (select-window > (display-buffer-in-child-frame > (get-buffer-create "*scratch*") > '((child-frame-parameters > . > ((left . 100) > (top . 100) > (height . 10) > (width . 20) > (minibuffer . nil) > (internal-border-width . 50))))))) > > Now _if I remove the following two lines_ > > if ((IT)->glyph_row != NULL) \ > inhibit_free_realized_faces = true; \ > > from PRODUCE_GLYPHS, evaluating the form above does pick up the face > triggered by > > XFRAME (w->frame)->face_change > > true as > > #0 0x0000000000463cbf in init_iterator (it=0x7fffffff8c60, w=0x193e060, charpos=1, bytepos=1, row=0x1947f90, base_face_id=DEFAULT_FACE_ID) at ../../src/xdisp.c:2975 > #1 0x00000000004652e8 in start_display (it=0x7fffffff8c60, w=0x193e060, pos=...) at ../../src/xdisp.c:3298 > #2 0x0000000000497468 in try_window (window=XIL(0x193e065), pos=..., flags=1) at ../../src/xdisp.c:19120 > #3 0x00000000004941e9 in redisplay_window (window=XIL(0x193e065), just_this_one_p=false) at ../../src/xdisp.c:18544 > #4 0x000000000048be75 in redisplay_window_0 (window=XIL(0x193e065)) at ../../src/xdisp.c:16258 > #5 0x00000000007af751 in internal_condition_case_1 (bfun=0x48be33 , arg=XIL(0x193e065), handlers=XIL(0x7ffff3e98ee3), hfun=0x48bdfb ) at ../../src/eval.c:1379 > #6 0x000000000048bdcd in redisplay_windows (window=XIL(0x193e065)) at ../../src/xdisp.c:16238 > #7 0x000000000048a7fb in redisplay_internal () at ../../src/xdisp.c:15706 > [...] > With PRODUCE_GLYPHS unaltered, that breakpoint does _not_ trigger. Only > if I set frame titles for child frames (as I do on master now) I can get > a backtrace like the below > > #0 0x00000000004821dc in init_iterator (it=0x7fffffffb4a0, w=0x1a4b800, charpos=-1, bytepos=-1, row=0x0, base_face_id=DEFAULT_FACE_ID) at ../../src/xdisp.c:2988 > #1 0x00000000004a575b in gui_consider_frame_title (frame=XIL(0x1a5e8f5)) at ../../src/xdisp.c:12447 > #2 0x00000000004a5c07 in prepare_menu_bars () at ../../src/xdisp.c:12544 > #3 0x00000000004aaeaf in redisplay_internal () at ../../src/xdisp.c:15392 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? > 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. > >> Nevertheless, the fact that inhibit_free_realized_faces is true when > >> entering the iterator after a face change is IMO a bug. We apparently > >> always run the iterator with the old faces first. Only after we have > >> (incidentally?) detected some change that forces us to "retry", we have > >> redisplay set inhibit_free_realized_faces to false itself and the face > >> change will get applied in the next iteration. If so, the outcome of > >> the previous iterations gets lost if a face changed there. Does such a > >> strategy give us any gains? > > > > I don't think I follow. redisplay_internal resets the > > inhibit_free_realized_faces flag to zero near its beginning. It is > > true that we also reset it when we retry, but the first try doesn't > > bypass this resetting. Am I missing something? > > 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. > >> Again, the question I tried to ask earlier was: Does a current matrix in > >> between two redisplays rely on the old realized faces? > > > > Of course it does. The glyph matrices don't hold any face > > information, they only hold the ID of each face, and the ID is just > > the index of the face's cache slot. If the face cache is thrown away, > > we will not be able to use the current matrix. > > 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. > > . expose_frame: > > > > if (FRAME_FACE_CACHE (f) == NULL > > || FRAME_FACE_CACHE (f)->used < BASIC_FACE_ID_SENTINEL) > > { > > redisplay_trace ("expose_frame no faces\n"); > > return; > > } > > > > . expose_window (called by expose_frame): > > > > if (w->current_matrix == NULL) > > return false; > > > > So this case is covered, i.e. you can call > > ... from Elisp, at any time, I presume ... Yes, but not limited to that. > > 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. > 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. > > So I think each function that might need to notice face changes as > > soon as they happened, should be able to reset > > inhibit_free_realized_faces, provided that (a) it makes sure > > redisplaying_p is zero, and (b) it only does that if necessary and for > > a single frame. The latter part is because clearing the face cache > > will cause all the move_it_* functions to work harder, because they > > will have to recompute all the faces. > > So it's not so entirely trivial to do that in Elisp. Why do we need to do this in Lisp? > >> If so, the answer is that inhibit_free_realized_faces should be > >> always true but for the small window within retrying in > >> redisplay_internal. > > > > I don't think I agree, but maybe I'm missing something. > > 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. > >> In either case, it strikes me as a strange idea that redisplay_internal > >> saves and restores the value of a variable which is apparently always > >> true when it is entered (I suppose redisplay_internal is not re-entrant > >> given > >> > >> /* I don't think this happens but let's be paranoid. */ > >> if (redisplaying_p) > >> return; > > > > redisplay_internal is non-reentrant, but I see no harm in restoring > > the value on exit. > > If someone sets it to nil now, observing the precautions you gave above, > things change radically. We may restore the value to nil, which was > hardly the case before. That'd be shooting ourselves in the foot during the next redisplay, but it isn't a catastrophe, AFAIU. From debbugs-submit-bounces@debbugs.gnu.org Mon May 11 04:30:55 2020 Received: (at 38181) by debbugs.gnu.org; 11 May 2020 08:30:55 +0000 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 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 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 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii 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> From: martin rudalics Message-ID: <96da8d16-0691-7b26-ec33-0b8ec25e3f3e@gmx.at> Date: Mon, 11 May 2020 10:30:45 +0200 MIME-Version: 1.0 In-Reply-To: <83v9l3dflc.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:rBLqQ3Tsa77bxjC1KxDIQ1LReCZhHAFIJEdwk+ZROtWRN7Y8MUq aHjGGDTB+PQ4z+cpGeJb0kkqynJQMAC7KzuZ8EQS7OAoWIgUMWe8jXrba3dncbssiGqHUaK /3pqSmjPbRXbpjHVzODYfvqrbjA3GPP4V8xhTltxAdbDRlzWRTD20w2ixYhPsNFEjjsvawY VWMqoDLafLhXdKIP7d2oA== X-Spam-Flag: NO 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/cOhMhC4ZeAwBJTkyLhB5hMcIdshREtLmcadnyM4ocbjf4O H+7MYKLgN1/jFa/PQUtGdiZ10ua1FgSoV1BY/YFRw6uvFtZ9mtaG4UZ8PEV31mRmO8ffXz9MC QwQr3i8x2Hem4Gg7eYsG3+9tJYc3US+TkcUdIAeR3gjuo554ybogk3ZoVE++tVlmjhAMeJl2I hEgzXAwqXXBXjg7POWbiz6UQ5PmAnCJBaHIzq3Oz39M3EtpzKR28XXoLg54iN8JAZPHCzwnfM /i42kNnVpftsI41chkBJBDYzBsYkDh7bCL7/ENCB+8OvqTEmFRY6iAXkVoDP8xsX7BgklJDS/ NXi7o/gC74CekAVc22ijIRxB7Jg6eQzNsyLpMgqLLvPOrNQ/wxnFGTxI+P6R5XyGtmZ0ofq7u besy12Fyu3QpLj51lTTEJ1ME1nCfreYIylzsqbl34dWjPQ0KsJWIettY/RQl1UiCpR58o3s+k yCPEPFXvsaF49glM6 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > 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 From debbugs-submit-bounces@debbugs.gnu.org Fri May 15 11:00:44 2020 Received: (at 38181) by debbugs.gnu.org; 15 May 2020 15:00:44 +0000 Received: from localhost ([127.0.0.1]:38471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZbpL-0001mF-Vy for submit@debbugs.gnu.org; Fri, 15 May 2020 11:00:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZbpL-0001gF-2o for 38181@debbugs.gnu.org; Fri, 15 May 2020 11:00:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43021) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZbpE-0005iC-GG; Fri, 15 May 2020 11:00:36 -0400 Received: from [176.228.60.248] (port=3415 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZbpD-0005dy-9q; Fri, 15 May 2020 11:00:36 -0400 Date: Fri, 15 May 2020 18:00:18 +0300 Message-Id: <838shtgs59.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-Reply-To: <96da8d16-0691-7b26-ec33-0b8ec25e3f3e@gmx.at> (message from martin rudalics on Mon, 11 May 2020 10:30:45 +0200) Subject: Re: bug#38181: Actual height of mode-line not taken into account 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> <96da8d16-0691-7b26-ec33-0b8ec25e3f3e@gmx.at> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Mon, 11 May 2020 10:30:45 +0200 > > > 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? Is that a serious question? Anyway, if we want to be able create frames without titles, I guess we should simply arrange for the face cache to be cleared and the basic faces recomputed somewhere near the beginning of redisplay_internal. > >> 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? For when we don't want to loop over all the frames setting their individual flags, I guess. > 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. "Initially run with old character sizes" doing what? AFAIR, we do the frame title thingy quite early during the redisplay cycle. What is done before that that needs to know about the faces change? > >> 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"? More in what way? This just means we sometimes set it elsewhere as well. > >> 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'? I don't remember, but if so, it doesn't yet mean everything must be done in Lisp. > >> 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. We should? why? From debbugs-submit-bounces@debbugs.gnu.org Sat May 16 04:44:50 2020 Received: (at 38181) by debbugs.gnu.org; 16 May 2020 08:44:51 +0000 Received: from localhost ([127.0.0.1]:39748 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZsR8-0003jj-LS for submit@debbugs.gnu.org; Sat, 16 May 2020 04:44:50 -0400 Received: from mout.gmx.net ([212.227.15.18]:59561) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZsR6-0003jT-O9 for 38181@debbugs.gnu.org; Sat, 16 May 2020 04:44:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1589618681; bh=CmycTmNWgxCHEjKeWKSHN7ldRyfoIM8fkRoQud4N+zg=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ECvGlZgpDk2tnaWxvjAoiDFMYYWKXd47AfF+N15UajONgVY1jDGoR20loY9eA9h+a k2S9WiddsVlo9vZ435ZZBf6HrzCp2zoQSveYPv6wcUVSXXBr8emf6Vll7blJq4vB59 MX0eoz+9r1jFKhzJKqTVbk4cVXXbseZMi8kl2KIw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([212.95.5.16]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MDQiS-1jPO2R2WFK-00AUKc; Sat, 16 May 2020 10:44:41 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii 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> <96da8d16-0691-7b26-ec33-0b8ec25e3f3e@gmx.at> <838shtgs59.fsf@gnu.org> From: martin rudalics Message-ID: <012a6909-f4b7-8863-5b59-aedf8149b764@gmx.at> Date: Sat, 16 May 2020 10:44:38 +0200 MIME-Version: 1.0 In-Reply-To: <838shtgs59.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:RczREYQZdqVgADMH8MK9jBQnnSpP9xpa5DpQ/DJ89Xo1Ah/lTST XIKyq7fd7Nyb8x/+Ee+zkFRAU/QWAzyKrLPWUFcvpkbdGXs2TEpz0XyLoxyoevLzTi6FT3A BVsRv7/sKREL7E9Aim1mbYHtZqrwCPfxu6tcux5VzMVIdaGZfbR7kAUS3BwChQy17PxPPLs VwwvnK02P1lXgJlBfrRVw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:u2u9/8Y68ME=:zsMhRFRXpwRC3tRSHIvdAt 2L2QG6R1dnajr1qda8wcadk65SS17/VR/bo8rB7Hs16n86eMCZOOpAr2QobF7ddEHfyXXUOyz wqJTHEMtlZ5bmARlHsL/TriRFvgI6jffUT5PDY5Az7vid/1eF67XkWyLEZ+o3m9pmG8xzM1Do FAxDglW/1RGYnwraDCOV1T8319TJCYxOh1wlTYwTTvKFtd6R3KqP3hj3BsaUX79Ho+aTmmiKb FT9oANpbRMe7kQYwXawv5ZqDAnfd0ilvstGj3wXkWwR6vbc2ACobI2SZQYAmDSeiUdiYSLVeF tgVB+Tf763n+NNBaMKUO75NmgbA1oeBZuIHsxzBiyW0BOZSP0/C6RyP+icdaQ9xwOKjZM2wTo Tdm+CpAiAOkXeV85EpR1y4UP11bK1w66OfvdY6rTmORvmFoUsOQPcsAW/f8U2B2br7noERO6t 8GWU88ByJP0RgpW9XMhkXxj+pfrGoDJ4R0uSE4rG6/J4P+EC8PYcGqbVieIC9XYeCzzilgCfW fRy8wnV5Udh+AK5Q1yH22qmh9kywJjt09th2PGeehujROwcDVhrFJdICwDQUvMzCp+iJ8Tx5f 72C1wLNABHjFk/sCw4avUbL1z1P0f8sy/cnv2APHPk3FLcNhY25y1/cZ8yeNVzI+fsRehsPeW Nbka1Ep4p18BBUTxCrst+cVjkQ4CUZgNR+mhJe4N/AKQOisVz5wGooINP+nlmXx4eVLGdq6eh u1M2z0sGq5jH+DFu3IeYI1vQ7Kgylv6TGnToUVV7nsu2xEYtOlhDedokcDoKZGqqJ/nh9knGR uRM6E6ict984vThocQMo/b8421qCCBsbZi8o9EiC8ubcb7Mhmq8BV4hurbOp7J/sO+0aoGPsI +kGR+CBVTHogGBG3vl8OFQdSmGRlZZXd08BR4m9mhFwk7Ngthv+b2HR/mUyQBrD0di2X+Yq7k AToaAgomv3gljiigl5Ccue6y/gq0JlL0tA+qiwCdfk/hCz1mfcUc3Wnj/XjXqFNciHi9ZR9Xj YuiQtwqxkMkcQmR552+j5A67cVUqHqlbbLF3J3H26fr8hod9ayQlwRzl/NZj8Mm2F2arWXXUA n47IXoFlJ0BVF9uUCJ3UZSxr1d5rb/QuhxOqiSsYd+QIhXnowmOuFkwXuMBiNYrCUH+TtQccI kEGkOOc4btToR/bIdd5CGiG1U/ReNTtlJ2Mm6drnKN2BZ2Fi5621kFNNR+PXxBnQJw3A/2eV9 6VBol/OeptX22TwYo X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> 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? > > Is that a serious question? Given my current knowledge of the matter, yes. Note that ATK apparently even mandates that tooltip windows have some sort of title set. > Anyway, if we want to be able create frames without titles, Our tooltips are frames and don't have titles so we do that already. >> This way of setting things confuses me. What is then that global >> face_change bool needed for? > > For when we don't want to loop over all the frames setting their > individual flags, I guess. Agreed. But does our code adhere to that idea? gui_set_font_backend sets face_change to true and so does IT_set_frame_parameters (not that it matters here - I'm just talking about the idea) while working on a specific frame. And in x_create_tip_frame and w32_create_tip_frame we even have to save the value of it via face_change_before even though these two functions really should only affect the tip frame about to be created. All other settings of face_change happen in xfaces.c and that one really should know better. > "Initially run with old character sizes" doing what? AFAIR, we do the > frame title thingy quite early during the redisplay cycle. What is > done before that that needs to know about the faces change? Earlier, when debugging this issue, I spent some time stepping through the iterator with the old faces in place and just wondered why the new faces would not get applied. Whenever I'm back there I might be able to tell more. But before that I'd rather wait whether your > I guess we > should simply arrange for the face cache to be cleared and the basic > faces recomputed somewhere near the beginning of redisplay_internal. could be implemented and solve all these problems in one rush. >> >> 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"? > > More in what way? This just means we sometimes set it elsewhere as > well. With the inevitable consequence that redisplay_internal restores it to true when it exits. Is that the idea behind "we sometimes set it elsewhere as well" or just some sort of collateral damage? >> We should say that in the doc-string of 'inhibit-free-realized-faces', >> maybe. > > We should? why? Because it might help people like me understand this issue. Do you think that my questions are provocative? Maybe they are, but then that's a consequence of the fact that I don't get the picture of our implementation of faces. martin From debbugs-submit-bounces@debbugs.gnu.org Sat May 16 06:47:02 2020 Received: (at 38181) by debbugs.gnu.org; 16 May 2020 10:47:02 +0000 Received: from localhost ([127.0.0.1]:39851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZuLN-0006pV-KA for submit@debbugs.gnu.org; Sat, 16 May 2020 06:47:02 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZuLL-0006pB-M5 for 38181@debbugs.gnu.org; Sat, 16 May 2020 06:47:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40017) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZuLF-0006OA-DG; Sat, 16 May 2020 06:46:53 -0400 Received: from [176.228.60.248] (port=4591 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZuLE-0005q2-Af; Sat, 16 May 2020 06:46:53 -0400 Date: Sat, 16 May 2020 13:46:41 +0300 Message-Id: <83tv0gcg32.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-Reply-To: <012a6909-f4b7-8863-5b59-aedf8149b764@gmx.at> (message from martin rudalics on Sat, 16 May 2020 10:44:38 +0200) Subject: Re: bug#38181: Actual height of mode-line not taken into account 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> <96da8d16-0691-7b26-ec33-0b8ec25e3f3e@gmx.at> <838shtgs59.fsf@gnu.org> <012a6909-f4b7-8863-5b59-aedf8149b764@gmx.at> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: jonas@bernoul.li, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Sat, 16 May 2020 10:44:38 +0200 > > > Anyway, if we want to be able create frames without titles, > > Our tooltips are frames and don't have titles so we do that already. Yes, of course. I hope you don't assume I didn't know that. > >> This way of setting things confuses me. What is then that global > >> face_change bool needed for? > > > > For when we don't want to loop over all the frames setting their > > individual flags, I guess. > > Agreed. But does our code adhere to that idea? gui_set_font_backend > sets face_change to true and so does IT_set_frame_parameters (not that > it matters here - I'm just talking about the idea) while working on a > specific frame. And in x_create_tip_frame and w32_create_tip_frame we > even have to save the value of it via face_change_before even though > these two functions really should only affect the tip frame about to be > created. All other settings of face_change happen in xfaces.c and that > one really should know better. Could you please tell where is this discussion going? Because I no longer understand that. We seem to be talking around the issue, but to what end? Why are these details important for whatever job you have in mind? I'd like to help you do that job, but I'm lost in "twisty little passages, all alike". > > I guess we > > should simply arrange for the face cache to be cleared and the basic > > faces recomputed somewhere near the beginning of redisplay_internal. > > could be implemented and solve all these problems in one rush. All it takes is to call free_all_realized_faces for the frame in question, and then do what init_iterator does: if (FRAME_FACE_CACHE (it->f) == NULL) init_frame_faces (it->f); if (FRAME_FACE_CACHE (it->f)->used == 0) recompute_basic_faces (it->f); > With the inevitable consequence that redisplay_internal restores it to > true when it exits. Is that the idea behind "we sometimes set it > elsewhere as well" or just some sort of collateral damage? I don't think it matters that this flag is set when we are outside redisplay. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 01:13:51 2021 Received: (at 38181) by debbugs.gnu.org; 15 Oct 2021 05:13:51 +0000 Received: from localhost ([127.0.0.1]:37717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbFXE-0004zj-HK for submit@debbugs.gnu.org; Fri, 15 Oct 2021 01:13:51 -0400 Received: from mail-yb1-f172.google.com ([209.85.219.172]:46808) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbFXC-0004zP-9y for 38181@debbugs.gnu.org; Fri, 15 Oct 2021 01:13:35 -0400 Received: by mail-yb1-f172.google.com with SMTP id h2so19826535ybi.13 for <38181@debbugs.gnu.org>; Thu, 14 Oct 2021 22:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=9DdkZ0dKvYb7FY4S2084eWS5shglxOnwU4CB9fQ/Ap8=; b=cHi/EHjdkPSy7yHr0+PSkS96WA7OZhaa9O4UvCqr3W8p3blQl2Q9WXFlsEJqP2y3su y9BJxRmenz9l+zuwAzwVf4EttxZ8w9nBg53rAT0sB5nTlVKymeoQ8Sy2CFpKAPCCxVcv qWwnZBTx12iZ5cWNVuPz8BFi1NT9hFJfnVnooA3Pc5ZUHEDB8jCDC5boUy0tFN1ub+4E DzEHX/T5LAfS8J/ZmzjeEWcpKYrrZmYh66TQyJ/Ee5qvruu1cOeVFrP+7MQZ74ytm+wa huow8zCR4Er8Ehz6oD1FaEREXL1DkwANH2o2LNlrXLcViTpMjzMd8PXaT7hLHeXZWBWV qw0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9DdkZ0dKvYb7FY4S2084eWS5shglxOnwU4CB9fQ/Ap8=; b=TOrbRj+oufFyr57obi9Qa+PZ+KLsPIzaUSNnvwuyr+QMGNHyWzPwHh/OhezrLlJgp3 tHO76P2p+kvErrfTagiwaIk38Da+1ThW1YUpnrShXrOT/gXrJcPOzU2g9mw4AawwVlbz 3gPz7By4bgIWchdqp/nz+mCqLefybbta64nf/43HMZt6vzX7ey/tInXhYBED9WXvGUY4 tpi8WteVddF7SRObRi3hsp6aLEGZ69hSQ5xdXmhxLlcbziSLQWfwQseXvFbULH9ApyNs 7Ax8s2eCgVuL//aosgT4oyHr6kmqOmV9W2o0BlZMA52swQ1UX1SvXcWKhWjH5FgzCyYc BKJw== X-Gm-Message-State: AOAM5331+a8ogDWmciGFwdCl/KVLO6NBYFsLxZLUsrDYq5aXusVv1FZA kcsANZhpbUJq2I1DU4NM5vXn4bvDOlv3pQtf486q6kOQcoSeJQ== X-Google-Smtp-Source: ABdhPJwCLuCH7I9lEdtqVns3K6F1CFYL4tz7SmOPEAnqlOWkuvfx4rKBK6ZEKzQujbOQGeIlJWH3RWC8mlszAK2ktQo= X-Received: by 2002:a25:2cc6:: with SMTP id s189mr10805945ybs.82.1634274808738; Thu, 14 Oct 2021 22:13:28 -0700 (PDT) MIME-Version: 1.0 From: Carlos Pita Date: Fri, 15 Oct 2021 02:13:14 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: 38181@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hi, I'm seeing what I believe is an instance of this issue in a vanilla build from emacs-28 branch, ns/cocoa backed. Here are some instructions for reproduction: https://github.com/seagle0128/doom-modeline/issues/480#issue-1027051204 Best regards, Carlos From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 03:05:18 2021 Received: (at 38181) by debbugs.gnu.org; 15 Oct 2021 07:05:18 +0000 Received: from localhost ([127.0.0.1]:37905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbHHK-00081b-5J for submit@debbugs.gnu.org; Fri, 15 Oct 2021 03:05:18 -0400 Received: from mout.gmx.net ([212.227.17.21]:60099) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbHHH-00081I-T7 for 38181@debbugs.gnu.org; Fri, 15 Oct 2021 03:05:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634281509; bh=lZ/FMDaFgbyUKQ9rvuX59Ri6+jwcmLbs/D1L1Pyvy9Y=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=kXi6l9Upds3pIEFTZIqZ+p6pJPEufUgDr8nziM+qcXhPRShIOwIrP6OKdxdiFTJwl Ou3mk4eHTo+f+RiYWBn1qcIeMsAgOvT6MJBwnLBYex6fPcWrkEQd2q4dZtst40TTX/ qOt1bO9xpc+uCU82z20Py5l96xm/B6eSv/rOkAoE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([213.142.97.113]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N33Ib-1mis5x3s8z-013R9k; Fri, 15 Oct 2021 09:05:09 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Carlos Pita , 38181@debbugs.gnu.org References: <87eeyd3ul0.fsf@bernoul.li> From: martin rudalics Message-ID: <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> Date: Fri, 15 Oct 2021 09:05:07 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:Kgnn6c9QfqQnF2nISlJ+7tzjzJi+lWbhhApjgMJTet8YH6nMz5e aWQbWxc0D6jP2bmKXixyNHMdckjuUu+OO/TtBsW71Vu5wjaG1JzFp7cFFKDWvmQMB1pFsn+ hBnDplCWP16mj9FlntXN5ajOLpO5tLngSyQBlfR6OHbMLru9dbOtlT6mZWrsMkVXTVAApm5 EJslRaLF565Hcs33vVOcQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:IezS5v6zPWk=:ix5+dJuT0MSG03H2IBQjP5 tAtAXQNjTRI8cq0yuDo9Tm6H6DJPVGKHLTz+aZInM/2aSkK3wEbaxkcTOYKlZvyFcAyRbZRL6 0VXfgondxtO8kfixQJXAY+VumP27yuGw6zUo7DNJDu7g5Xx52aES452sKWoMzU7pAx8SHdp5y UxSE7LZpiGCtJrR9TsMFHjoNWwOm6c+wFwSvUKC9B6+4MjCvnT5rYK5QygHq5+E/VyVyu1EYQ hRtgw/256w+BV5xgnLLIOyzsEDLPiypaD/z2BS+yAIft3Fvp1Ef9nHAk9lmESO0TJ9Z5zKaZ1 z4Bfko2wVznqSGk0BrT9ThMgM7UAPQO99F7Ni8VMaIBeBs0ZChmWY3UhoI58F0oxkOrUuEQ1O lNmKCm6+JC2jefHFpA+uZ4BX0em9t2OAM4BeOQds288NgJqHdhd5ioQvoZHSF1Vvg1z6DAa4A CJK5Qi5PhqwBX2OxeScj9kGti2TNIOVFa6Qn/rp76FkpVtb2dT/aEWebyy+n/uX7HeMb1pegw O1lpEMbhadKF1HamwDuCaLnTZHHdhv3mzi6QGhgPF6bHyqd9lu24TIZqMI8SebDquH4kKAqa8 glB3kem1egTQmhFG/5C6w5mIBqwUFFfzy61IeM53tLYnRof5/GHdxC3dsr0GHpfRqsYSwNLz8 cjCXqa7IGbnHpSqS0V3f+8gI2lag3gjDvNSG9wsLv5ahzU5V6+/8CQMEOmRJAR7+AQfpPrTd2 WV6ztz8b1pO9Lg88RiqS8eTL51UVHIVPQvBVaMqBFjOiPuKxmV4HGYEFKY2L9uHUiAq98C67Y ddSppxZaV3QS2muZR0SZjNyY7rfYW7GfxM/9cA6dNlx323v2d12s9wh6VJAcNzoexnRZiYSB0 o5HqeBPkA3U8JPjnpVs1ksSqXfHOa10nBewttlMwhgK7B4OBuNnfk5xUMTGoOvoNMHrHbl+Fi OAi0QPVOrdLYGDgCeWEQBd9du0VtNIKu+piPCZNXwRneo1TcilOdaYRTilUahv7TZJmdWzX1N +iR2J+JJ1l3IWkKBCtA0QuzdCGnop1VPqS2JuSRUZdnAfxWkGPl0scxTdrwxlo7SvNHoh9CrN ZNnHwtGYtHHwMc= X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 38181 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > I'm seeing what I believe is an instance of this issue in a vanilla > build from emacs-28 branch, ns/cocoa backed. > > Here are some instructions for reproduction: > https://github.com/seagle0128/doom-modeline/issues/480#issue-1027051204 If the underlying scenario is that you first fit a window to its buffer and then enlarge the height of that window's mode-line, there's not much we can do here currently. It's like fitting a window to its buffer and then adding a header line or a horizontal scroll bar to that window. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 03:27:14 2021 Received: (at 38181) by debbugs.gnu.org; 15 Oct 2021 07:27:14 +0000 Received: from localhost ([127.0.0.1]:37948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbHcY-00009x-J9 for submit@debbugs.gnu.org; Fri, 15 Oct 2021 03:27:14 -0400 Received: from mail-yb1-f176.google.com ([209.85.219.176]:36633) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbHcW-00009e-3S for 38181@debbugs.gnu.org; Fri, 15 Oct 2021 03:27:13 -0400 Received: by mail-yb1-f176.google.com with SMTP id g6so20613839ybb.3 for <38181@debbugs.gnu.org>; Fri, 15 Oct 2021 00:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=81uw6jExUcy2OBI7uhOOLKlGhfCFN6XQ5AAtitjWdGk=; b=iDvNzlt5Lh8hM0KfPvkc6zNc2nEmbZkBP3FtKej+9SbJNVaibZVTWj5DlVQFQPHKwY uH3SyhLKm9k6CSx/84ujpJ4ku+xoKNyb/ATtiKxxq7zBrpG+O112Hx2n+nomaIKn/wsr CvMKuhfq9TUULxjO1U3P0oRXavU3dwujYMZziu55mS0vbkOliI49PD0rbMSUWalD3ZaE 7JSgjUs9qDh1+MroBurokFVLph5NDwyshwPed7vhHy5xYSQVgPbxzN28Tl/DMIbAwGv/ HVI+eXa/2Co/X+mJY5dmPr1lLe40SR+WKK/QjIixi66Ir8GodFOV6ENJhMefaV4BlOBW A2jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=81uw6jExUcy2OBI7uhOOLKlGhfCFN6XQ5AAtitjWdGk=; b=VYpCqX5euMyAgvbyJcvFlQEuzqSFFa0lg9zaOA0lIu2GxfOdeUkV2J7BxWG9iQ1hrW oHX0sY+YZj+h5GXxEubUOlHLoez+3aIIGrnwJIcOlVyOFheqczwY7I109fw1Av3K8hKJ lYNqnZT5HO+jltU9sTDAzM8urnD5qS1nzUP0d958hmtgDKZIo9v06FDJ3jDZyYE6Pf0U D9AxxLtrS+7zDTjhDf4wQK7xyu3mBSlzW25wr7HSZtd6EnTBdQy3l3MOQgOD/4d+/Bt+ q6ew/mcqhv0SWSJv3QCKrRvPyYWFNS7ixsRai13dlyokrzJIxgpgWGvQNws/FeBYSlQb 10jw== X-Gm-Message-State: AOAM530OBXlfRjP39Jpz/n8tRRyXXtYbaTDSLzbe/TvrIHLEL9oGMqbt iQhnikUHOM/VTJQVii9usHyrtwE35BiZyn5Xm6hmvjlJCyDnkw== X-Google-Smtp-Source: ABdhPJxVlpmApzmyN+MiM4FGKnCO6IA+276l5Foxfvp8DKG9btHrWh/i6SyLaMADa7xSWiL9sTaQhhHZjQp7ApTpwuY= X-Received: by 2002:a25:b4d:: with SMTP id 74mr10408734ybl.443.1634282826567; Fri, 15 Oct 2021 00:27:06 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> In-Reply-To: <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> From: Carlos Pita Date: Fri, 15 Oct 2021 04:26:51 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: martin rudalics Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Hi Martin, > If the underlying scenario is that you first fit a window to its buffer > and then enlarge the height of that window's mode-line, there's not much > we can do here currently. It's like fitting a window to its buffer and > then adding a header line or a horizontal scroll bar to that window. I can't say I understand the details discussed here but I'm not quite sure your description fits the situation. The workaround since this bug was first reported has been: immediately before fit-window-to-buffer execute an advice that forces a redisplay, then deactivate the advice. But the problem I'm seeing now is that the first time org-set-tags-command is executed its popup is correctly sized (with said workaround in place, of course), but further executions show a popup with the wrong geometry that trims part of the text off. If I remove the "just once" clause in the workaround, so that the redisplay is forced after each fit-window-to-buffer execution, then the layout is correct every time. It goes without saying that org-set-tags-command is ultimately triggering the execution of fit-window-to-buffer, but that stuff you probably know much better than me. Thing is, there was no enlargement of the modeline in-between, as far as I can understand and see nothing changed in this regard between the first and the second execution of org-set-tags-command. Best regards, Carlos From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 03:51:17 2021 Received: (at 38181) by debbugs.gnu.org; 15 Oct 2021 07:51:17 +0000 Received: from localhost ([127.0.0.1]:37988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbHzo-0000os-Rd for submit@debbugs.gnu.org; Fri, 15 Oct 2021 03:51:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45894) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbHzl-0000oc-G4 for 38181@debbugs.gnu.org; Fri, 15 Oct 2021 03:51:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51768) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mbHzg-0005b3-4v; Fri, 15 Oct 2021 03:51:08 -0400 Received: from [87.69.77.57] (port=1745 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mbHzf-0001vV-Nv; Fri, 15 Oct 2021 03:51:08 -0400 Date: Fri, 15 Oct 2021 10:51:06 +0300 Message-Id: <83czo6k9p1.fsf@gnu.org> From: Eli Zaretskii To: Carlos Pita In-Reply-To: (message from Carlos Pita on Fri, 15 Oct 2021 02:13:14 -0300) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Carlos Pita > Date: Fri, 15 Oct 2021 02:13:14 -0300 > > I'm seeing what I believe is an instance of this issue in a vanilla > build from emacs-28 branch, ns/cocoa backed. > > Here are some instructions for reproduction: > https://github.com/seagle0128/doom-modeline/issues/480#issue-1027051204 That bug was about doom-modeline and similar extensions, and it was never fixed (because we found the solution to be elusive and nowhere near simple), so it's small wonder the issue still exists. Is there something new you see that you think will help us in dealing with this problem? If so, could you please describe the new information? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 03:54:39 2021 Received: (at 38181) by debbugs.gnu.org; 15 Oct 2021 07:54:39 +0000 Received: from localhost ([127.0.0.1]:37992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbI35-0000tY-Af for submit@debbugs.gnu.org; Fri, 15 Oct 2021 03:54:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbI33-0000tK-3V for 38181@debbugs.gnu.org; Fri, 15 Oct 2021 03:54:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51844) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mbI2x-0008Jk-65; Fri, 15 Oct 2021 03:54:31 -0400 Received: from [87.69.77.57] (port=1952 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mbI2v-0002Fe-Ur; Fri, 15 Oct 2021 03:54:31 -0400 Date: Fri, 15 Oct 2021 10:54:29 +0300 Message-Id: <83bl3qk9je.fsf@gnu.org> From: Eli Zaretskii To: Carlos Pita In-Reply-To: (message from Carlos Pita on Fri, 15 Oct 2021 04:26:51 -0300) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: rudalics@gmx.at, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Carlos Pita > Date: Fri, 15 Oct 2021 04:26:51 -0300 > Cc: 38181@debbugs.gnu.org > > > If the underlying scenario is that you first fit a window to its buffer > > and then enlarge the height of that window's mode-line, there's not much > > we can do here currently. It's like fitting a window to its buffer and > > then adding a header line or a horizontal scroll bar to that window. > > I can't say I understand the details discussed here but I'm not quite > sure your description fits the situation. > > The workaround since this bug was first reported has been: immediately > before fit-window-to-buffer execute an advice that forces a redisplay, > then deactivate the advice. > > But the problem I'm seeing now is that the first time > org-set-tags-command is executed its popup is correctly sized (with > said workaround in place, of course), but further executions show a > popup with the wrong geometry that trims part of the text off. If I > remove the "just once" clause in the workaround, so that the redisplay > is forced after each fit-window-to-buffer execution, then the layout > is correct every time. It goes without saying that > org-set-tags-command is ultimately triggering the execution of > fit-window-to-buffer, but that stuff you probably know much better > than me. Thing is, there was no enlargement of the modeline > in-between, as far as I can understand and see nothing changed in this > regard between the first and the second execution of > org-set-tags-command. Can you show the recipe for the problem, starting from "emacs -Q"? It sounds from what you say that the problem is not with the mode line, but with something else. If that is true, please submit a new bug report. This bug is about redisplaying the mode line when something changes in mode-line-format that affects the height of the mode line. If there are other problems with fit-window-to-buffer, they should be discussed separately. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 04:00:39 2021 Received: (at 38181) by debbugs.gnu.org; 15 Oct 2021 08:00:40 +0000 Received: from localhost ([127.0.0.1]:38004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbI8t-00014I-Ld for submit@debbugs.gnu.org; Fri, 15 Oct 2021 04:00:39 -0400 Received: from mail-yb1-f174.google.com ([209.85.219.174]:41474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbI8q-000142-DU for 38181@debbugs.gnu.org; Fri, 15 Oct 2021 04:00:38 -0400 Received: by mail-yb1-f174.google.com with SMTP id s4so20760549ybs.8 for <38181@debbugs.gnu.org>; Fri, 15 Oct 2021 01:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ld2diiNj8zWhOpbJerjWEHkPohxIGUUvUUMJt+Dk0zI=; b=BoLGqtTvDY9Ura9QfnTmRak4P7c+y3qo8Hos/nzvOxmSHbV5k0EKLjIcvH7n89103S 4FQvTYnS5tKR+twe6gQDi2RGjWXK2R6yvONNr7D2l4qPRWNlniQKuVKeikZUX0MjmNPF iI/dRhL/ZGYtET2+Cgkm9jVb6BPTJqpVDqe/kS0jz9SsjcMIXNXlr+iJ+unEaVdMc9sp gAts/m7U/aR11VCbTYRUHnbYARhCMODgHsDkQDc4LdvKpqWW8mLjcDp+KczDJtlpWhPo Wk+f3yaPjBxgFC8NpQGfTJEo34u/27XkuZy8Eak/tXD2vMlKPL+UMx/tO3zmjaTRs+m7 aMHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ld2diiNj8zWhOpbJerjWEHkPohxIGUUvUUMJt+Dk0zI=; b=mjXgeCf3CAE4N119EQe1azkLDoPS36LjR0TZ1vHvb1h55JBMP4JtSOGISkiXn9iufx xikBuo9lrsDZZTYmqpIZJrlxdQskluz5X3SAIz8SgE3yJd/7h7TjTZk7MDgfr1iWe9M8 1h/sN0UDalg6U/fWZIGvPgQr0d7MdnGNIQuKM+W8Z1zxszWBAZDOoqsOQ3a2IWPMg3ex WwgZuol7ntiHeQOrsQE4PqHkOkaVpwfDUqFF7yI5ICHljtZuxhuyaMFWJ4KOT96ui48l 8pycLppw3rANhAcISWV1deqaKYV2859qy4yG4wWS76BhZPbaX+JJc+SO6QuDQkR1b+Kp ho0w== X-Gm-Message-State: AOAM532rN3SM3D/xaNG9pviWBrGYlCFyOhy4lqH8KHGNTV+T8wJxeby1 6+G6XRBiDRCjZn4HLZmcjdT0WlP5ZsBo97XiY9+KHYrU3gIIeg== X-Google-Smtp-Source: ABdhPJy8JOcOQuJ7+qQW87M34UCqVwRg2B2wTBwLGRyz8HOg2M16lfHBVNNDlRlnflHXhVTeVIJWHlzyDSzkYPMiHV0= X-Received: by 2002:a25:3104:: with SMTP id x4mr11348603ybx.512.1634284830753; Fri, 15 Oct 2021 01:00:30 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <83czo6k9p1.fsf@gnu.org> In-Reply-To: <83czo6k9p1.fsf@gnu.org> From: Carlos Pita Date: Fri, 15 Oct 2021 05:00:19 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Hi Eli, > Is there something new you see that you think will help us in dealing > with this problem? If so, could you please describe the new > information? I don't know if it will help you dealing with the problem, but I believe that what I've just answered to Martin is new, indeed the workaround that was working before carefully deactivated itself after the first forced redisplay. What I can't see is why after the first redisplay, if the modeline hasn't changed, the popup will be chopped like that (a fortiori considering that previously it was correctly laid out). Best regards, Carlos From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 04:18:32 2021 Received: (at 38181) by debbugs.gnu.org; 15 Oct 2021 08:18:32 +0000 Received: from localhost ([127.0.0.1]:38017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbIQC-0001Vh-2C for submit@debbugs.gnu.org; Fri, 15 Oct 2021 04:18:32 -0400 Received: from mail-yb1-f177.google.com ([209.85.219.177]:35637) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbIQA-0001VT-6D for 38181@debbugs.gnu.org; Fri, 15 Oct 2021 04:18:31 -0400 Received: by mail-yb1-f177.google.com with SMTP id z5so20917235ybj.2 for <38181@debbugs.gnu.org>; Fri, 15 Oct 2021 01:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wj+2gZEs8FDg74aw29H4MAoTWreipiPR8QiFvvuMPlw=; b=ogZKtO/L53t1PNmPKs+7FA12OozWVZlcWmdWMUygMB1uh6vY/4E/cMhZ2+SLH0Hy+k 7lnraJ8T0gMMC9nPPX7ZuuQyOowITm7KOFXv8OdbfpoTRzMpxeRSNSz9euoG6UxcQ9Ad M4A7N8l6GXIq3cHqMBTJLa7NYUcACAluhHyvsqfiO56Rbdf6LGRVOZtK6oq/yu09k5IY nOBmWgIIf83fYnu6gGl62LyliRFvELmuiPVaAsEw0ypB/JNvM7hgguAEMFQV3GhQ3EH0 e0COZkhFFpMX1R4RHaqBX+c4bdC5tvn/3dUN7RA2z6j8AL8bslGR7zxzKuZs0lhvyKdK /U5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wj+2gZEs8FDg74aw29H4MAoTWreipiPR8QiFvvuMPlw=; b=z6TxnsBD158r0HUDrY3N/GgKl53mDeMrveardg6lLvekKZFfbE1OT/jnv4SMBDFe6D gHvnkJM4OINLPAdvCAcjBDhnVD5FbLkzpejoyVQiykspVhR2XqSJXnr4t9DQOoWP8y3H UnDHWOvtxPL4BM7VYzoI/YpkddCEMDtXr+Sx6QhihL+hV8pm/7Sl3xQIeUCesFBuqic9 ynnqehoivdGLaHOcEBdlGwUp9vLDTFp44EVtf6yjNIMEDYEFRPhokdjK2G2DykuhzvZk GZEtVs6o9ftfKFPLobEZCgX7Zn6G33Ty/pUKoR38LbcInSjmF+QQoQPu43CWs1MFTV5I roqA== X-Gm-Message-State: AOAM530+ygMY0bcaV5OlJEFa3yukON3Vvu8WRq5T4bA3VmpKMI5a67/h Fb7T1ih4IUsQ8/6wnZKGeCvdgt+MiIY6USovzNE= X-Google-Smtp-Source: ABdhPJyzx2pUf94XklW7EY2BwlVsvbIieHHrNFSprpgone2UTPytVKLMriABH0Vtl0HU1kCYrsg3cMWbX76O+Zer5lM= X-Received: by 2002:a25:49c3:: with SMTP id w186mr11821085yba.429.1634285904771; Fri, 15 Oct 2021 01:18:24 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <83bl3qk9je.fsf@gnu.org> In-Reply-To: <83bl3qk9je.fsf@gnu.org> From: Carlos Pita Date: Fri, 15 Oct 2021 05:18:13 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: martin rudalics , 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) > Can you show the recipe for the problem, starting from "emacs -Q"? Yes, of course, the example Jonas provided in the opening post will do it with a small modification. 1. Execute the code. 2. Call test-popup and check that the layout is wrong. 3. Redefine test-popup with (redisplay) uncommented. 4. Call it again and check that the layout is right. 5. Redefine test-popup with (redisplay) commented again. 6. Call it again and check that the layout is wrong again. Now, consider the workaround [1] that seemingly has been doing the job for almost two years in at least moody and doom modelines. AFAICS if this workaround was working then, (6) above is showing us something new. Or perhaps it's just my setup and the workaround still works for everybody else. > It sounds from what you say that the problem is not with the mode line, but with something else. If that is true, please submit a new bug report. Please, you tell me what to do in this regard because I'm unable to tell if the problem is in the modeline or elsewhere. To my untrained eye it looks quite similar to what was reported here, although with the aforementioned difference. Best regards, Carlos --- [1] https://github.com/tarsius/moody/blob/9b679400ca885b8ff51bcfd75b87f79d66c0ee26/moody.el#L303 From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 04:35:35 2021 Received: (at 38181) by debbugs.gnu.org; 15 Oct 2021 08:35:35 +0000 Received: from localhost ([127.0.0.1]:38039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbIgh-0001wd-4r for submit@debbugs.gnu.org; Fri, 15 Oct 2021 04:35:35 -0400 Received: from mout.gmx.net ([212.227.15.15]:51363) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbIgf-0001wN-HG for 38181@debbugs.gnu.org; Fri, 15 Oct 2021 04:35:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634286926; bh=hDSKIsd/7dQsEpXgwuio7mY1ZqKSvgnsV9kAInES5bU=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=VK/3SS1sXRR9G0i9RuKyl8pLN4rzUV510EL9igyXTlMJEIWnLvBJR/ccb7V45Pnie sve6898IkwZsX3ImYxVFnDuOJa7vBnhqpspIIzfX4l5gmK0R2nCbqY1U1HeBefHqcL 38eQ6YB9JfBVvLqx1rqw7Rb9Ltmo0qRe0/3EocTY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([213.142.96.142]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MFKKh-1mUMg30rxR-00FnJd; Fri, 15 Oct 2021 10:35:26 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Carlos Pita References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> From: martin rudalics Message-ID: <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> Date: Fri, 15 Oct 2021 10:35:25 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:FcvQR/7yD5qH/sfac5PUeMfN6a/VmDQwBy7F/jcydMTAZQH0NAR 0CbQ79HwLaQ66z4WNw1JMmsINz9PS96aCz5uJqB0OmHDKZbnv0kunamKrBFQE3KQgmJzVlD gY08ov7oW+aaWsDuDb+Pal96QwRUau4X0mhFkqLzlqMP8gQhOT8769tGdMJdG+o1uJ0Ciuf cvwXhEXmKYYQA5un8Jf6A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:XS2ccv3wu/o=:2nwdiE0Mqxh73E6WsmWwOC YbtO593XCQTHL8YU5x4mWRWll0M9AkgJH9DmVyS4O2BXdEoWicKx5+MEYR3dGvZ7cKx1xyS9w p+iBtKCTzALUo3xD2ANoaqRc1a0SbHStpiwIeII5iyHwv06RomUzZgr48/9isQf7HyVIHrxpY No8d2Fz+ZneZMpGyoZvAIcJ7TU3tVZbetcv9ywPLU0X0jm0R199lMn5ON3wAWFQDpfnaf5aez Qg70UAzCClDFb3+O9UU/NFTuAW79qz4Xs/tqDzbDi1THcaaXPBaxAEwwmdf8v3tmpaOffL59q 08vujnFk/Ro1CpdmY7ZrnbxNJh9CHfeE3bRp0PrAnrbOkK0ABTy8Ugf6qyTGYKEe84uI3K94y BEoO1IAQDfCtGiyqiSdsMuUoMYXaD8ISly87TM3jDbsFFJGAUK/NBgt3T2kOX/X4Q0Ha2Spy2 EZWUz99na2ZnjeEFu7xEhImkMv/7WZAQP69smXksev6UBseHKqmI9gS5ddijkMk4N0Z6zvweY Tz8neYrmqjWNGZyt9Gu1KL67EA1F3y3rWn8esmGaTXwAfGIltVnF5bom2VQ+zzGQgWU+xa8Ox /pRtxoQb8g9qAejgppZ/0VZgFjeRgfiuhb4R4Hrn2PE30VHTasy1RZJzjTh0WLSAjRQV6E28X tEYABeHG61ByFIvcSaTH80ZJmvQmkiqn7FFFtU3c/1XEbVMWqW00NwKumI2Y5L4lFumUQVz6l QAcu/8wNVc9uA4mSu4e8XqbQRGvEXl9TO/tnkToweJiXuHYhTAE2iYmaKUdyLJ4HtG8PC2bcH GbklnATYlwfwcuc6tPE02IvZx6tfahIA0eKGXZ+a5xi1zV0oyewQK/EIyczZmYjEhsS9Ps47F LujWne3kcAYR7XAoeqaTgT/HjhtnAQcVCxlEMME0uOCrz/sVF1BsC7XyCc/H5zX+M8fq2vK2i 5QV1bW8kVS1/6gkfQxml4WWHto3H73gykJ44FMPf6olkVyRhnK28v4sswq/v+TpnTDDI9tBOE UFAAllKKUK6OF2wQdI+A2gOyt8a01chw8AJK8bsxB2wZxqhB3rkmDpkOJMznPzFwC/ZUqDi4u 3FKia10VAnthF8= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > But the problem I'm seeing now is that the first time > org-set-tags-command is executed its popup is correctly sized (with > said workaround in place, of course), but further executions show a > popup with the wrong geometry that trims part of the text off. If I > remove the "just once" clause in the workaround, so that the redisplay > is forced after each fit-window-to-buffer execution, then the layout > is correct every time. It goes without saying that > org-set-tags-command is ultimately triggering the execution of > fit-window-to-buffer, but that stuff you probably know much better > than me. Thing is, there was no enlargement of the modeline > in-between, as far as I can understand and see nothing changed in this > regard between the first and the second execution of > org-set-tags-command. I'm not sure I follow. What is the purpose of "the redisplay is forced after each fit-window-to-buffer execution"? If you want a new mode line height to be taken into account by 'fit-window-to-buffer', you probably should do any such redisplay _before_ executing 'fit-window-to-buffer'. Or what am I missing? martin From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 04:45:36 2021 Received: (at 38181) by debbugs.gnu.org; 15 Oct 2021 08:45:36 +0000 Received: from localhost ([127.0.0.1]:38052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbIqO-0002BE-Ln for submit@debbugs.gnu.org; Fri, 15 Oct 2021 04:45:36 -0400 Received: from mail-yb1-f177.google.com ([209.85.219.177]:40753) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbIqL-0002Ax-7k for 38181@debbugs.gnu.org; Fri, 15 Oct 2021 04:45:35 -0400 Received: by mail-yb1-f177.google.com with SMTP id n65so21005490ybb.7 for <38181@debbugs.gnu.org>; Fri, 15 Oct 2021 01:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=PtfXud7fMKZWt+d1bl6ZM37eyJCbDlUOVxMa+hrSqjw=; b=X4amzhs/KMwVGYkYiywx/IL6xklUyZAGbrE0uqdNX7K+icMCkRvmSEwSm8iME26QIF jQEGrb+KFDUG+a2C5XFgJgLZkkcZ4KezfL6WxX3PqORsjC3XQIe/w5ko+wijlmmBLCyQ vvFDY+BmJW118lBxEFBsVoQgAH+VtuAEh/bMy4YWIDYF4rOYLE6psPGMiNeGLnjpaH+Q wxkzO6VMUjc2Wk5i9tfYZE0Y1AoTUgPeqN7Vq3lW51iDNzqGNThNzKHBl1eOpLvyGS7S fQmZy7Rugr/noAPKNm+yzbfNX176rMtk9hvSYYtFIJ2VeS9x7ZeUcihA4zJVvEjyFyMa dSiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=PtfXud7fMKZWt+d1bl6ZM37eyJCbDlUOVxMa+hrSqjw=; b=GyZcBZbZGfTvQ3NHcUcOJbiXjNQhBpWMjqh+HOSKN9N5RfnKImTG0FnVVNBxZQolIo AsoTxRJKeOI6PtagpAPJ831JbhkBc/XpejHS4cTu8eX8BNm1pGWGXIKHaQl8JXGLujKs /Ld7xkq6OxGR03z6tMscBNWFv09N45usNcYixZq48UqWuoJ88ioVMNhCKnM9EOyCmKwx G+SbGkTPl7vRIHH6FvWCCCS2sFz+Qo2GYWD5N+OMu7pJrhSVXkt/yvNY38n6kIXPAAeD 3vJ2v/HokCONYIgTrq4F6UTAQ+sMeGDNPdulOCX3B9IHGgBs+A3YgG38+XbybM1AXEcA P1KQ== X-Gm-Message-State: AOAM531UH3wLe/Km0JbpPpNh0mC55dR4Pwd1D9qgz7UImxDwzjFHXBM9 0gvCF9A5tIf95gnwWu3TrInmoFOtMdv09dOKuossly6BzC7tBg== X-Google-Smtp-Source: ABdhPJw8JkkOch+KoeG84eTWkla4VO3DqbwP1HrVu2ENR9Wi1ErOV9+dwWmSgkPDp1FUf8HK1bEg418LVmlk2vx1VEE= X-Received: by 2002:a25:e7d7:: with SMTP id e206mr10861809ybh.267.1634287526419; Fri, 15 Oct 2021 01:45:26 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> In-Reply-To: <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> From: Carlos Pita Date: Fri, 15 Oct 2021 05:45:13 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: 38181@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On Fri, Oct 15, 2021 at 5:35 AM martin rudalics wrote: > I'm not sure I follow. What is the purpose of "the redisplay is forced > after each fit-window-to-buffer execution"? My bad, it wasn't the best way to express it. It's executed before, of course, it's a before advice. What I meant is that previously we had the sequence: 1. redisplay fit fit ... and now: 2. redisplay fit redisplay fit redisplay ... Supposedly 1 was a fix for: 0. fit fit fit ... but now I need 2. Best regards, Carlos From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 05:08:14 2021 Received: (at 38181) by debbugs.gnu.org; 15 Oct 2021 09:08:14 +0000 Received: from localhost ([127.0.0.1]:38078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbJCH-0002ma-W7 for submit@debbugs.gnu.org; Fri, 15 Oct 2021 05:08:14 -0400 Received: from mail-yb1-f182.google.com ([209.85.219.182]:34621) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbJCG-0002mO-K7 for 38181@debbugs.gnu.org; Fri, 15 Oct 2021 05:08:13 -0400 Received: by mail-yb1-f182.google.com with SMTP id q189so21200637ybq.1 for <38181@debbugs.gnu.org>; Fri, 15 Oct 2021 02:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0daV2KZvFJCySNPUJQogXta/zzlBOqSvyotWXW6cyS4=; b=J6v6utM3e6gwpEdnJf6GxeziqCFLy1CS++ZdQzzGVGF54A+YmginLHkUUCVNv3rQRn egFBvOYUqLoc9tKxjh67X5D/9xIe03Nyjw79WIi/Ulx8B5RJ9Pv+YQXek1TwowAkQpMf Xzw95cSBRnFLxSk5ZTJnHWGJ5FIsAgLA+gXzYP8wv/UpThV5dSKoYRmIOtNNYnmiw5RK QLASz7nbA0IHMV7hYihyH2OXjx5MqJzPdsNCX086T8OGE+uZnQZgk7rXzY+y/o91ZXrk yv4pH8+B8cysbftaW4ol648a1WFXFLmNLzZdIlSVU1DU4ew4D4DX75TfmvznJabyRJ1L 4sAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0daV2KZvFJCySNPUJQogXta/zzlBOqSvyotWXW6cyS4=; b=GlUIl9ZdHZrDwoKSdCeSFkXTfVuHK/2dtu1E4rgQvLOZa33iXYy+8H8XIHXaku7AAr jPjLUb+rIDSxu1qWVVE/tN77ewas+hUfvfB//wis32WrmMlnvZyZQbo8K7wFgx7bk0v4 lKPUWOA/PVAMTqa+JkKb8bQikt5t1atZAkHQaIPXFiBsOyHz+D1Wi4Mo64Lr3eA2/mbw 9PbBEru0q5iMalwqHNE/n95ios3O1UIPCsIP/b8WoNllD2WddnFFUfci9ExxfyLVcZQx n820tFNPpFZOECQ4G3/KECr5jfDNIkR9LdoL3zOoMQxDau9K8wfTPhKb3tzWzyDH3/c8 +Brw== X-Gm-Message-State: AOAM5323mN2JEUc1cf0lc+o/CSOJio9mCt/9SdnyUS+FQMMIRPwHimey 7rWfuymFOp3SjARFEo1xcLzY0BYZCcKDqFSodpE= X-Google-Smtp-Source: ABdhPJzptSupEvG4PuEzeLeGeI6DeWIPz5Vr7k7izEFhXeDA2MTclT5rjyJSybOkS5MkC/5ohTNpGvMaA/ey+BKVZqE= X-Received: by 2002:a25:49c3:: with SMTP id w186mr12037308yba.429.1634288887123; Fri, 15 Oct 2021 02:08:07 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> In-Reply-To: <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> From: Carlos Pita Date: Fri, 15 Oct 2021 06:07:54 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: martin rudalics , 38181@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) > > 2. redisplay fit redisplay fit redisplay ... > Sorry. I still don't understand the purpose of the last redisplay here. It's not the last, it's a repeating sequence, I left the dangling redisplay instead of ending it in a fit because I was explaining my unfortunate choice of words when I said "after", but it's formally the same, the point being that the first redisplay is not enough. > Does > > 2. redisplay fit redisplay fit ... > > fail? What are the values returned by 'window-mode-line-height' after > each redisplay? As far as I can see this works, as I said before. In the example provided by Jonas window-mode-line-height is 29 immediately after calling set-face-attribute, but after setting mode-line-format it's always 60, no matter if I call redisplay or fit or none of them or in what order. But even if the reported height is the same, the layout is not, omitting the (previous) redisplay always crops the text. Best regards, Carlos From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 06:41:00 2021 Received: (at 38181) by debbugs.gnu.org; 15 Oct 2021 10:41:00 +0000 Received: from localhost ([127.0.0.1]:38262 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbKe3-0007YV-Uz for submit@debbugs.gnu.org; Fri, 15 Oct 2021 06:41:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56100) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbKe2-0007YG-55 for 38181@debbugs.gnu.org; Fri, 15 Oct 2021 06:40:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41040) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mbKdt-000201-UK; Fri, 15 Oct 2021 06:40:51 -0400 Received: from [87.69.77.57] (port=4162 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mbKdA-000839-5g; Fri, 15 Oct 2021 06:40:23 -0400 Date: Fri, 15 Oct 2021 13:40:02 +0300 Message-Id: <83a6jak1vh.fsf@gnu.org> From: Eli Zaretskii To: Carlos Pita In-Reply-To: (message from Carlos Pita on Fri, 15 Oct 2021 05:00:19 -0300) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <83czo6k9p1.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Carlos Pita > Date: Fri, 15 Oct 2021 05:00:19 -0300 > Cc: 38181@debbugs.gnu.org > > I don't know if it will help you dealing with the problem, but I > believe that what I've just answered to Martin is new, indeed the > workaround that was working before carefully deactivated itself after > the first forced redisplay. What I can't see is why after the first > redisplay, if the modeline hasn't changed, the popup will be chopped > like that (a fortiori considering that previously it was correctly > laid out). Does the recipe involve any change in the appearance of the mode line? If not, then it's a separate issue. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 14:33:23 2021 Received: (at 38181) by debbugs.gnu.org; 15 Oct 2021 18:33:23 +0000 Received: from localhost ([127.0.0.1]:40391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbS1D-0008E8-0j for submit@debbugs.gnu.org; Fri, 15 Oct 2021 14:33:23 -0400 Received: from mail-yb1-f173.google.com ([209.85.219.173]:37812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbS1A-0008Du-QH for 38181@debbugs.gnu.org; Fri, 15 Oct 2021 14:33:21 -0400 Received: by mail-yb1-f173.google.com with SMTP id w10so24862037ybt.4 for <38181@debbugs.gnu.org>; Fri, 15 Oct 2021 11:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LksQRV/z+WDaK0mTcuNt0+gkYuz57SBvx9BN7D9DBog=; b=kqOpArnwlPlEO9sOwI2SfCof2ay+shbLpDmGHDtGGedChmtMp6nlGPFH8WL+rk0xMx whnW7NZXaEPT8H/KUTpZJht8HMaqsfcEx0QSPTfYYKXUk1n1FXkKr+U6xAyxVZ7057SG SXwrAwkWouoAIqD9XhdnAffe2uErViSRlO4VlzTnRwRIqDKqooNiBfL8pNqC3bzt1wgB SOaKbYYalq3HGZvTecAgtQN1I6HGJCUyABmBnKvsr5W8lkeNQDSWkfxlszit9E7RTV3a sC2r5BT7OJBdHQ0VVfkMyVoVdUOI7HRdKP8KvEINBZ3BkRAtkYp64hTGd/UKq9Ar0I9L tBPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LksQRV/z+WDaK0mTcuNt0+gkYuz57SBvx9BN7D9DBog=; b=NiFJgdZr91OyIqZ7NnNsaKJXOCcz7Lk0EsmJ+hzV2U0pqVnw9j0h1U/DN60jVkwX2x QXfSoHM516CTXhfcTO0tzB6e/LKvUQpA+8lauwKzmX796zA9ceEkdaKIRbikSva+txy4 ZPGUJLiVlXdMmCp3klXHwORfD7CwPDicI4fSw4kz1Ks57Ab0SrfFuJTXmyVmcnDTnsYG F/uZpkYJ8qe9ZERj4ERgvWNifo6cfpJK6eIj8Zra9bwciXrbsffs9DHagfs5K7TxwOwO Cm5SFGDM71cEIMi8V2f3dPDCwPVoKpjkw5fHU0plFtxdzuY6PCtTRvAKjXXzHnAh1VHT PqZQ== X-Gm-Message-State: AOAM5301ZQQYFJxO62D0r5SQGf26HWyzV+zr7wVMdrGOH+XdAnhBSrWf SG0Yn2HTnPaP0q2P+y3BSIGbtWNVA9a2ek87d9g= X-Google-Smtp-Source: ABdhPJzByYsEmdnaWG3FGDLg33YuwpLN70GuqQ6mUfGhi1ll+jLu32Y9iHGmHrg/DyY8ROu8UoTWIQz1qI7f017mZjY= X-Received: by 2002:a25:e7d7:: with SMTP id e206mr13735860ybh.267.1634322793758; Fri, 15 Oct 2021 11:33:13 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <83czo6k9p1.fsf@gnu.org> <83a6jak1vh.fsf@gnu.org> In-Reply-To: <83a6jak1vh.fsf@gnu.org> From: Carlos Pita Date: Fri, 15 Oct 2021 15:33:00 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Hi Eli, > Does the recipe involve any change in the appearance of the mode line? > If not, then it's a separate issue. Yes, it does, it's step 1 of the recipe. Best regards, Carlos From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 15:08:20 2021 Received: (at 38181) by debbugs.gnu.org; 15 Oct 2021 19:08:20 +0000 Received: from localhost ([127.0.0.1]:40422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbSZ1-0002oe-T9 for submit@debbugs.gnu.org; Fri, 15 Oct 2021 15:08:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbSYw-0002oL-9f for 38181@debbugs.gnu.org; Fri, 15 Oct 2021 15:08:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42662) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mbSYq-0002D9-Sk; Fri, 15 Oct 2021 15:08:08 -0400 Received: from [87.69.77.57] (port=4256 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mbSYq-00073r-F6; Fri, 15 Oct 2021 15:08:08 -0400 Date: Fri, 15 Oct 2021 22:08:08 +0300 Message-Id: <83o87qhzs7.fsf@gnu.org> From: Eli Zaretskii To: Carlos Pita In-Reply-To: (message from Carlos Pita on Fri, 15 Oct 2021 15:33:00 -0300) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <83czo6k9p1.fsf@gnu.org> <83a6jak1vh.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Carlos Pita > Date: Fri, 15 Oct 2021 15:33:00 -0300 > Cc: 38181@debbugs.gnu.org > > > Does the recipe involve any change in the appearance of the mode line? > > If not, then it's a separate issue. > > Yes, it does, it's step 1 of the recipe. "Step 1" being the original recipe of Jonas? Then what is new about this report that Jonas didn't already report and we didn't already discuss and analyze? From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 15 16:09:39 2021 Received: (at 38181) by debbugs.gnu.org; 15 Oct 2021 20:09:39 +0000 Received: from localhost ([127.0.0.1]:40460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbTWM-0004H0-V1 for submit@debbugs.gnu.org; Fri, 15 Oct 2021 16:09:39 -0400 Received: from mail-yb1-f171.google.com ([209.85.219.171]:35792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbTWJ-0004Gm-9z for 38181@debbugs.gnu.org; Fri, 15 Oct 2021 16:09:37 -0400 Received: by mail-yb1-f171.google.com with SMTP id z5so25423138ybj.2 for <38181@debbugs.gnu.org>; Fri, 15 Oct 2021 13:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i6cSl7dzHr3sigVuWKA4XXGoLSeBgm+r86DQa4E/TDk=; b=jpYtptIRoencE4+TOUweBT0ncm9S1m1rUX5yUALAtqbjYQ5Lm/TnZ6vuqmB8YD7lhK jlb6ikTaqRHgiDC/ED8E/WiCcdgRKU/0mSBnrtlyuQJN5ZLikvyDzLELEYswHyrw3uDu yatxwY1RaftJzUWR/dszxXL2fyJOnufujyXJ31f/bDe01iUsTLLRcPTQug0FCW6YD9us KqiykWIEQ5vDK/38FWULONxDRdqAetKNL/3yU1H7FRoseBevQobEwBsK71gjdEqd+NZx ugJHmTvbxcdbAFIjuIcKDGRxkWh7L5RgqZ5GQ7IR6QuBkle2JZEyNhL7FQxLMagUKbE1 PGlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i6cSl7dzHr3sigVuWKA4XXGoLSeBgm+r86DQa4E/TDk=; b=rVRhgd0eFm4rzSaC477UMrN0Mz3h82RGSnYDQ+jEAVcut7CVEubV1qtZypb6JVFvuz JWQNBs7Vuwu7/j1hnUCt10wd+XL51X6zFyA4JPVbwdFT8itHq0Jw5ERtu+RqwNA1V6E8 ER2qVcsCxHiCbd0dMsx7RL29qSKVSM/Ohg7cB4uyQpBmODAe3h9F0X2TjgyUFODk3tEu di1vbnhopJx4+gx+OSucQbHdsHDhwrMPKpoBIHz0Q1wkUn+CajwqvUfh9LJ7Dyv2/uTi isNkVzQvJeHYmSSnMFmuKndHdohmKQUQR+mRPR1jqkJfxlXofytTs1K/ztLSxpq3bbYg hfxQ== X-Gm-Message-State: AOAM530a3vWxenUP68Z9hm2Xa39fooqAVQ5/Cu1MaqlqC3w7fIss/bpx ck1eIHIt+fWNpoPkEDB7dEqO4WhOhdacdO8HFb2YjIO44Vw= X-Google-Smtp-Source: ABdhPJzziIfnKFnOASGrBetVbB5gnpiB0+992K2GsLP3mCamt9UeVAlAWtBrvctT2nnWUvyM3pE1hFnAwA4XPe54wqc= X-Received: by 2002:a25:b4d:: with SMTP id 74mr13980531ybl.443.1634328569840; Fri, 15 Oct 2021 13:09:29 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <83czo6k9p1.fsf@gnu.org> <83a6jak1vh.fsf@gnu.org> <83o87qhzs7.fsf@gnu.org> In-Reply-To: <83o87qhzs7.fsf@gnu.org> From: Carlos Pita Date: Fri, 15 Oct 2021 17:09:16 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Hi Eli, > "Step 1" being the original recipe of Jonas? Then what is new about > this report that Jonas didn't already report and we didn't already > discuss and analyze? Perhaps the new steps? I will provide my perspective and the formal procedure to reproduce the issue one last time. Then I let it up to you to decide if you have already discussed it because the exact relationship between what I see and what happens under the hood is way beyond my knowledge. If after that you still feel that I should file a new ticket, just let me know and I will gladly do it as a mere automaton. In message #20 you said: > Why the need to use advising? Your recipe shows that calling > redisplay before fit-window-to-buffer also solves the problem. Can't > you do something like that only when you add such tall images to the > mode line? In message #29: > Code like 'fit-window-to-buffer' works on the text area > only, it doesn't care whether a scroll bar or mode line changed size > since last redisplay. In message #33: > If this is to make the mode line prettier, then it should be done > [calling redisplay] once, at the beginning of a session, right? In message #39 Martin said: > If we don't want 'fit-window-to-buffer' to do that always we'd need > some variable, either buffer local or even a window parameter, that > 'fit-window-to-buffer' would inspect once and reset immediately in > order to perform only the redisplay call that's really needed. There are more examples but I hope you get the gist of it. Moreover, there is the "conventional" workaround [1] which likely was a consequence of the discussion above. The advice deliberately deactivates itself after the first redisplay. So from what I can see there was some consensus regarding that a single call to redisplay after changing the modeline geometry would suffice. Now that's exactly what I am bringing into question here. I reiterate the recipe: 1. Execute the code. 2. Call test-popup and check that the layout is wrong. 3. Redefine test-popup with (redisplay) uncommented. 4. Call it again and check that the layout is right. 5. Redefine test-popup with (redisplay) commented again. 6. Call it again and check that the layout is wrong again. Specifically, step 6 contradicts the statement that doing a redisplay after modifying the modeline geometry is enough. Now you might say: but then why are you reporting this here, it is not a modeline issue. To what I would answer: you still need step 1 that involves modifying the modeline. And if you then asked: but what's new wrt what was already discussed? I would answer exactly like I'm answering now and we would be going around in circles. I understand the issue is confusing but sadly I don't know enough about the subject to make it clearer to you. Maybe I'm not saying anything new about the internals you already know, but from outside it looks different. Best regards, Carlos --- [1] https://github.com/tarsius/moody/blob/9b679400ca885b8ff51bcfd75b87f79d66c0ee26/moody.el#L303 From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 16 03:55:33 2021 Received: (at 38181) by debbugs.gnu.org; 16 Oct 2021 07:55:33 +0000 Received: from localhost ([127.0.0.1]:40915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbeXU-00078w-PQ for submit@debbugs.gnu.org; Sat, 16 Oct 2021 03:55:33 -0400 Received: from mout.gmx.net ([212.227.15.18]:39311) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbeXQ-00078g-RG for 38181@debbugs.gnu.org; Sat, 16 Oct 2021 03:55:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634370922; bh=9gBQ0c6xjzeoRvo1vf/boIWD0EIRYCrTMgEvBTHtho0=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=Ppj25iMy4FrvbCF5j8+4sZRyihvKaPPlKu2mEBPgGK64XZbox0EpP9LPYMraOxKju RQBju2bMdyvaqNAdK0+24ttWWDvbUpn7VX/oXqiLLi/Bpf8vee/+SamXKx12TYGZm/ hb4b5WFYvi6MhLhPvRFQRuF+bTMqG36J697zsEjY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([212.95.5.98]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MuDc7-1msMTP0fPR-00uVsv; Sat, 16 Oct 2021 09:55:22 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Carlos Pita , 38181@debbugs.gnu.org References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> From: martin rudalics Message-ID: Date: Sat, 16 Oct 2021 09:55:21 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:NT/+7gXbqphwUmC/V5e3JEM5BaYWR+ft+DniughhLU3YWofaPcX T+XsjlD/ZYAuWbN1Hj/MnoFXVsZXTfHKLquxXH75fsBtbB9E8kotLi0F76ZAxieBDbmcl0F lLkgYpaWfsNkcg4h2cN+g+w4zewGdRSt34os8stxDErlvLGMkTZqDYBfo9OGPIbAhQMxiVy 140gjJoaJufIjuknp/4Nw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:KekYd5pi4I0=:fVofbIA95ojBWfswm118bB DYX73roCqDaqhqRkR5WVvlfnTmjLaWRPZX+lE28JnQXcOwfIIj+lvanDeWoX5l508hdYwyz1B 3MBbijhDq8kLZ8XQjiRa5H13WHvQ+b0trpcl+pl0GrZXzApG0BEcHp0BuHFsyh1V9wDzxObyb PA2TV3Juh+oC4BSUMcbTyngJkQ99TbqVDVtJa5OhwmA7IAltO4RN6YU5GUvQ9xJXu/if+rRPn G8Pp2gUpcs1MUDWjCM+VvenS+A/cUQcY9ibsmmqnTOdUJPCioYgycdyOLXS310Wu6u8pQ3Ycy iAhleDXvivosCG0sP/4cUUfoTzx5COElFE5+j1SU0N4AKWFm5XipSZZrBUNjp2c/cnT/5sA12 cdfZRtseXeA1vh8lsU7C3q2UQSqwnbMJfJV6F002xU3MC8FhyVjhB3QGW0FlEkPm2/wjrgO8f 6zdbdV/ipLQOc+2YQU2T6mUTVDdh7uFfcEcd8Y7s3q0XQUzkxAmsIOZp6VCqxMSFtM67pMLAU YwXXsyZnC/HfsV901fBQgfqS1eMmOAQE9YbYpVP70zranJQU38VPWmcTMTrjBTptzT5MvgxiD 0Z6zNCVEI21d5I1CNVqt4ut1DswyHFO8CC0tx1bSNNFeBAsibdKh4CTfjaqMybl39EHTKp1i0 LDxz2fDv64eIovuvG5QKZuYRwk6sInm2rPUWfnY0anbW306QetvD92xugitgPwFkWoplGQyIx vAZhu95Jvr6htjQzAHmxLgmsNzLvfUx8RD5T9coS14Gxq/nhBgmVoPoG13KS7DFEY95mcuwmW D97AgmyOO9v5o/tAD26dDCVt/iMsMqjsjRQP+OCQJhScEjTten13J4h4BR4PvlljBR/EkPbZG hSo46Y+0tyoaajVTm0R6JIgcA8/E5FvNKH1tIeWwtOiP6QnMHWIeQYEEXQNB8OHERzZNirrNl yLyzp3NI6cDoeERTZmXGLYK833AQfbhtJly/2uHjKVeihqV37rrxRmA0PcS3zA4tWK85PCIyJ V2ax6IsrohA727az2ogCgUEub7xTbcP5QfGR2UeQ/T/PFNcu5a5CJ9U5KWdsU0pntN7/AdHFX BKUiOd6G7QO2tk= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> > 2. redisplay fit redisplay fit redisplay ... > >> Sorry. I still don't understand the purpose of the last redisplay here. > > It's not the last, it's a repeating sequence, I left the dangling > redisplay instead of ending it in a fit because I was explaining my > unfortunate choice of words when I said "after", but it's formally the > same, the point being that the first redisplay is not enough. OK. Can we settle on something like 2. redisplay fit redisplay fit redisplay ... fit Bear with me but I'm trying to simultaneously understand what you are doing and what Emacs is doing. This is multitasking and I'm bad at that. >> Does >> >> 2. redisplay fit redisplay fit ... >> >> fail? What are the values returned by 'window-mode-line-height' after >> each redisplay? > > As far as I can see this works, What is "this" here? > as I said before. In the example > provided by Jonas window-mode-line-height is 29 immediately after > calling set-face-attribute, but after setting mode-line-format it's > always 60, no matter if I call redisplay or fit or none of them or in > what order. But even if the reported height is the same, the layout is > not, omitting the (previous) redisplay always crops the text. I'm currently not even sure what we are comparing here. Let's settle on the following idioms: (defun selected-window-mode-line-height () (pos-visible-in-window-p t nil t) (window-mode-line-height)) (let ((val (selected-window-mode-line-height))) (fit-window-to-buffer) (cons (selected-window-mode-line-height) val)) Do you see any change in the return value here? And when you run this repeatedly as in the redisplay fit redisplay fit redisplay ... fit scenario? And with 'set-face-attribute' and setting 'mode-line-format' intermingled? Maybe Emacs sometimes doesn't cache the result of an earlier call of display_mode_line although it could (or should). martin From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 16 07:23:35 2021 Received: (at 38181) by debbugs.gnu.org; 16 Oct 2021 11:23:35 +0000 Received: from localhost ([127.0.0.1]:41031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbhmo-00042K-K2 for submit@debbugs.gnu.org; Sat, 16 Oct 2021 07:23:34 -0400 Received: from mail-yb1-f177.google.com ([209.85.219.177]:42918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbhmm-000426-5s for 38181@debbugs.gnu.org; Sat, 16 Oct 2021 07:23:33 -0400 Received: by mail-yb1-f177.google.com with SMTP id u32so1737660ybd.9 for <38181@debbugs.gnu.org>; Sat, 16 Oct 2021 04:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n4jmVdPXAhYHoL5va/nGTZ8ev9cxmZhnZrK6vQSliKM=; b=e3hZP3VKRHH1rs1YJUwPmto7Mbz6B7BpOCLUz48/F3Vh677THY3X/Z+sRWMw9uX17p l/p7DuEuinR+UdUIfXvcl4geo6pUmi62DXfHHYbUSLkuiWITCUDva9NOI8W5Lbn5slKb k+vuNrvwmH4fGfVKgIndPjj1wrkIuhJlKuw0KRs+UajeB/AMdThcWCnyyR7z+2MQZvMh UC/FSk3C1nfV4Ytmb2N7b2q+2gbd/iJ0du37VdEvNlfLrJ3nkILk8I386mY2jko7UZ7t yua9mnKXl4sxdBwCG+8lKKNMdPQGpwRng2lJKMUyBCiQCz2L7Qb3s3O2vDW8eoKa+3qH 1DMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n4jmVdPXAhYHoL5va/nGTZ8ev9cxmZhnZrK6vQSliKM=; b=D5kiTPSWJnx0LLzt06GEr6sLoN7p2gxSaov4FucsXSkpV6KwyuTFxtqpBV3EyQrwsd auqqC3UeIeJHzZ8rUQ/kfuA6SjWgzew7M5Y1VvaBUA7k/Rq7azbkakh2dn/+bGhGioqD ohzVNZ0C8KZADGWoMymwMMESrCBAYOcCnEZBXE26MsxPm3eSAJW/3e60Vb2KH1EYbTKz cSVuundbvib/UPt3TRPir5apYXL3IYgtFr86Sv63H8KwDUD2/E3PsE934W9JkNDZysZm lqp6aTbO93JUB65ra0Zr+JrSq6bbwaOARcG2TM3QcG4XMS1Z1L5K73oxhRd8Mq5xbRBt Oy0A== X-Gm-Message-State: AOAM532P4wBV1V9uJHOypLO2M/DPWwtWNco/C/3Yk7L/eMJCgqzJXL1d 9EZ4GTbQ2V4SN0XcMgxofXJ9lQsp6YSpUiRo914= X-Google-Smtp-Source: ABdhPJx4jf9HacMCc94NZ1ItiwStT0zRLSJjh66ga/+1gzG9wb/jNMgtHStza1ZmKpImmXQizJ3Up3qP+WOGmOvVtWU= X-Received: by 2002:a25:2cc6:: with SMTP id s189mr18381052ybs.82.1634383406402; Sat, 16 Oct 2021 04:23:26 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> In-Reply-To: From: Carlos Pita Date: Sat, 16 Oct 2021 08:23:15 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: martin rudalics Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Hi Martin, >>> Does 2. redisplay fit redisplay fit ... fail? >> As far as I can see this works, > What is "this" here? Well, it is "that" there :). "redisplay fit redisplay fit ..." works just fine. Details below. > I'm currently not even sure what we are comparing here. Let's see. I run emacs -q. Then: (window-mode-line-height) -> 14 (fit-window-to-buffer) (window-mode-line-height) -> 14 (set-face-attribute 'mode-line nil :height 250) (set-face-attribute 'mode-line-inactive nil :height 250) (window-mode-line-height) -> 29 (fit-window-to-buffer) (window-mode-line-height) -> 29 (setq-default mode-line-format ...) ; full version in Jonas' post (window-mode-line-height) -> 60 (fit-window-to-buffer) (window-mode-line-height) -> 60 (redisplay t) (window-mode-line-height) -> 60 (fit-window-to-buffer) (window-mode-line-height) -> 60 (redisplay t) (window-mode-line-height) -> 60 etc This is not actually very interesting nor informative. The numbers are fine, but it's always the same window and I guess I'm never in that instant when fit-window-to-buffer runs before some calculations it requires have taken place. Now, let's define test-popup-no-redisplay as the version of test-popup with the call to redisplay removed, and test-popup-redisplay as the version that calls redisplay before fitting the window to its buffer: (test-popup-no-redisplay) -> cropped content close popup (test-popup-no-redisplay) -> cropped content close popup (test-popup-redisplay) -> ok close popup (test-popup-redisplay) -> ok close popup (test-popup-no-redisplay) -> cropped content close popup As you can see, the redisplay only "fixes" the next fit, after that the problem reappears. This may be of interest: (test-popup-no-redisplay) -> cropped content (test-popup-no-redisplay) -> ok (test-popup-no-redisplay) -> ok (test-popup-no-redisplay) -> ok (N.B. I'm not closing the popup) It seems like the window was reused and the second time it got things right. My interpretation is that the early redisplay "prepares" the current window for the fit. Now, the workaround that I linked above does a redisplay once per buffer, not once per window. The issue I observe, which I believe is the same one that motivated this report in the first place, is an org-set-tags-command menu clipped at the bottom (it's not the only case, though). Since the popup windows that org-mode opens for this and other menus are transient but their buffers likely remain hidden, that may be the reason why the workaround is not, well, working around. What I'm failing to grasp is how could it ever work... maybe there was some change in the implementation of org-mode popups. I would be happy with a sound statement like "if you change the modeline height so it is different to the default char size, you need to call redisplay for each window that sports the modified modeline before executing any operation that requires knowledge of the geometry of that modeline, including fit-window-to-buffer". If that's true then the current trick could be reasonably modified to cope with every possible case instead of hooking to particular functions (fit-window-to-buffer) in maybe the wrong scope (buffer), by just triggering an early redisplay each time a new window is created. Rereading (some of) the above thread, I noticed you said: > If we don't want 'fit-window-to-buffer' to do that always we'd need > some variable, either buffer local or even a window parameter, that > 'fit-window-to-buffer' would inspect once and reset immediately in > order to perform only the redisplay call that's really needed. I believe this is similar to what I've just suggested. Then a long discussion full of technicalities that I won't be able to follow in depth anytime soon took place. I understand that maybe forcing an early display is not ideal because, in principle, we only want to update the size of the modeline, not prematurely redisplay the window. Moreover, modelines could change after creating a window, but this is not an interesting use case in real life. But since creating a window is not a frequent operation, and changing a modeline on the fly is not a likely event, would it be so bad to trigger that early redisplay on window creation? I'm not saying that emacs should do it, I'm confident that your decision in this regard will be far better than anything I could come up with, I'm just looking for a workaround that gets the job done or, alternatively, the certainty that it's a bad idea and that we should refrain from pretiffing modelines. Best regards, Carlos From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 16 12:48:51 2021 Received: (at 38181) by debbugs.gnu.org; 16 Oct 2021 16:48:51 +0000 Received: from localhost ([127.0.0.1]:42924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbmra-0008Ko-SJ for submit@debbugs.gnu.org; Sat, 16 Oct 2021 12:48:51 -0400 Received: from mout.gmx.net ([212.227.15.15]:59523) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbmrZ-0008Kb-6x for 38181@debbugs.gnu.org; Sat, 16 Oct 2021 12:48:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634402922; bh=UEyMFDOnJUAHUuFQ9Zoek/b2Sz+tzwDt8XBFxF7AMDg=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=QvfoIGby/6tApZPLhgylof95L8AJF1V7SmvTQ6U2gpEMBV5brweKmLBOp0o+apAie ypRwwNOr+qgP2/ipjPLVTXMrrDRZZ05TtQDOkAnkQNmHSd8H0cRxGRIWsKAPzuItRZ A25idhuT3jLWHRp3yEovwS2yxjr2xPDXReDYoFhc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([213.142.96.242]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MpDNl-1n4rTh0JQd-00qmj4; Sat, 16 Oct 2021 18:48:42 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Carlos Pita References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> From: martin rudalics Message-ID: Date: Sat, 16 Oct 2021 18:48:41 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:Zs6ptK9VVr4q0h7YgEJKxsNy09t/NpL+c2Jitv7b8BdM0viGEm5 E1VU7X28X/R8gGg5aSJwhMcNOHnBBWFeooRZNac9+EsTZHdoPR6JPLtROxfTR1aj1sOwI7U S6xvGxVmOalENq0SXJNRaKwY5x3nIMpBuZKjGCIkR9jk4OVOscaIBvPI+BCVZX2Z+k5mufO hhUoS01I5MC8MlDfwUVMQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:h0HPodhjXBs=:mxCu93Gh5H9Bq31dllOFbm 21eleDrlCNRKHm6psLIJlRu61knaTw8cK5qQn/YS1Yx2u0v6Gl3QA9TfIb9kN41WMBZuxnuKd IbDK9nBMenofIXNgtN9sEaMcx9i5pNmdLk9TNCQBcDS5rGpGAPm1w12J/av6CwS1uZDjKWWBT bs4hhl6+8PATKscRvNIbmlR+FkJyjTls+5T2Ff+g2zgrr1R6hRTEXGPawls1B4P0co73zp47d YdUxF62i9kmmhuMWThUnadGOn8skmh9zTeOipiBTB88xvXG1oHVC6bI3Ix2lsIjxNCqdhzDZY elUcZVgpgQyaSj6pMH7IMHLZKOLXsl4DcaF3wmTYqYEP+fxK1t7YsKcvU3FbEJqxnK9qo7JRc zYJ7yjpHg3vNSdIkkTAa5aeiVB1ueppkqm9mUkuQ/dlsRoZL5POExhlGgWgRTYY/7B2d71ikp kosbzyPwterBfJm+iu1u4in+In+NF2os7XdBGd2vA038+/ClnxwdftJhfIUORpy59JXTCmRdh yVaXnWNcjJIHp5KdAor2/whCfxzgThqEowD8B/HJmMP2yYE+bnpiAvFpxsMlCXEohU8x/WV3a FDd3wjIi6mtNa1MsJPGFebdGwgc2fWBFe9+Hs9b9WAJa8ZgS2TtMHPMe8VzBEvktBYQwIaUOh TFxLPRHxfYv65aFE4tGrwIeG21/ZS/K1aiqlBkFOn8tMYpQ2CGJ2vJBVHyR4DI+0gMfS9xezV VbsKTrIO2igJHO7x1V6+HJOPdCE5/zdA/c0kgEgdAxcJI4cIKA5fFDNsdYPEFkrIFJu/xa+Sc FfKSdgalrb4OUEVa/GyLGkB3THUwcrnEzjXt2wq4LTMQhYWELYkodKik+iNhfZ/UvpRBT099e vCMHM4xuKHqWtpYbDhcuIEI3TCKnoish4AovHziEH33yUtMT6/eL0b+ladh8elXbCLqxfVe/8 3rBXJrjYfh/PO5eU53Jy3BHpcKRZs4iAPuWmgzyG43+dQ0DjZBzvBPvX0RBmJVyZV4ejMwX17 SqaN53pxHZ7l4AlPIVTtuSC1ZvKYvDbTOrg3ubKlrd2T6PFq+uqNkEAIdHXJvY6O0dmTY+zLJ xxc5sVB+1VR4sc= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Now, let's define test-popup-no-redisplay as the version of test-popup > with the call to redisplay removed, and test-popup-redisplay as the > version that calls redisplay before fitting the window to its buffer: > > (test-popup-no-redisplay) -> cropped content > close popup > (test-popup-no-redisplay) -> cropped content > close popup > (test-popup-redisplay) -> ok > close popup > (test-popup-redisplay) -> ok > close popup > (test-popup-no-redisplay) -> cropped content > close popup > > As you can see, the redisplay only "fixes" the next fit, after that the > problem reappears. Right. The "close popup" removes anything redisplay cached for the window's mode line in the last call of 'test-popup-redisplay'. > This may be of interest: > > (test-popup-no-redisplay) -> cropped content > (test-popup-no-redisplay) -> ok > (test-popup-no-redisplay) -> ok > (test-popup-no-redisplay) -> ok > > (N.B. I'm not closing the popup) It seems like the window was reused > and the second time it got things right. Right. It always uses the cached mode line height in this case. > My interpretation is that the early redisplay "prepares" the current > window for the fit. Now, the workaround that I linked above does a > redisplay once per buffer, not once per window. What is the "workaround"? IIUC there is no "redisplay" one can call on a "per buffer" base. > The issue I observe, > which I believe is the same one that motivated this report in the > first place, is an org-set-tags-command menu clipped at the bottom > (it's not the only case, though). Since the popup windows that > org-mode opens for this and other menus are transient but their > buffers likely remain hidden, that may be the reason why the > workaround is not, well, working around. What I'm failing to grasp is > how could it ever work... maybe there was some change in the > implementation of org-mode popups. > > I would be happy with a sound statement like "if you change the > modeline height so it is different to the default char size, you need > to call redisplay for each window that sports the modified modeline > before executing any operation that requires knowledge of the geometry > of that modeline, including fit-window-to-buffer". If that's true then the > current trick could be reasonably modified to cope with every possible > case instead of hooking to particular functions (fit-window-to-buffer) in > maybe the wrong scope (buffer), by just triggering an early redisplay > each time a new window is created. Even the 'redisplay' trick will not be sufficient: Consider Eli's scenario in this thread but with _different_ heights for active and inactive mode lines. It will break things when after doing the 'fit-window-to-buffer' call you (de-)select the window you've just fit. > Rereading (some of) the above thread, I noticed you said: > >> If we don't want 'fit-window-to-buffer' to do that always we'd need >> some variable, either buffer local or even a window parameter, that >> 'fit-window-to-buffer' would inspect once and reset immediately in >> order to perform only the redisplay call that's really needed. > > I believe this is similar to what I've just suggested. Then a long > discussion full of technicalities that I won't be able to follow in > depth anytime soon took place. I understand that maybe forcing an > early display is not ideal because, in principle, we only want to > update the size of the modeline, not prematurely redisplay the window. > Moreover, modelines could change after creating a window, > but this is not an interesting use case in real life. > But since creating a window is not a frequent operation, and > changing a modeline on the fly is not a likely event, would it be > so bad to trigger that early redisplay on window creation? I think you mean with every set_window_buffer? And probably with every set_window_configuration too. Did you try it? > I'm not saying that emacs should do it, I'm confident that your > decision in this regard will be far better than anything I could > come up with, I'm just looking for a workaround that gets the job > done or, alternatively, the certainty that it's a bad idea and that we > should refrain from pretiffing modelines. Here I have no problems with the scenarios I've seen in this thread because I update the mode line caches with every change of a window height (which includes the case where a window is created) and with any change of a buffer local variable like 'mode-line-format'. So basically no redisplay is ever needed in the first place, just a recalculation of the mode line heights of all windows whose heights have changed. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 16 14:01:11 2021 Received: (at 38181) by debbugs.gnu.org; 16 Oct 2021 18:01:11 +0000 Received: from localhost ([127.0.0.1]:43022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbnza-0003va-JH for submit@debbugs.gnu.org; Sat, 16 Oct 2021 14:01:11 -0400 Received: from mail-yb1-f174.google.com ([209.85.219.174]:37873) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbnzY-0003vK-8m for 38181@debbugs.gnu.org; Sat, 16 Oct 2021 14:01:08 -0400 Received: by mail-yb1-f174.google.com with SMTP id w10so854679ybt.4 for <38181@debbugs.gnu.org>; Sat, 16 Oct 2021 11:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TgWOKl8OMzxnY0Qu9qrFF+Y8mW1TNw8GK2cZCcgJV8A=; b=AJNXseTrdngjbSgQuM4XNGKAXse3rf3mT+l+xRbtGCNAcj2ggziub+4FjmYF6pCQBd VfDRaOL9BAXlq7pgzm2D4d41zMW5j5DYWJScJFWhMfY9nVJfdf0gAdIAJ8hgvrB0WbHg vkdbl37wT3ADqt1OpPABTzC+6LHnDRFog6POk4ebFuimpe5xkUvlCEnas8u/AYjUfc6k Jxa7n9A0hKoFJu+1Irkp7I2Ku8VtNOup32Y1FkhjsSqzTHktZOJzsqgdG6ITrMrk+mp2 qVsPqXtse6+KxK//mco5oSLlyWYPAxIamYTx+ohlkL89pSi9ycIEtNdq5MnY6hvVmIUF /5/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TgWOKl8OMzxnY0Qu9qrFF+Y8mW1TNw8GK2cZCcgJV8A=; b=ZvJ1QfEDG9PQCxZRVVma5B75QscgCniGlA13TXtb9OgV/G0glLB9ewCNHxG83ePA7I Tq533FtK9JNNIeHVzeKtsZYRwEEw+MyW2f3Y1AOdTX72nX86/v1UB78D47hHT7+eBOuG ovHH2wo79LhdM7035E0N1AV+rZ3zUQ/i7JXPuwDPCdpKGCk1c/i9AEIShQagjBwEvFtc +GFtfDu59ditgr1AndFL2qDsAtyXsLHLlwIZj24pwVbrQ7U8mWH2DbAQVh/FMj+fWyKA 69mfsf113Lt8eZd1ExwB07yhviqAMmKcLghmRvrobq3h1SA8E+JTYl+gZyVTrXTl/PoU JgoA== X-Gm-Message-State: AOAM533/XDzvWdeF8UetTcKKG1vMeEJVMW+Sjs69zG39OXm1C3cGRmaV DRSCmHkgP1uOe2yzLm9WQJcair4F4rk3vO67kXDZ59PAnyU= X-Google-Smtp-Source: ABdhPJz8t61i20De/Fk6DZST1LofsFO1m59ev6rrnqT2Pqx8vf39BzbGw1nW4bXqgdDLWYM7Sgk5cS6eg4Qf15qCJ5I= X-Received: by 2002:a25:ae92:: with SMTP id b18mr20345361ybj.220.1634407262621; Sat, 16 Oct 2021 11:01:02 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> In-Reply-To: From: Carlos Pita Date: Sat, 16 Oct 2021 15:00:51 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: martin rudalics Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Hi Martin, thank you for the commentary. > What is the "workaround"? IIUC there is no "redisplay" one can call on > a "per buffer" base. The one I linked above which some packages have been using for almost a couple of years now and, indeed, was mentioned early in this thread but never questioned AFAICS, namely: (defvar-local moody--size-hacked-p nil) (defun moody-redisplay (&optional _force &rest _ignored) (when (and mode-line-format (not moody--size-hacked-p)) (setq moody--size-hacked-p t) (redisplay t))) (advice-add 'fit-window-to-buffer :before #'moody-redisplay) The problem I see with it is that buffers often survive their windows and are later reused in other windows. This happens with some of the popups that fit to their buffers we are talking about. Moreover, using a window parameter instead of the buffer local won't be enough, because sometimes fit-window-to-buffer is called from another window (I mean, not the popup window) after the excursion that prepares the popup, so the redisplay ends up running in the wrong window. > Even the 'redisplay' trick will not be sufficient: Consider Eli's > scenario in this thread but with _different_ heights for active and > inactive mode lines. It will break things when after doing the > 'fit-window-to-buffer' call you (de-)select the window you've just fit. I think I follow the argument but I don't see it as having practical interest for the use cases that motivated this report. All modeline customizations I'm aware of use a single modeline height, although the modeline contents and faces may of course change with major and minor modes and activity status. > > changing a modeline on the fly is not a likely event, would it be > > so bad to trigger that early redisplay on window creation? > > I think you mean with every set_window_buffer? And probably with every > set_window_configuration too. Did you try it? I still need to refine my concept of "on window creation". When you say "with evert set_window_buffer" I'm not sure whether you mean something like: 1. There is an event (a) of window creation and later and event (b) when the buffer is set for the new window. So if I call redisplay immediately after (a) it would be too early because the modeline won't be properly set up until (b). Or, instead, something like: 2. Windows often change buffers and buffers may have modeline formats that imply different modeline heights. If 1 is the case then sure, maybe it's a different event that I need to listen to, but it's still one forced early redisplay per window. But if you mean 2, again I don't see the relevance in practice. With regard to set_window_configuration similar observations can be done. > change of a buffer local variable like 'mode-line-format'. So basically > no redisplay is ever needed in the first place, just a recalculation of > the mode line heights of all windows whose heights have changed. This is good to know. Thank you again. Best regards, Carlos From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 16 15:42:01 2021 Received: (at 38181) by debbugs.gnu.org; 16 Oct 2021 19:42:01 +0000 Received: from localhost ([127.0.0.1]:43116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbpZA-0006M6-Qt for submit@debbugs.gnu.org; Sat, 16 Oct 2021 15:42:01 -0400 Received: from mout.gmx.net ([212.227.15.15]:50423) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbpZ8-0006Ls-Pb for 38181@debbugs.gnu.org; Sat, 16 Oct 2021 15:41:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634413312; bh=rNt8mwMN/PDLD1ULlfTEbHvrnl8FEATIoMIdP7cvlHU=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=VxCE8dlOAua9RKcySTKK1kBLMjFm4+4pVTdYFqt4v3+/gKv/RWX6wRX2gAyE9edJ6 ztgRczfaOYbqG07J7fstqTLVvn4M3A8zwzQjLX37cWVszXzMguMCSR7zGZ7LHHMHO9 PxyJpLq8ICINIqSJMenGN1Bw3r4/vjOBt9esy5mg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([212.95.5.68]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N0XCw-1mz9jf4B7M-00wRnG; Sat, 16 Oct 2021 21:41:52 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Carlos Pita References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> From: martin rudalics Message-ID: <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> Date: Sat, 16 Oct 2021 21:41:51 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:5WKypudpyTp0dk4Up2bGLXhpnqtzox3Nh1T4jRvJO5n+2ltVohc GDvXsuNpSJXO+iU2KNjQFrAIJ0RGBH28N4AgDIUYaCGHMP3afj5GtlZDHqXYPyuLFMr7dD8 xKWxpRR/4IqwKA5mxbp2b1lZBidvCeIHHaw/kEAzL0eoqgvDEAR2AXibaYIYCe4Lhc5Qphb 7OXx5HWhxvvBh12nv6jGg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:WoRiiEpYglI=:3sgEeg7VvhHc5w9Mu+nryk WKWcJn5dx58MyRR1UVhbCicWCvs8OTxAVRELZS3U6gj+xh06lXCJmSs8B5zVzmMLru6BmaIHT D+pppIM3EwHBXdvHi9urmOyBUZK68D6Ycx16qYj/a66ODqMxdVD/67ua+H6tkqkS5Nxyp9xSr fsfKZnptcY9SUnJxT+3ZZxg4b3I6fKMHgQ9bjTAYeu17UZGYkn0dd/m8+x9TW1SkkPMfnuDbB 2871m+cyY+y8cL+TSYXKMFlyue6DafRsPUesdHOXJwFU9/g6Fmjx38GkyiUZMMb428a3q/JPQ tsGW3Rr6ajea5GS69o2q7sCSjHypKtpWusR/ig9sKWQRw3qYIxF8esIFuT0g9c9jaygBgDvp8 +yVyQng9nyRF+e/glPO0Ofa42A2ptC1pkCR+dWCOA1/ABDuPd3QpyyaaCpnWpvUpE7dG3raHF VjGrODq/NnRQEPk/CBShR2eX/qFXde0Y2kETROKy0i2M2rOh20hr6Iz9vnXZrRxSkcaQJ8d4c Sac6bUAiT5PIp03uHwaCTZVOSDzGG58G6wt9rfwhop8OPQhv+gQNg7qQpv31RUeRFxGXSf9dS QglUhjZOCvpZwPScubue9Z106HJEsZamwKFxFtqZkUJlQ+T9xZUhiHNnvunVwLJPVwJxkDZAa HIsmeJAQSPO89HXiqOYzMe87nz25gyvac9584XZrrjUMoebJ1ONWYbfFxwMLozBpsoKUcuM8t W3jCsDwIlGUFinhZxLj8aGIoW8y2K4blKVXxb6HG9DtoO2BckXp5Wq6y3tyUtGWpRVxFowCMs qB9ZwE+WI+YynWdXy5GNfP3zuGQ/ZsXlbYkHBvlBwLldNngR2dEurlHaurR5B2b6edLgGzKs/ LO+m28Zn8eu5et6GIaPisOZ/MDO0Fe4fEObx/fIy2FciDDFKyz0kX+YK1fUbrlfrb7Ym6CS9o A4ZJsCKXMdpRn0F6rR/FuQcGpEBcfJE+dpwb5rwqBGhNqqd8HPmKeaVquGCzfNapOwBPfioq8 e84CtRvo325e+uJ8mtiCIJFjgP23oZCh5x6o3XGwm9xYD7OH73LDjpREdc1Q3O1JkPC9Kw8zz 4HZRZiLiGI0zdc= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > I still need to refine my concept of "on window creation". When you say > "with evert set_window_buffer" I'm not sure whether you mean something > like: > > 1. There is an event (a) of window creation and later and event (b) > when the buffer is set for the new window. So if I call redisplay > immediately after (a) it would be too early because the modeline won't > be properly set up until (b). Window creation means 'split-window' which assigns the new window a buffer that appears in the window that was split. > Or, instead, something like: > > 2. Windows often change buffers and buffers may have modeline formats > that imply different modeline heights. > > If 1 is the case then sure, maybe it's a different event that I need > to listen to, but it's still one forced early redisplay per window. > But if you mean 2, again I don't see the relevance in practice. How comes? 'display-buffer-in-side-window' may reuse an existing window or pop up a new one. Or do the mode lines of _all_ your windows have the same height? That indeed would simplify things a lot. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 16 15:57:52 2021 Received: (at 38181) by debbugs.gnu.org; 16 Oct 2021 19:57:52 +0000 Received: from localhost ([127.0.0.1]:43129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbpoW-0006l6-GL for submit@debbugs.gnu.org; Sat, 16 Oct 2021 15:57:52 -0400 Received: from mail-yb1-f176.google.com ([209.85.219.176]:46035) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbpoU-0006kr-96 for 38181@debbugs.gnu.org; Sat, 16 Oct 2021 15:57:50 -0400 Received: by mail-yb1-f176.google.com with SMTP id i84so102758ybc.12 for <38181@debbugs.gnu.org>; Sat, 16 Oct 2021 12:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JVFjakPY/ubSfshZgpqaNqLvcgAfS7al7lF0aoDNvFI=; b=Ysz6YKKmKj3wEQQooP7+h+5j35qgUGhh5MB8a+pf9yZpf7A2IQNHzPp8b08Wh+TXG/ tuaES0yBJ6nOftI2SsXUblg+l3hs8K5FZ1JgxFwVfkA3LBw32a0Kh9hyRhmc/mT+UnX/ NfKBlEaFQ6HU/OFl/oLkpfKEM7Wpr/EHbsd+11MQUKzeXR4EpzvPDlGpOecPCOc9tp0m 1IrhZWSz1AtImEsz9B+OhOr5lw5Tnk5W8Y2XMJADkCwhvZJ+n381nuTcOf1poea+6IMS FuKWqeGICNBRPEY4jNHRdJuuLueYFVAJj+kwiuS7IDOhySa2+al5d5TEkZfQqgaJj8hI +mpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JVFjakPY/ubSfshZgpqaNqLvcgAfS7al7lF0aoDNvFI=; b=FBodjciYNwOpbYSYofUDDwsvxIoCup4nFN2Hmz13srN+cbYdjm37XUQ+kY6bb/l3GU lcGLHhRGp/ePjF5rFNtNwGAQq0G6QI6q+Ua+1diAORqvOpY07mwH26LcG2gob5N1O+Rv SZdi0/S55U2Pswf92ZZw1mvsT8tEKY0Q8EjiNzOpi2NWki5wgysLwxyTNb540ZkSh7BO 45Oxg9d8DZPnaM2mtIhLvWbAysiZYLtScs9yWp+v79FviQhjIYW7DrY94+9AGqKVhf+i dAs69Z3CNw0xh+AGOsmse1r6G71zvwvMWesvoqaSlefznno6pkW+fDDcVG+1o5v4Brte Nb5g== X-Gm-Message-State: AOAM530iN5tlYU8owiloJISPsLXPE/8ZFWlKapqCxdYGtrjK3RKqlIrN 0IImCCEoEbdEcY87+saaBWpfTOa8FAZIYGEx6SBdnZt5OwE= X-Google-Smtp-Source: ABdhPJxu8rui7HzwwHWn5wjgLhOzQuJMukyIPxbqAD+GpmGC0F/kE8VVwBhRPsx7DDX6MV4EMkYebYsxnJORGC+nPfc= X-Received: by 2002:a25:49c3:: with SMTP id w186mr21171245yba.429.1634414264553; Sat, 16 Oct 2021 12:57:44 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> In-Reply-To: <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> From: Carlos Pita Date: Sat, 16 Oct 2021 16:57:33 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: martin rudalics Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) I was just about to email you with some questions that you now have answered to some extent. Anyway, I'm copying my original questions with some annotations. > > I think you mean with every set_window_buffer? And probably with every > > set_window_configuration too. Did you try it? > > I still need to refine my concept of "on window creation". Well, any relevant window hook in [1] is advertised as "called during redisplay", so that surely isn't the place to trigger that same redisplay to begin with... Let's go back to advising then. Here are some questions I have: 1. Is there a primitive function that is like the mother of all windows? There is no window-create nor create-window alikes, so maybe split-window-internal? > Window creation means 'split-window' which assigns the new window a > buffer that appears in the window that was split. So this more or less settles the question, but to be more precise: do you see any difference of relevance between advicing split-window and split-window-internal? 2. Or is it better to advise set-window-buffer/configuration for whatever reasons? Any or both of them? 3. If advising set-window-buffer/configuration is the preferred method, I'm still assuming that we will keep a window parameter in order to disable the forced redisplay after its first execution for the window. Is there any reason not do so (taking into account what I said before of the target use case: a single modeline height for every modeline during the entire session). > Or do the mode lines of _all_ your windows have > the same height? That indeed would simplify things a lot. Yes, this is by far the usual case and I believe it's a fact that favours the "advise window creation" strategy over the "advise window buffer/config change events" (with or without the "just once per window" clause) strategy. Thanks again, Carlos From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 16 17:27:29 2021 Received: (at 38181) by debbugs.gnu.org; 16 Oct 2021 21:27:29 +0000 Received: from localhost ([127.0.0.1]:43173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbrDF-0000S5-Ln for submit@debbugs.gnu.org; Sat, 16 Oct 2021 17:27:29 -0400 Received: from mail-yb1-f176.google.com ([209.85.219.176]:35614) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbrDC-0000Rq-Uk for 38181@debbugs.gnu.org; Sat, 16 Oct 2021 17:27:28 -0400 Received: by mail-yb1-f176.google.com with SMTP id z5so1616352ybj.2 for <38181@debbugs.gnu.org>; Sat, 16 Oct 2021 14:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CprVo4WXmUKiwa0ftmH06ljjr85a4ql5mQO/1woyJHs=; b=b21k0YTFSLh+R30gdOzV/A6IRMQlu7n3m4NlVk8FZpsF8dKuBMa9XPdo2NSgM6yTY4 EZKsgD23wBUSqMd7uCrJEKUFCG7tjQbtEy+xBKIa836QjyBpgHzT+zMF9ZelBazOqPXD f4Ny0t+sjTzyTp1UimDeGoZJ+yf9YTNUw/t4v9nGfkX4sFM285jEPngRqPHhr0OZZLG0 un5SLr01d5m2FtkpHkSICEC9XLoe9m6WtRalYJ3X7XK3n8vk/LF/kWUFF09sdLYxY9yl r+lJrNt9dnVhYIpENf94rI4sba24ZEiNpk0yseubjxxZ5ETpe4zDaN8KIVa04mmbj+Rc fWFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CprVo4WXmUKiwa0ftmH06ljjr85a4ql5mQO/1woyJHs=; b=O/HMsFE3TBFup/YAep1y3f7mf2tlWWr370l4pvb8/vwkHELAiq/wadEkJnNDvsaihG S5mSPMqbnofUtQQDAXuDaIrnjowPv6dhHrPJvOD5Zn6uws/1vh+XKyX5WW+uO32uV3xx nQfcirSjAK8G7MCRkYJhxuJ5j02SxGVeDv4rolTTahDbxKXsqPpiYZ5Lhdu5KvoK6qSI mSKpIpBQfmraRO8L/QA0J/WzIjkUIqp0LEdtVv0W/XscyKqFs1d4ynTUWRFYlf7d4r7x qZ3arprqAd+EWwMjINTCCLVJs3tJZxsahLyD39OsIPQw1IPAJdTAOlz706DzRn1XlvDt pR3g== X-Gm-Message-State: AOAM533fSlX4A/wXjxN35ogVaSbGLGxgFMAJNCEFKJk29B1rKEXyLTI9 r4lGoTwiYodn4S9CW/pApaH6fD3cOF4Z67nBtHw= X-Google-Smtp-Source: ABdhPJwQHR9uKwA1WzG6ZC6G8g172fN5ChBgTkZM6NN2NIMpM0zUBVoKRMyxzq7M+0vH6RP5ldjb0LZITtE2+dN/O9A= X-Received: by 2002:a25:b4d:: with SMTP id 74mr19170983ybl.443.1634419641438; Sat, 16 Oct 2021 14:27:21 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> In-Reply-To: From: Carlos Pita Date: Sat, 16 Oct 2021 18:27:10 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: martin rudalics Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) In practice this seems to nicely cover the relevant cases: (defun my-redisplay-hack (&rest _) (when mode-line-format (redisplay t))) (advice-add #'split-window :after #'my-redisplay-hack) but there is some flickering because the window is displayed before the fit and then immediately replaced by the fitted version. Although I see no way around that glitch, so it might be the price to pay. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 17 02:06:17 2021 Received: (at 38181) by debbugs.gnu.org; 17 Oct 2021 06:06:17 +0000 Received: from localhost ([127.0.0.1]:43466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbzJJ-0000fp-23 for submit@debbugs.gnu.org; Sun, 17 Oct 2021 02:06:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50760) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbzJI-0000fe-4F for 38181@debbugs.gnu.org; Sun, 17 Oct 2021 02:06:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45664) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mbzJC-0008T9-If; Sun, 17 Oct 2021 02:06:10 -0400 Received: from [87.69.77.57] (port=1037 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mbzJC-0002cP-4T; Sun, 17 Oct 2021 02:06:10 -0400 Date: Sun, 17 Oct 2021 09:06:13 +0300 Message-Id: <83a6j8gp7u.fsf@gnu.org> From: Eli Zaretskii To: Carlos Pita In-Reply-To: (message from Carlos Pita on Sat, 16 Oct 2021 18:27:10 -0300) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: rudalics@gmx.at, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Carlos Pita > Date: Sat, 16 Oct 2021 18:27:10 -0300 > Cc: 38181@debbugs.gnu.org > > In practice this seems to nicely cover the relevant cases: > > (defun my-redisplay-hack (&rest _) > (when mode-line-format > (redisplay t))) > (advice-add #'split-window :after #'my-redisplay-hack) I wonder how this fixes anything, since split-window already triggers redisplay. Martin, do you understand the difference? > but there is some flickering because the window is displayed before > the fit and then immediately replaced by the fitted version. Which means there are two redisplay cycles, and the first one (which produces incorrect display) is the one from your hack. So once again, I wonder why that call to 'redisplay' is needed. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 17 02:45:25 2021 Received: (at 38181) by debbugs.gnu.org; 17 Oct 2021 06:45:25 +0000 Received: from localhost ([127.0.0.1]:43507 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbzvA-0001d5-OK for submit@debbugs.gnu.org; Sun, 17 Oct 2021 02:45:24 -0400 Received: from mail-yb1-f170.google.com ([209.85.219.170]:37481) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbzv8-0001cr-Ui for 38181@debbugs.gnu.org; Sun, 17 Oct 2021 02:45:23 -0400 Received: by mail-yb1-f170.google.com with SMTP id w10so871245ybt.4 for <38181@debbugs.gnu.org>; Sat, 16 Oct 2021 23:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9hDI/KgKfuNJLeW2hJGfAp3TVc/YMEYbdX7fnvmKk0o=; b=gJkhBpyjPAr/kIiUMTH+qcD4dC9pj5j4nDLX9am2DwkveCUpblvw8eyEIacmNd93TX PGjvVbsp5RsiWdzbZkg1uX3VlYfKNvLlhFufV4DIQusl/hQ855zH5vrHF14LvGYLdlJ3 84izlW9+rsv//2ciKUc7iay5po253I4ZOnAI7OoismhxkVa5ZNIYEFIpGgIETsAOnMoE 0T2QFIgRTa3zukGTuMtx7NMAOZvCs8wm0MWMzXHGF2QFwup7F7hf1gjTyJHj4oTdGso6 79oLOSxiPQdqwpt97qxnVtCSZhgFoomTBykrCQ0xiadTZqLXrWKQ2Zgd5Y3KLRaOb8Kp 1EKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9hDI/KgKfuNJLeW2hJGfAp3TVc/YMEYbdX7fnvmKk0o=; b=IjBjysS3UFIfHgZa+y8hzfqWbJdanoLe5LDqHqa3QquQwCfouwDuOMT8EJREJSis1R ijzBQiHXiS4zL7X1DSgZxzGX6kydG6vT9gu3TIuGygh1wLfBilLcNaCw5/7ilwP9OLIf QUBxVIpwvzk+GrmrC5DG4EXhjslkLorZ5MIxI8VmzQhwiMVIAV+LSAxgxb7C/7t0UUDL x4MISaYNX4e2V2qtdd6cdRZbyYGj2QIIi4baPjrtCvj8fE01+MFapFehmziwyfPlw35K tY3+BYsCnLUQWgUm69mhnWNSOvDZ2qskMMefXDEtdhHKF+UP/Ikr0sVsPG7eMQeSUkfd Gsxw== X-Gm-Message-State: AOAM531Y/5kP8MiGpYb6gg6s/APnu7GquHe4a7G5hehD/VII4sovb9Yz UGUH0X2t7GMB+iAgZdjQdSPl7EtJxkA/LRsrR8o= X-Google-Smtp-Source: ABdhPJz8vcS8o91JEg2LNbUWE4PD5i9SVTI8n1lmGZIS4IAInDComGKeglkA0yw9GGcaijaJsxpQDJbgNcpvIpig488= X-Received: by 2002:a25:ae92:: with SMTP id b18mr22773626ybj.220.1634453117188; Sat, 16 Oct 2021 23:45:17 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <83a6j8gp7u.fsf@gnu.org> In-Reply-To: <83a6j8gp7u.fsf@gnu.org> From: Carlos Pita Date: Sun, 17 Oct 2021 03:45:06 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: martin rudalics , 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Hi Eli, > > In practice this seems to nicely cover the relevant cases: > > > > (defun my-redisplay-hack (&rest _) > > (when mode-line-format > > (redisplay t))) > > (advice-add #'split-window :after #'my-redisplay-hack) > > I wonder how this fixes anything, since split-window already triggers > redisplay. In the use cases discussed above, IIUC the problem is that the redisplay is triggered at some point, but only after fit-window-to-buffer has already taken place. Consider for example what org-attach does: 1. Create a new window 2. Enter a window excursion and insert stuff into the new window 3. After the excursion fit the new window to the buffer (this is done from another window) 4. Wait for user input Seemingly, at point 3 the redisplay has not happened yet. The redisplay-before-fit advice won't work in this case because the current window is not the popup anymore when the fit (and hence the forced redisplay) happens. Another different example is org-set-tags-command, this is what it does: 1. Create a new window 2. Enter a window excursion and insert stuff into the new window 3. Inside the excursion fit the new window to the buffer (now this is done while the popup is the current window) 4. After the excursion, wait for user input So in this case the redisplay-before-fit advice works fine since it's triggered inside the popup. But then the popup is killed while its buffer remains hidden, outliving the popup. Remember that the advice is really a redisplay-before-fit-once-per-buffer advice, so the next time you call org-set-tags-command it will fail to redisplay. This is why I believe these cases weren't properly addressed by the previous workaround but are now. > Which means there are two redisplay cycles, and the first one (which > produces incorrect display) is the one from your hack. So once again, > I wonder why that call to 'redisplay' is needed. Yes, I know that is the cause. The redisplay is not needed per se and, worse, produces undesirable visual artifacts, but apparently it's the only way we have to update the information about the mode-line height before fit-window-to-buffer runs. Now, if you are saying that step 1 in the examples above already triggered a redisplay, and if a redisplay always updates whatever information about the modeline geometry that needs to be updated, then something is not adding up. Best regards -- Carlos From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 17 04:34:04 2021 Received: (at 38181) by debbugs.gnu.org; 17 Oct 2021 08:34:04 +0000 Received: from localhost ([127.0.0.1]:43546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mc1cJ-0004Fd-Px for submit@debbugs.gnu.org; Sun, 17 Oct 2021 04:34:04 -0400 Received: from mout.gmx.net ([212.227.17.21]:37051) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mc1cG-0004F5-Rt for 38181@debbugs.gnu.org; Sun, 17 Oct 2021 04:34:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634459634; bh=PverEue9XIDVUsMWhNPW44xQl4iQozxlrFcGzk2GOgI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=lcZLEc8rP4V2T6IUVp1sNVlT4B4gmez6EzWsp1FC2b++Xy/O+3i7/qDiHfYBIysNm V5EV51LPD4OifAc/uJsnYrXwmeNkwqBS1SXr3rg+UEshf3r+8CEOD74A3T1z8LWLbx 6+uBGd51HuPG7Xyda0jo+zqJ6mqsd0CfGoHJ3dpI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([213.142.97.130]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MN5eX-1mLB1I3qlh-00J35H; Sun, 17 Oct 2021 10:33:54 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Carlos Pita References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> From: martin rudalics Message-ID: <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> Date: Sun, 17 Oct 2021 10:33:52 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:JodvF73p2WBtW3fVOIsTM0Mc3HNuXSdtKsMPb5WKFADkul+PYgS swC92j9ElPbxEiQWr47LfORGp9zzP0wnqtInCCj7RJUIsBu763xFE74zbSHhsN5UKbOprcl Bq9oJoXxRhqkfyBUu4TxxNj16kv1zlCIwUPS8VZUfW5G5yOBIri32zhVtDrNWz8wK93NEZr EGZ4vRRf8BKB+3Q6gQ8bQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:V04FSRT5k2o=:yqDDKx0fKPeCGtlkXxtqB4 yOgsKnU9SJo3gw43Kkcw76u+JSoHEF2hNJtMrIBYjwJsJvUcox4xECCh+1M9WL5OBDWnoMB6o keatoZzvoAIRSK3mGMA/V7m+dTxw8amCOCWP0Aait4x6Qld+MrRiZZTERo54SLl6aNVyDmf6p OzJqDzAAHx01NSyI8cIDSAeVtLJ2NeWB5z8e179rKzT1XLja/Hv/jc6i07WElm2p+NIFeH9ki s7WxgpSr9ytzIyVnJxE4sZGm+RPDqZ66a3/EyD3RfYfbVHcNzYAcJQzv4hBYiS6Eu0Re/2oNq 3KdGhlJlkvoqYhxueJq1DKsljWM7ac94b1YJhvDgcOBfbLiuIrq4qZc011G67vj5HNIDbSMii gaUayzrED6cgwpWgGweDEmVHhu9rOmQpy1a6wh17pVFYB6fGJ0DoFXmYpUFOyUmV/VlKYwY6w tdFne5kUK82VzzGZf0UyS956B0pNBj/Dzaqv7rQa+dTWJIWNd8sS5SAoSITvZshFgHOcSNEkl 0IbBX1mZeGbBCopUB0ngQO6hE9YxR4cGudZHIMPWQqWrAy4wyR/SQROk3Qh41nGoynWpngvUl 1CrbJqVApLAAd091e/0J9Ww0coh1uAXcRWRI/zzvaGhIA0IUJd7HEFtnHscV8Yg/fLa7rbxhs iTqCrTImE0+Bi/K2QXxY625Pk5u2puk4mOgEwheut7pjAyKZrqksqDkcKRY4kTrMYhEYdQqT/ +hR5rcpzlbq997B4MGRoEk67REZwMXH1QStYzZ+Omn7ghtKVyhnxa4x/t3Pb8usqR3eQcS5Lk W3KlvaR+KaPhpCWhhr6AZ+lOOY+pQlcuuMMSC+1yTSVjZK/WIOUqNSDcZ5Zn0dhyq174vyc9A YstjhRn6RQ9lm56qilIpFDqjPmkjoReuvaWFV6WPRxxt2Wlr6QDrcp6qd9dmuM6CklEiOHEP8 KMw/Fc9TuMF8VGw0Yq1uk9mwqiDtzTi7GPKafgrMlJz3VWlwtF/xsIU+qxxcbVoUmCk9cG75F 0lUMJ6hMifjj2HZKkDdBAJkQ4RGtzKeYnqiWapGxaEcESCmd0yt2LXvwlWyrweB/sK6oV7wKY yixIWcdrz5F0e4= X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Well, any relevant window hook in [1] is advertised as "called during > redisplay", so that surely isn't the place to trigger that same > redisplay to begin with... Roughly spoken, redisplay calculates the height of the minibuffer window and those of the mode lines and, if any of these changed since last redisplay, does another redisplay in the hope that they stick to their values now. After that, it runs the hooks you mention above so these can take the now final (wrt redisplay) window and mode line sizes into account. A function on any of these hooks that changes a mode line height or a window size does that on its own risk. It's _not_ recommended. > Let's go back to advising then. Here are some questions I have: > > 1. Is there a primitive function that is like the mother of all > windows? I always wanted to write one to make 'display-buffer' simpler but nobody was enthusiastic about it. > There is no window-create nor create-window alikes, so maybe > split-window-internal? > > > Window creation means 'split-window' which assigns the new window a > > buffer that appears in the window that was split. > > So this more or less settles the question, but to be more precise: > do you see any difference of relevance between advicing split-window > and split-window-internal? Never advise an internal function or one with an '-internal' postfix. Such function may change or be removed at any time. > 2. Or is it better to advise set-window-buffer/configuration for > whatever reasons? Any or both of them? Both. Especially because you may want to reuse a window for showing another buffer in it. > 3. If advising set-window-buffer/configuration is the preferred > method, I'm still assuming that we will keep a window parameter in > order to disable the forced redisplay after its first execution for the > window. Is there any reason not do so (taking into account what > I said before of the target use case: a single modeline height for > every modeline during the entire session). The mode line height is window specific, taking into account what the buffer, the window and the window's frame have set up for it. > > Or do the mode lines of _all_ your windows have > > the same height? That indeed would simplify things a lot. > > Yes, this is by far the usual case and I believe it's a fact that > favours the "advise window creation" strategy over the > "advise window buffer/config change events" (with or without > the "just once per window" clause) strategy. In one of my earlier postings I falsely assumed that we _could_ retrieve the prospective heights of mode lines by calling 'pos-visible-in-window-p' followed by 'window-mode-line-height', forgetting that the former restores the previous values after doing its calculations. By looking at these functions you could derive a new one that calculates mode line heights in a similar way and peruse the return values of that function in 'window-text-pixel-size' in the hope that they won't change with the next redisplay. The 'mode-lines' argument of 'window-text-pixel-size' should then accept a value like 'update' to reflect this special use case. It might be worth the experience. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 17 04:34:29 2021 Received: (at 38181) by debbugs.gnu.org; 17 Oct 2021 08:34:29 +0000 Received: from localhost ([127.0.0.1]:43549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mc1cj-0004GF-6H for submit@debbugs.gnu.org; Sun, 17 Oct 2021 04:34:29 -0400 Received: from mout.gmx.net ([212.227.17.20]:39051) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mc1ch-0004G2-Fm for 38181@debbugs.gnu.org; Sun, 17 Oct 2021 04:34:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634459661; bh=TZWKb/9w7hpwToa0joovB9GX9bxUN14CFJB1EnkDmGQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=FuILUsEJd650a5Lc0BWQ0iP20N6SY3poQuHIWyzAdAb4DPiNBGgWa7aiRIkK3yHHg DXBQI68nTNsvAe8AEmsi9QrthXHY1m2L5ce2eQXuKPLIkzyzk8fTXjLGz9gDnBzSzd 7YPXwNIdMwDTgqKTeGdOyRJDpT6lao7i2u7Lwjdk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([213.142.97.130]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MhlKy-1nFVF647yC-00dl75; Sun, 17 Oct 2021 10:34:21 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Carlos Pita References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> From: martin rudalics Message-ID: <4d0f8146-37e3-978b-6ae1-58162e691de4@gmx.at> Date: Sun, 17 Oct 2021 10:34:20 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:19gS/zV+zUqxjLc+W/aAn5YRKRdNG+AegNgozt0TA/vddPJ3CaH EXjgFitREB1HOWa5R4p6UnauU13dYjO+IhL5th8cj9I600NQ4jTtE0LgD0V2HVSWddHX2b6 2SmFCWcCFecJ/JNi1Z7L2n4f16VAqnnS2OjPGXoJfQKdGmVfsEJaCEXi4pS1bk5IenhXCct agqvgOvrdrq1nksvJ2YpA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:tofdCtXChrE=:xREqF2deolUJAsMIF21y3T Nw/ob7n+DakMlQ4oyS6wMDeJvm6ta4ZXueOqdeHj4qEg6LuohgLeZUMIXEwCJJ6U3kT2wikRN GDtpiU7Za/guy/TUFNB6lE+woH2PcnOUG4hCtFuIcoKu0lEKddSC5x0QPjec/khyZxaxoHeFj ojOPi9LCmI+lEotW7uoLhxCQZWFnKS3VcEmIUJue+1bohndJCQc6jYLszT0rkzd1W852e5SsK GryrmMo8/H/k/g3AhjTu/oL2MasMsf+pPxp4c4pG+eW3oGXHA+vdVeJ8omwTKgDw5OeBp6C0k yaYQcOdq9fns6EuYxzsR0ga3jUTjjpOozS7GHsgoe0pGLn7mLl0t7YhEYcTGsfzuEAOkVc/ey yx7uuIlxKPczc/3tUtb6fjSo87p2VrkJG6r6Pp9mrrN1Dqu2pecRkFpCHM3Dpf2L/He1Cmvmb GaNpCXXFEjoYQzGF+4HhwAfdDAwGgvEke0ta2i+OQu8eO5nY0O4T1ws6Nh3+0tXO1f/xX0yOF QsyR7kuZQR0vfHJexhXgtXr3KlgHFKa9yJp7ixm8n6VRAOCempLK/0lqKq3C4Jyvv09sE2rgN KAlMMqS2p7Dro+cxwV38rI78J/oQUfvolbUt9dDe2riOt3wZ2kDffgetzz1tiDOWs/QGKS9Ex LiVoq1yzS3R9/2OKnqTh8u4w0sTZ+FQx9tgZ8HJabN9DIclZya0B0w/GMBjygF7yYqtHR03wC e5nRGUvXc8YImYhaEK6/7B5TR5LpW8B2Sb5KsV2ti3Uxy9iMbdx2oH6JJKI/IpcAy4e+NuBnO DxartxHa+1ommO43KlrfPvlQFxIT74DsvP+2s48CXXiean6LQZVOi9uSmAosEAwuAGTZFo7EZ gjKBnASzUO0Uc8Pih06t/aiW0qoQpM2ZcME4hf2PTqV96hEOb7HR59CmlOkNlwIbxwUDfNLCn IwfZAyVDmjWbs+w6UfQB9y4M8dyiptoFL5rt6GUFTC+mI23p8pHa7Kzd/KoDUPPqmeNLOU1ph yMy6ouKPn1VQkXFMVBDFv3RP4/9A151XMPzDXBv4la9bBfCCsl0QBGkeeUZOkpKL8+crNSfTF a4OpP4Mbra3QBQ= X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > In practice this seems to nicely cover the relevant cases: > > (defun my-redisplay-hack (&rest _) > (when mode-line-format > (redisplay t))) > (advice-add #'split-window :after #'my-redisplay-hack) > > but there is some flickering because the window is displayed before > the fit and then immediately replaced by the fitted version. Although > I see no way around that glitch, so it might be the price to pay. Nothing new here. The sequence remains the same as before: 'split-window', 'redisplay', 'fit-window-to-buffer'. And remember: People usually tolerate when Emacs occasionally crashes. They never tolerate flickering. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 17 04:34:44 2021 Received: (at 38181) by debbugs.gnu.org; 17 Oct 2021 08:34:44 +0000 Received: from localhost ([127.0.0.1]:43552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mc1cy-0004Gi-Dq for submit@debbugs.gnu.org; Sun, 17 Oct 2021 04:34:44 -0400 Received: from mout.gmx.net ([212.227.17.20]:54267) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mc1cx-0004GU-6g for 38181@debbugs.gnu.org; Sun, 17 Oct 2021 04:34:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634459677; bh=ONudAk01Ukt3LJCAWOy2klZspORPc4b1Nyv8RpFUxls=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=VoUJOHgTsafRomEVAuCgLgem4AsWZ9GSd1dyBIs1dy77pcZQ4AkMvRn24cnSvVqe/ NrsuOBVZoNeI1I0BhEwoiRUkjYkfaLPyqeJF++AJI27s8sSqGpH39raJyZVT0YOOJ1 oq8UEGdfJQpyOp4sQMUOpgKy8hO0BtHHaSFKu/Eg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.102] ([213.142.97.130]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MpUUm-1n5a9Q3AB2-00psUY; Sun, 17 Oct 2021 10:34:36 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii , Carlos Pita References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <83a6j8gp7u.fsf@gnu.org> From: martin rudalics Message-ID: Date: Sun, 17 Oct 2021 10:34:35 +0200 MIME-Version: 1.0 In-Reply-To: <83a6j8gp7u.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:R0UBzwkEvuG8hHY+zwwG4vTaVx2EwQE6nooolZUSruai6C5VpNU 6o2kTUnHXmmjwiMXyhdsHHRdSTMPgaCk4z2gubcPl8qRMjQFbw6WuHYrNjt3+nvWu9w4STc wkagkKDIQwbVRcXutSvXCCXh0UxqyckjqDnyLWGo93NuCq7zCdkhzSmpMWyvLSzuoilgXsP QrtbW3F+Na49HtkDo+vOw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:XxFbb5+7p7g=:6aelcAqOTLrccQjEQpBASS lrwUuQxZy3SspT3zEQowZoML+RsBhZ8WZtvYGv00ZL3ynCWruXZ3mK/4icN+nJkekRe6rrJAD kKVcQkJGaJ2YoedmhkdMmcwBqDVGMrl7nk0Yisgr2+et98ninVGdh18aiPWM0Kp9fIqYLd0hm q9mFtYmEq+PjhbmCBWVT8bWGGnNQMjuf3K4Cx0pDqlNE8fwzno5COB5xLHE7XbFvtAZjG+QXh ehY1Za7LHEwrh4G+yLH1Dg1+ywSZ9vMF/svevTqHHgx+LdqVNp5bAHOzNGISSN/U+So4G8Asy RryUX4/M12kHIps68gfvZEQCD4y6dsD12fWv7Mlpyd1U52cqWThekBfeQTTeN7/wBPk60qXY4 w+4v26aUZtYbrDCMcrUoCjqacrojp+IdUqR5xXZ5jt5sRpMzWD/NoabVuobZ2RjrS6YwMvPTB f6Xhs3zKv0knJd3Vr2z7IsCDLg8w35F8oZeWMA7MECY/m5W9kph76cK3oIMzTiAnND2+0dz1b dsVVtJe3Rx8s9aTuqBop3yLKMKWAE3eKvkcGcKai1Pa8XOq6WGHDnfDNAqJMAdctG4+ErNkOC nDKH/aXItjiXTp4gsf9ObeEXqByeMc86kQXGr38U3WDKyDyrSIjcb8W1bsofBBH6e8SudzdB4 qvybVeMs/sjzWC11SD7Nj6OpD54aSzSTJb7YTFIcDT1UVi6iro8Z2e+peueBLzO2YkQdHUeDO 0in+5z3GL/Tzs91GNKSY0oxII3xMiE2LDRIl9vTP4ir7fjISV5ywyPFqvHMNyQbZLgdXww2p1 hjKVTPKP9N0v9LK+o0Wb8oL93cOsYgdcJqAUM5SO/DOi2GuOd1LG4EvJWPmcXzcvwri36QuDB jo3XNfy7MLSgX3qjO4fQ5IYDLbwNCZQypDyUHWu/RPQUm0eeg20IvazqV92PAqhXhnruffgkv W1L8CQ1crn5wIBIuTCr9N02Q5NyT56+tA8HeGcw+Ph/2smN8ifN6Y/kOiFuk8YOSp2j34wfT0 08to3c/IHtA5kDe1iLqXTtALKfDO4kF5eMD/NDG/LAEWqMtwvEH3y/bNQOMfTAIwViyEij5ef U9R6ShmWjibZXU= X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> In practice this seems to nicely cover the relevant cases: >> >> (defun my-redisplay-hack (&rest _) >> (when mode-line-format >> (redisplay t))) >> (advice-add #'split-window :after #'my-redisplay-hack) > > I wonder how this fixes anything, since split-window already triggers > redisplay. Martin, do you understand the difference? There is no difference in the use cases posted here. The results will change only when a window is reused and then fit to its buffer. >> but there is some flickering because the window is displayed before >> the fit and then immediately replaced by the fitted version. > > Which means there are two redisplay cycles, and the first one (which > produces incorrect display) is the one from your hack. So once again, > I wonder why that call to 'redisplay' is needed. Where "incorrect redisplay" stands for "window that has not been yet fit to its buffer". martin From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 18 05:34:41 2021 Received: (at 38181) by debbugs.gnu.org; 18 Oct 2021 09:34:41 +0000 Received: from localhost ([127.0.0.1]:46019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcP2X-0007CC-0Y for submit@debbugs.gnu.org; Mon, 18 Oct 2021 05:34:41 -0400 Received: from mout.gmx.net ([212.227.15.19]:37877) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcP2U-0007Bv-9I for 38181@debbugs.gnu.org; Mon, 18 Oct 2021 05:34:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634549671; bh=j9O3zDemBc13KQId7+mronbnwidOCZQCX/GxaP3jUSk=; h=X-UI-Sender-Class:Subject:From:To:Cc:References:Date:In-Reply-To; b=QlI9+NhBIWNJJHwp2gZ5vP12HC9BFcmnRu9yK7e5fT7boweu2IVUnq588lTPq+rPG lQbjB4mdS7xvRtYaQnykHWh8vPjcJEnHwntgwyF3T3mM/h9FuaBpmOnZ+y4BGGBMaW Bva+wGmyG/TVuOKP4uvkTxo07c7TctePhDxbS7tI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.100] ([46.125.249.39]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M72sP-1mdkDo1VmB-008cPT; Mon, 18 Oct 2021 11:34:31 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account From: martin rudalics To: Carlos Pita References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> Message-ID: <312e15c3-83d3-99ee-ef73-8fd6013153cc@gmx.at> Date: Mon, 18 Oct 2021 11:34:30 +0200 MIME-Version: 1.0 In-Reply-To: <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> Content-Type: multipart/mixed; boundary="------------DEC360DBF328E98628F0E555" Content-Language: en-US X-Provags-ID: V03:K1:JBK8j/KMvIcVmwMFtKzK7o3eKlNt73JKjp5dDk496FQIt++4NlI 90FM5VkCb80Xdhs1tMHdWpzvV1ssd+FJHxxYnyuv35lXeE15CJImZ9qxR6g+YvKEagibfl6 /h2kicglz5cDdykJsJ7BliHtUzyskFwvfveRl7sjftJWd/onWsip4kprS5wA40cjgdzqKiE wr/qI4yrkdRhSw89eqQig== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:xQAEv1ulKow=:FSPUIrvE5g0lof1Q88gFCI YUtO12bwfWu2Qo/qyz8n+Wg8MgnWwRs80c8UUBcZCiuW53QUco2WXKoRdy12hJ8795PC7rfqu zP31+dgHghnV0Ykq3Yba7g3i2EDgO6XJH3hbabalatp8x+h6uG7vuIHL+R5x5i+3grGg3JSyQ duteZqFMYaTp1mUZ53QFJTGmOgRobmJL5j5fmDYeQV4HfUcV8CRQZDso366vKTD8FisAIqdko u+mYZLD4zek3yKYWkwbmvGAFYeMABosVjDoNetrI/xqVZCBO9Riu4cKMFgdcONwpTFhKIKKDH qErOzRWuqiZqcYE9HSkuAOANxz2VaacxBaRfGOHoCFCF5ooDfOueUEpV91hdN/ofWNIzO05Na SwSf87VsxDiP7KN6FV8U5qcTQCIby3G7zRf/loJcBvq/KbclaEAZX40GiwOkBcs0GDn8ZKNd6 U2bf5Dmy80o47ZKIx0FvdWjDw1nIks/Lwye70658Rgu7CNKsUN2drJs3KXKxnulwrrwy85Amk oOwQZXlTkbOGHQ50KXcG+acunvxOHAlwVNJcXgI688oPdySZttZI4Q84oUn3ed2+R5YbjwL7Q yRWjhshxIzW7KXeDOsb4D855tj1BXidqIXf+jj0LCUxxlgVGDfzWxUfps8mYjzSYlqHrWHBpU XYUCIxdVlS02JGGl7F4BnLHbSJUWuSkbKNa+pqz+ByoMnOjbmpGwyKBccDDO8OXhVVF+LQVqp yMUPY3P1FBAihkG6nx2knVsKBVxkpuQ8Z2pCLH0mSY6pOu5N+cnpKwdl7RrdNz8vexX3h6X6L OlVqGHL0f60194lB/gOnc2w0Ms6qLdsE9xnEFX3t72TneDqCCop24+hZJFCgkAMqKM8tiv1iL PG6ULRke6G7iqXYFhA2Z1ZbYd4zYkP2FQh/F8Z0+toek1kGJaCeRbt+TOa1A7BnY9iRRE2sZk ybldRqd0NRIO7g5YHb09x/NDfI68A1FfZqPUGCE5YylBQZfbk7x/eqRUZoUWU9xFFNvSySTvA jTdrpJR6XMWBDu2v/p/+UrkYFPRJ7TUvzx0aZLb5VZ11jO0X5KaoV4TQu57hFRD6Uqi+Xzq4e oekG5X0PROx3NQ= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --------------DEC360DBF328E98628F0E555 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit > By looking at these functions you could derive a new one > that calculates mode line heights in a similar way and peruse the return > values of that function in 'window-text-pixel-size' in the hope that > they won't change with the next redisplay. The 'mode-lines' argument of > 'window-text-pixel-size' should then accept a value like 'update' to > reflect this special use case. It might be worth the experience. Or try the attached patch on master. It seems to fix the issue here. martin --------------DEC360DBF328E98628F0E555 Content-Type: text/x-patch; name="xdisp.c.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xdisp.c.diff" diff --git a/src/xdisp.c b/src/xdisp.c index 783ef396a3..ad833d99e3 100644 =2D-- a/src/xdisp.c +++ b/src/xdisp.c @@ -10847,17 +10847,45 @@ DEFUN ("window-text-pixel-size", Fwindow_text_pi= xel_size, Swindow_text_pixel_siz if (y > max_y) y =3D max_y; - if (EQ (mode_lines, Qtab_line) || EQ (mode_lines, Qt)) - /* Re-add height of tab-line as requested. */ - y =3D y + WINDOW_TAB_LINE_HEIGHT (w); + if ((EQ (mode_lines, Qtab_line) + || EQ (mode_lines, Qt)) + && window_wants_tab_line (w)) + /* Add height of tab-line as requested. */ + { + Lisp_Object window_tab_line_format + =3D window_parameter (w, Qtab_line_format); + + y =3D y + display_mode_line (w, TAB_LINE_FACE_ID, + NILP (window_tab_line_format) + ? BVAR (current_buffer, tab_line_format) + : window_tab_line_format); + } - if (EQ (mode_lines, Qheader_line) || EQ (mode_lines, Qt)) - /* Re-add height of header-line as requested. */ - y =3D y + WINDOW_HEADER_LINE_HEIGHT (w); + if ((EQ (mode_lines, Qheader_line) + || EQ (mode_lines, Qt)) + && window_wants_header_line (w)) + { + Lisp_Object window_header_line_format + =3D window_parameter (w, Qheader_line_format); - if (EQ (mode_lines, Qmode_line) || EQ (mode_lines, Qt)) - /* Add height of mode-line as requested. */ - y =3D y + WINDOW_MODE_LINE_HEIGHT (w); + y =3D y + display_mode_line (w, HEADER_LINE_FACE_ID, + NILP (window_header_line_format) + ? BVAR (current_buffer, header_line_format) + : window_header_line_format); + } + + if ((EQ (mode_lines, Qmode_line) + || EQ (mode_lines, Qt)) + && window_wants_mode_line (w)) + { + Lisp_Object window_mode_line_format + =3D window_parameter (w, Qmode_line_format); + + y =3D y + display_mode_line (w, CURRENT_MODE_LINE_FACE_ID (w), + NILP (window_mode_line_format) + ? BVAR (current_buffer, mode_line_format) + : window_mode_line_format); + } bidi_unshelve_cache (itdata, false); --------------DEC360DBF328E98628F0E555-- From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 18 11:57:24 2021 Received: (at 38181) by debbugs.gnu.org; 18 Oct 2021 15:57:24 +0000 Received: from localhost ([127.0.0.1]:48308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcV0q-0006y8-Kp for submit@debbugs.gnu.org; Mon, 18 Oct 2021 11:57:24 -0400 Received: from mail-yb1-f171.google.com ([209.85.219.171]:38857) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcV0l-0006xq-AJ for 38181@debbugs.gnu.org; Mon, 18 Oct 2021 11:57:19 -0400 Received: by mail-yb1-f171.google.com with SMTP id d131so3447596ybd.5 for <38181@debbugs.gnu.org>; Mon, 18 Oct 2021 08:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6Ml0tXW4xwA8Y9ggc6RD6+Z5H1iOWil3BDSxJ2/QByA=; b=J8rulwrJtNg61z9oefoWlE0wODBGSEMjy6BgXkuuwEMmd9uuHpnQi6xodBQyYh/50K 3BnmfctmxcvvgmT8or7rwijVywIri0Sz47Op7g+Dp82DOHot2kj/ofxgsJ+mJD468LRP kh1XE5fWYDKy2D0hiq9i1BMcSdunS4bcChhrp4CJ9Ko3tApYq43qmBateoGXEeBQXv5n SVS6W7kR31pp5AbFERSiUZ5oXgfh8wapUYITHS7ODdXVD0K8I8oH5WlaPcjIfHZAUzGE 1aiVWs+nQAhDxknn5VosemYWGoM9okGnW68frNXnY0katj/3R/OVt9iLgnu/RE9Dwnfm nhHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6Ml0tXW4xwA8Y9ggc6RD6+Z5H1iOWil3BDSxJ2/QByA=; b=DQAU6qrB4tVKo0C3d7EunN45Onr0dIKOiGAc86d+ibRe+0Tevc5iuI4ftPN0BxovCX guN4j1tKvYGx5FwsmIk+Z6+Z9bxwHWbXc+BIxZonFALYrwiJvL2X9Cc9f7whSVUE0qL+ 1Aln0v7h3ZbhDzq0WHCodEKMHptQ+IK7HuASyiXT+Ad8LKqMjj2gCtSmnmNJU3tx6u5a RISl/hIZKUTrQp+gnoLSoTPQy9AbMkiXBXpMJhm61zXJH6vOF/yDAoIm7QZGW0gpZ6UW VtB4pEKnYpn4uaYIovvEXPy6X/7xo/Ky1ARJ9IX7f0J/z2bzxwLyloM6ljGnSWkopLDl 531g== X-Gm-Message-State: AOAM533hUjwtYFF0xNLFwTp1HzKiQg6n/cGGv9A9bSffyPl0mC4Z2kg7 GTXihn4knDJ+xOou9yRl1k7x2CwPpi1u4gLD+VU= X-Google-Smtp-Source: ABdhPJyjCwBpAecE1H89bb7VJ5EJX4lS+JAPWw4tsTRTwcsPp2VddJNVc2nngPs766ck1KL7llf1UMCN5N/pJHRnyps= X-Received: by 2002:a25:3104:: with SMTP id x4mr30182215ybx.512.1634572629723; Mon, 18 Oct 2021 08:57:09 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> <312e15c3-83d3-99ee-ef73-8fd6013153cc@gmx.at> In-Reply-To: <312e15c3-83d3-99ee-ef73-8fd6013153cc@gmx.at> From: Carlos Pita Date: Mon, 18 Oct 2021 12:56:57 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: martin rudalics Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Hi Martin, Thank you very much. I've tested it in both master and emacs-28 branches and I've seen none of the aforementioned issues nor, at least in a cursory examination, any regression. It seems like you're displaying the modeline instead of merely using the current height? There is no perceptible flickering in any case. Best regards, Carlos From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 18 13:44:17 2021 Received: (at 38181) by debbugs.gnu.org; 18 Oct 2021 17:44:17 +0000 Received: from localhost ([127.0.0.1]:48522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcWgL-0005cw-2j for submit@debbugs.gnu.org; Mon, 18 Oct 2021 13:44:17 -0400 Received: from mout.gmx.net ([212.227.15.15]:44665) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcWgJ-0005ci-LB for 38181@debbugs.gnu.org; Mon, 18 Oct 2021 13:44:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634579049; bh=t6c9kCGLxz610vGjs5XXeG4+uqnMTn/uUd6z3E4wrMg=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=kxdRRQih3WlycFTvKHQyExp1Hy01YukquMPQrRLb/xZjbR4bZAUMicKX2HU8+aX7d +Imw/wZqtmSsgXx4mhGIKYyNVeZk8hF0xHTNgx3YK1IeKNAy+UDzAv5rU3RxYHLwPS j/F4wQ3HvnsiRejfW144m11oHpjomxNpIYNeHy/g= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.100] ([46.125.249.39]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N0oBr-1mx4NI0qbF-00whz3; Mon, 18 Oct 2021 19:44:09 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Carlos Pita References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> <312e15c3-83d3-99ee-ef73-8fd6013153cc@gmx.at> From: martin rudalics Message-ID: <7626992f-ab12-5df2-9061-77cb1e276556@gmx.at> Date: Mon, 18 Oct 2021 19:44:08 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:gyJoZik3V36zKLK6i28bOLayDZQtrMPu6K7hK2926+i2gkeGMUN Rp+2RERFedlzl7qy2rhmIrQiS3EfVWT0xkWaosEhlLti2wT5VEIDBSFedTNIB7K3I5zJKFt 4TSO+WPyMPjJgzX1ky+WUpQ72a4ZKQh0N3wctqQHE7MIh6H9rY8JhcxqN/KKuh23BGkDgQb N0JM00oEulNaQX0A1NppA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Qk6HbQkMUjw=:MZKUaUyhCKNYQG2lXkMQWj xz9D0HGsFtqp9gEI9i5TYEBkNw+ME3iW3Nf6oqaq1YwSg9UidS7Q1TGhVKTr8Hwn5w8dqCsYj vOr+qZ6NlJkVBDFZ79xxh9DCeSWkzslXwtWijOMGqu1gxNHZJjgBUGVU2Las61HqwE7QC69/X BfdnhR+JajcUDKKlRF+rXantxiq/IMelSiLEuGns78qYqoZR+k44C4Q1gBCxNUBBJi4RPbyju Az5C8q7zjtLstfgSL9eLdHWZo1pX0laR+us1olBY4mThdvJZT53d/K9uIzUnCy/Tv7uxlL9O1 /rTJY6BVvYnCzx3JOK8MwYiCqLtNMJcWa1fPUDGVpF7dYPlG1w4HrB3dUESqoQ0OpSHOn16X1 I7uus+rmuAasQJrs3Kc8smH7QJGDV1LdXOKB52qh+7b64k3+eEWjxzY+n+ubnXrA/8mzRJSKP y5Zj3gEBo4unn/Ii1uJYtF/JKTXGXGNPD+ejNCu/wwTSOgtBm4Hnb9LZ9dIlkSavPBVa6tl8q 0bYQEQT+9TIbKG793DzNVgKc5W7nf0eiQLBhzpSbbBtRfFkNu5DU5o8ekOV5zWAwRU56CCibW hirW58QVzR5Xorh0XIZItSEnBHRt/zAhHfz995/qHK701GwPte1L134AnTShspWWudC7jDigl q94cBtsurNGggyTr3OaCnAak24/IGiCc71tVTuNikfwRguY9vVfgi4bNjJq7coZFzxnsxu5Nm pAoUYhge2pAgVa8lUGRFeeS/+tWoV01edbndz6pGr7j3uJYgY2gEWy7UwZ1nLmm5yTn8kWqlv zAKPnElDCtW1147QsVPy+J6BhGw/6bL2G3h1MI+aOFNCb4TVGcqI0MNSoONTW9j2VKzegtLnd and8gp1dqGgGguMiF9QlsmVRurDxcyvZdNW99P1Iw3JskHmJksgiNe3s0nvTd93YJpXG2fUoY dzfIEf4/ueRmBseXJpPtVdZRbmXbBrxbE+UW5XMOOvMaPS7sMmQo9rOBa6KRCeHwEW+jOPjGX DuOwJjHlTEsegoGrmAt7U37yei1ZYzkRN87bkVLAVgp8/Ld+d9CCMaMd+dhuMRp05q10iBn26 LzqNkfvLu/Ix6s= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > I've tested it in both master and emacs-28 branches and I've seen none > of the aforementioned issues nor, at least in a cursory examination, > any regression. > > It seems like you're displaying the modeline instead of merely using > the current height? There is no perceptible flickering in any case. There's no "displaying" involved. IIUC display_mode_line has become a misnomer ever since it's used in pos_visible_p. Basically, I do two things: Run 'format-mode-line' and compute_line_metrics on the current mode line strings. Eli, I think this could go into Emacs 28. WDYT? martin From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 18 14:27:34 2021 Received: (at 38181) by debbugs.gnu.org; 18 Oct 2021 18:27:34 +0000 Received: from localhost ([127.0.0.1]:48567 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcXME-0006go-0D for submit@debbugs.gnu.org; Mon, 18 Oct 2021 14:27:34 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcXMB-0006ga-Ra for 38181@debbugs.gnu.org; Mon, 18 Oct 2021 14:27:33 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49890) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mcXM6-0003wl-BF; Mon, 18 Oct 2021 14:27:26 -0400 Received: from [87.69.77.57] (port=2545 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mcXLp-00047u-Rz; Mon, 18 Oct 2021 14:27:25 -0400 Date: Mon, 18 Oct 2021 21:27:15 +0300 Message-Id: <831r4idw8s.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-Reply-To: <7626992f-ab12-5df2-9061-77cb1e276556@gmx.at> (message from martin rudalics on Mon, 18 Oct 2021 19:44:08 +0200) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> <312e15c3-83d3-99ee-ef73-8fd6013153cc@gmx.at> <7626992f-ab12-5df2-9061-77cb1e276556@gmx.at> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: carlosjosepita2@gmail.com, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: martin rudalics > Date: Mon, 18 Oct 2021 19:44:08 +0200 > Cc: 38181@debbugs.gnu.org > > > I've tested it in both master and emacs-28 branches and I've seen none > > of the aforementioned issues nor, at least in a cursory examination, > > any regression. > > > > It seems like you're displaying the modeline instead of merely using > > the current height? There is no perceptible flickering in any case. > > There's no "displaying" involved. There is, for some value of "display": this function actually generates a glyph row in the glyph matrix. > Eli, I think this could go into Emacs 28. WDYT? No, it's too radical, and the problem it fixes is too obscure. Let's install it on master, please. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 18 19:36:08 2021 Received: (at 38181) by debbugs.gnu.org; 18 Oct 2021 23:36:09 +0000 Received: from localhost ([127.0.0.1]:48866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mccAq-0005nb-CL for submit@debbugs.gnu.org; Mon, 18 Oct 2021 19:36:08 -0400 Received: from mail-yb1-f174.google.com ([209.85.219.174]:45688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mccAo-0005mx-BM for 38181@debbugs.gnu.org; Mon, 18 Oct 2021 19:36:06 -0400 Received: by mail-yb1-f174.google.com with SMTP id i84so515217ybc.12 for <38181@debbugs.gnu.org>; Mon, 18 Oct 2021 16:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R7oTF8ivKLhWFiArnqbm947e/eRhxp0p7ZTKR+F9l/M=; b=dL8ZgpVxzqaAbMAoivCzcnECZAFDurX/AQNeyLkhbWIO5RsTQNg1I5dMsGdUjjPq7U cAhut2SZSQU9VRgQHrtxpW9FaesDcwhaEGq20c/+oxPQdQ52rOsbG8on+k1WhGriqroD NLJ0rsr5JSKfutFB74xwlrAcKt8axRDf6dNUyhpGujkeRJJwSPbZ0WANeO7EhUD1+7SB Ms5WQpkCdnAYre67g0vE7N8QCGzIPtR29lEV1iuHAARDlBXPHOmWAfsMpOiMHKt3TP1B 3J6CLJwn669zkovg26sfs2vwoKSB/+RVAmnjliIExHXSWKI/WfAlIeSFK75r3k6tzqkB JDMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R7oTF8ivKLhWFiArnqbm947e/eRhxp0p7ZTKR+F9l/M=; b=KREOBu9B0YLT43sqgZ0/lHjqQ41rxKI/vEAYeHZOZ7IpNcnqwk831qVZGSZcwXC1O7 SuJMLDA21FPexqOSfV0de/FfMCBRORFcNVMWw7gXwZEPKemAqR0ylbhVFcnJcVpKgrrl SLI4q2/+OLuoLm/R3enLGgoN5XyayeXbpetU1eHBfM6yJz95dTj9MWAy5DhoFsgBvr33 AYBvXdD1R3BNPTpXbOQ+dRJjmBzqMwzYl61wFUbrwSN8q4L6akkVAWKZ8zvApIhj4Me+ 0BBb1M4KlXicC8feBUOpi8w7dAFVSnkGuuFrW822wYIq+LP7KAH+s1guXZ9RZgrTS5NQ ABEg== X-Gm-Message-State: AOAM532AJByl9+7miVODq1uDFFkcwpBseBm7Z4Fe3GKqRZ/iwTuF5AJE IQ8694UuFuOEdirUnKGuRYVxqivFbUkDed4js54= X-Google-Smtp-Source: ABdhPJxNd8ffnNno31fqwWBM3eHkPg1XYhWuxx1fDGyipIkARAiE3P8Qu95l+Hgbb7Li7NcnKbdJYD/6TDHRVIFErUI= X-Received: by 2002:a25:3104:: with SMTP id x4mr32421747ybx.512.1634600160695; Mon, 18 Oct 2021 16:36:00 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> <312e15c3-83d3-99ee-ef73-8fd6013153cc@gmx.at> <7626992f-ab12-5df2-9061-77cb1e276556@gmx.at> <831r4idw8s.fsf@gnu.org> In-Reply-To: <831r4idw8s.fsf@gnu.org> From: Carlos Pita Date: Mon, 18 Oct 2021 20:35:48 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: martin rudalics , 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) (Sorry if it ends up being a dup but I'm resending this because I'd previously sent it with an attached screencast and it seems that it's not being accepted by the bug tracker. In any case, it was the wrong cast :P. Please let me know if there's a policy wrt screencasts, even the right ones. I think it could be useful in this case but it's not that important.) Hi, Here is one more example that tries to capture the essence of another popup dialog in org that is giving me headaches. It's fixed by applying Martin's patch, it's not "fixed" with the redisplay-before-fit workaround (although the redisplay does make a difference as shown below) and it's "fixed" with the redisplay-after-creation workaround. 1) I run emacs -q and execute this simple code that opens a window with 30 numbers, each in its own line: (progn (switch-to-buffer-other-window "popup") (erase-buffer) (insert (mapconcat #'number-to-string (number-sequence 1 30) "\n")) (fit-window-to-buffer)) The window properly fits the numbers, which are all visible (please ensure your screen and frame is large enough). Now I close the window and make the modeline bigger as in Jonas' example: (setq-default mode-line-format (cons (propertize " " 'display (create-image "/* XPM */ static char * image[] = { \"3 60 1 1\", \"0 c #00aaff\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\", \"000\",\n\"000\",\n\"000\",\n\"000\",\n\"000\" };" 'xpm t :ascent 'center)) mode-line-format)) 2) If I run the code above one more time, that is: (progn (switch-to-buffer-other-window "popup") (erase-buffer) (insert (mapconcat #'number-to-string (number-sequence 1 30) "\n")) (fit-window-to-buffer)) The numbers are only partially visible, the window looks as if I had scrolled the buffer down to the bottom. Scrolling up it's easy to see that not all of the numbers fit the window. I guess this is expected because of the miscalculations regarding the modeline height. 3) Now I add a redisplay before the fit: (progn (switch-to-buffer-other-window "popup") (erase-buffer) (insert (mapconcat #'number-to-string (number-sequence 1 30) "\n")) (redisplay t) (fit-window-to-buffer)) Again, only about half of the numbers are visible and the window looks as if its buffer has been scrolled down. But now by scrolling up I can check that all the numbers fit the window. So the height of the window is right but there is that unnecessary scrolling down of the contents. 4) Now I repeat with the forced redisplay even earlier: (progn (switch-to-buffer-other-window "popup") (redisplay t) (erase-buffer) (insert (mapconcat #'number-to-string (number-sequence 1 30) "\n")) (fit-window-to-buffer)) This seems to work around the issue. I believe that in 3 there is some miscalculation during the insertion of text into the buffer that forces a scroll, but I'm having a hard time trying to explain that. Anyway, it's another case the redisplay-before-fit advice can't cope with. Best regards, Carlos From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 18 20:12:16 2021 Received: (at 38181) by debbugs.gnu.org; 19 Oct 2021 00:12:16 +0000 Received: from localhost ([127.0.0.1]:48877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mccjl-0006e9-Qp for submit@debbugs.gnu.org; Mon, 18 Oct 2021 20:12:16 -0400 Received: from mail-yb1-f179.google.com ([209.85.219.179]:33320) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mccjh-0006dt-8Z for 38181@debbugs.gnu.org; Mon, 18 Oct 2021 20:12:12 -0400 Received: by mail-yb1-f179.google.com with SMTP id v195so2703097ybb.0 for <38181@debbugs.gnu.org>; Mon, 18 Oct 2021 17:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GdlAHhrtdZ55Q4NEm/3RE7XYp7dm65cO4oOIyrx0NAU=; b=MSxm5HyW43E6Hew7khA9T3MdFwTkGx0AXxKYU3rfGXqd9BTkL3pXtFNrMNwYVR48n8 1sZPFYbctqT6RkKT5z1tvzdqkBpownkIz9ALj9EIaGhuBoMc115YXdFlqbC2LdZQqdn3 zbwKdkbx7KjvZkj2Nu0XG0lBh1Gmb7UpzfvYx1inzz7GDqZinjBRVfwZNJDQRV77gcHK ONJprwZqWhZY4cujWvdP7cDGT0HW3edqj0sJwzQ6nuaK2ohk05SYOLd0KHdCh40/67zG Tq//yMYJEPqDZltpjQflP82SiIPXuq/nXfP8WbV9YCd7vwuV7I2inM11BoSGKoERWQrE O0Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GdlAHhrtdZ55Q4NEm/3RE7XYp7dm65cO4oOIyrx0NAU=; b=IdGbxaC+J0fdqtGSJ/UJzLDDeukPfsAuMdTGOkxVL8OVIA1utyp4tF4Pq5J7wZjyy+ Fpvy5OUvQ/fmYwIWCsgfKxJ1yqPHcEZZcqmL8HxlG3CIGa7PbVSnZxjQtIuyDxHGGVYu ZX8awwQ9POY0P65XGITmkpQNx4wqvTH9HqP+xTjOlJgmTMcKyKvsK9BUfWtmaImV8lO3 2yWEUbJCNG0pVk20zpxDdK6e7vX9KyHorN1sWGHHPjJSMMoxHB8gwfnqnhTMX9g99RVk 0Y3AHOMCRGMvG7DmZHDOHeZTcmk6r780fvGDgtYEv9koU6EI5uPbg2mS5EkIK9ZeaGbc 4Y7A== X-Gm-Message-State: AOAM530BcIdSPCIvVVhlD6h3h1Yr/8P6q1Vs2AmeAY9zzCKnziiJD2lY HAAbkSOmnMIvmVKj3xwriMGoJVOHkQcsUsKyCaw= X-Google-Smtp-Source: ABdhPJzPJUCXpkcXT1rFKASwL671EhLKVmr3HBa0oHRFvuESqtrgeMOFT/l8MnMulfG2iDC9sic3vcNp0qVJniyFsD8= X-Received: by 2002:a25:3104:: with SMTP id x4mr32561510ybx.512.1634602323858; Mon, 18 Oct 2021 17:12:03 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> <312e15c3-83d3-99ee-ef73-8fd6013153cc@gmx.at> <7626992f-ab12-5df2-9061-77cb1e276556@gmx.at> <831r4idw8s.fsf@gnu.org> In-Reply-To: From: Carlos Pita Date: Mon, 18 Oct 2021 21:11:51 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: martin rudalics , 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) > Please let me know if there's a policy wrt screencasts, > even the right ones. I think it could be useful in this case but it's > not that important. FWIW here is a permalink (I hope) to the cast: https://user-images.githubusercontent.com/2845433/137821853-c887649d-848d-4d55-8a1f-299da8020ff4.mov From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 19 06:08:50 2021 Received: (at 38181) by debbugs.gnu.org; 19 Oct 2021 10:08:50 +0000 Received: from localhost ([127.0.0.1]:49440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcm38-00079T-H9 for submit@debbugs.gnu.org; Tue, 19 Oct 2021 06:08:50 -0400 Received: from mout.gmx.net ([212.227.17.22]:53305) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcm32-00079B-Cn for 38181@debbugs.gnu.org; Tue, 19 Oct 2021 06:08:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634638117; bh=79FQM2owrwRQikpufzmT5IZdR+p3HLs3RvmAz12Ws5g=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=G5k5OJmFmJWpyhDgWEcgAZ+hIANwI3pqyX10OnJD1CKfMVjYQXB41DQGEMI+/zZ+S JZlv/roxCY1yXEThp++RXr/kDTlfiq4zGOgLEBKLmnPqNZqoKtRoZONLJrmqH8hN2A BZCyn5v8H7DVhp4EUyJvWAfMORwMJa7YhtzVZIpk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([46.125.249.127]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MuUjC-1mtl0315BC-00rZ54; Tue, 19 Oct 2021 12:08:37 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Eli Zaretskii References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> <312e15c3-83d3-99ee-ef73-8fd6013153cc@gmx.at> <7626992f-ab12-5df2-9061-77cb1e276556@gmx.at> <831r4idw8s.fsf@gnu.org> From: martin rudalics Message-ID: Date: Tue, 19 Oct 2021 11:25:09 +0200 MIME-Version: 1.0 In-Reply-To: <831r4idw8s.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:k4Ui4sLzP6yuDNpbsTjE2lojSYO55V+nvV1XYEE9+peq1wMXKNQ hZ23KGkWMvmASYAMs7GUynrIDH+amBctIDrN6R8LVXXJQmcO9nlW5PAtnqkx8eoQVJ04tAC DLgVOzZzMNAzl6sPqYcqlEtBfL1hxXgxorCGIJ9C7KLPmGljzzMRssAd1Wc3bAVuH6hZ7nG 7hhWkdFmXhcVc3clhVaGw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:0WLQL+BxHyc=:ppmXZ9hLQ2SH7R2/omLoWa Ybq4447Kt6xA/4w4745/dJuCIexNE4Ots5bEGjRoWVTaViLV7w8zkESI0jidGxzyTYk8xL6lH /+/tcx4go1r1UsOLmg9DwBAKmLwFKlxMnFunOfsYtLJQa9XlrGaYFYF0NkNdxWDBvslvvtthw aStwTuLTXTqbIQyuEMu2bAUCrH/fjU1Bj4jrFnDN/QD+uHAbOnJgExi95ZJ4H8IVSXO6fJtuD bS7kY4rOncuOGHSY2a0l0DKC62Bfi8on+Cn2IQGT4kC5rDzbLpSaWgo+nKBe9j8M6nTfjixtN Q77B3bPM88xAgfMhey4BcRplCVmeZJvtxsuQ+K4k3+ydpbLWvumOKpIz1ZfxRGa+N0rEUCEsd yvPJFXj473gDauO4q1US4vQcS2z8pTqm5ZLOlILFvFI9QM20ads0y3q3v02v1OKsYfEkPNSEN QyETnAOc/kbgrnQShW+GAWRGSVsrn26w2s7uL5FudW9Pxj653f9/VixgFPgbcFIzu645Itv/U IjGwvWgeACaOLAU1tg1Iz3xaZCZsaTxr+9Cp2uThg8D51tSim3+Dlff0+BZ8WWRKQnM1R9CVb R7vAhkgw7oBhEodn3gedh1VcoHSEf+b/ZZz2BwoRDyF+zSAc0SIi6SE6H4mk5HjEYW3QMDYQG DuR81Ez2OUrTUxFssiN+UxOqc6eLvccJe0o7rDTZdYtiOT8u1Qq2D5b55tmuiOaleIpzP3U6Q VZ15XOBzip6IV5RkWQyRDc6Y7YE9PFIJlHfDhduKem94VPvkTsScDS+wfr8mVpRmauLBgSdZL 9BtWD7GbMNfSU7fIjfQqR/a9QlX/uXsnnqfXaKzUwLEM7a4qKD8Ycm5oIvtbcmUxfLK/0csEU 11XTwOpqrlNcX69lgBW9G8PF8yMzC58VP5GLPwmkRdl0yr26dBFEkMWWRneftg2vAzL+gurxE 3a+PM6eMewO4IElyY7ENEbVQp0+jMRMoDVihvLWFKcaz5mmbTKrmJkti3F4JAAfYDEW/J2LyQ hbrHicYYt7mPUFyPSTzgU5v99bI3q7Ax5hbwycXm3cm2heUkymkcgvdQnK83xXVItD2owy9JB OmZFr2kfY96jzY= X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 38181 Cc: carlosjosepita2@gmail.com, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > There is, for some value of "display": this function actually > generates a glyph row in the glyph matrix. The same thing happens with 'pos-visible-in-window-p', I suppose. >> Eli, I think this could go into Emacs 28. WDYT? > > No, it's too radical, and the problem it fixes is too obscure. Let's > install it on master, please. I'll wait a couple of days and do that if Carlos doesn't see any problems. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 19 06:10:09 2021 Received: (at 38181) by debbugs.gnu.org; 19 Oct 2021 10:10:09 +0000 Received: from localhost ([127.0.0.1]:49444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcm4O-0007Bo-UT for submit@debbugs.gnu.org; Tue, 19 Oct 2021 06:10:09 -0400 Received: from mout.gmx.net ([212.227.17.21]:48321) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mcm4M-0007BI-U2 for 38181@debbugs.gnu.org; Tue, 19 Oct 2021 06:10:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634638200; bh=r+/WUcWpeJkgGGa+UD/Fs1nckXhDPaFzcVui8qJuhPU=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ThK6ix/Y2S1VMHx0K3qeLE/MMwNYQVhLYZyOK2hNzTVGQNQdVh60eHBIlRXWavT0w sJe3d64XSjvZ94Rjn9fVRjMpcannpEtaG3Zx0YiBPiK04Ysck22Z8UdH6F0Y+CoZVy TmL3SecVTVSRWfI3OerOgUKH3RKRN0EOn71QZjLg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([46.125.249.127]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MCbIx-1mTjdz1qDr-009gGr; Tue, 19 Oct 2021 12:10:00 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account To: Carlos Pita , Eli Zaretskii References: <87eeyd3ul0.fsf@bernoul.li> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> <312e15c3-83d3-99ee-ef73-8fd6013153cc@gmx.at> <7626992f-ab12-5df2-9061-77cb1e276556@gmx.at> <831r4idw8s.fsf@gnu.org> From: martin rudalics Message-ID: Date: Tue, 19 Oct 2021 12:09:59 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:SPBKeKmw9fMPWUip6oiNeK9xWsKlH5iM1td/K4EKeSU/wkXOokb XTyOmpl4uAQPSEeMgDHYcyIWZeUQ7O4s+P6i8FOap8znP9tvVCsWmQeLofo4UIAFvtJU9WJ EmnbQzNKxg3k0ChyOD2r15IzyUFglqKaUiK8PyCGIZyuEpgWYrK153RlITWCeMpQ5PuUtHW mO+c8vPwNB2nbFj/PqmtA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:IVLVrmBA+3I=:oEwyWCQGTKk6KJX3XBber7 QgN8Trt3b9VWszWidAUbVX4CW+sJrkL4nYM8XUkddfGCdvjkHt7+e+iRwcmGg/VswRfqBnqTk 13LpKJuilYscNYz3qBoAs1zqc0X5w2fiD85LU+o/IPvq/7eYruN8gkR5JfU9ISyAs0G6kJm8N VIIguA80BJmq9Hh5SwAtEq1XZQzJa+TjST6Yn436YYxzHA1ckMJJZhBLLUhFiHd0ACRjVctU2 /hvVHDIVRUUy5xyNIt/ADP+b1q8W2PJz7soWvVfCdqI1SC1AzfzsuAGlb5+trCdxYcn2GTzYm 704ae6MGeRDLVsmI+uifqRPzbzRW1ZNjtD7Lw5i9vlggrn7YNCEFJRM9o2E24u38wKM6+PWHs U1vjgvGeL/M7mWpB0CZpCy4wd24pHdVcCwdHFaG9lR10eioOh5lKtSIzpkDLSkBNC6QLNZOiI JpA6NmPhbw9Opvc/TWMPPWoMCrXqGJPiDYqPLkOFhPh+YNuRmdGMAZeGud3DoiFaQbznwlJTE yrh43p0Q3Kh2GcRvsRqkDLy1gdLuEirdEnfvkr86fkZ/+Bs15MlmxxT7LB57ZWn0Vt60cJSIU 6EM4uEnHlKqpG0MnRr4g/KIlDLZulLc+MyLCplNONw646wIANQBKrUJeWJrb1pjJyhlAm2rbe gZIr8ReqKBD8N1cVLUiWwc9J3+CRIm+hJ9mLMUvdZ77LP/PESDpTOYAwnrg3+FPUaQSE84Nut Qj68vaqLC6mSrnND6EqflbBcOdc3cWPY10g6wQj4KINvpShbLNPr6X4InCPnmXVs6ssdaj2v0 5m3VlH34t+sTACWPgLnDfK0vRcy2DNiQ4I1aK1VqFkAH/GMgU+XGuEUJIw9ibWkVfu35qVRPI 7sqlb29nWjfpWB2Vs5WTW4jCeoUpc73QTLz4H3z4gadjj8jBYBkDQ9RQZQeazR4/eI2QKAyKc RhD0OltMIqL5huwjKoUldEvov21HqxMaNyKoMhqeJBWFLuPNOXNwaQ8Y+BC8UzBkPAh0lok2p Rz6s7ByDuQ13g6FF1yF7ZJ3OM7wgCwvrZ02TABiNX5VNHYubs8gyf24jeBNU9QhKPb2Zeui7L ZtwglJu1Cnlhtc= X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 38181 Cc: 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > 3) Now I add a redisplay before the fit: > > (progn > (switch-to-buffer-other-window "popup") > (erase-buffer) > (insert (mapconcat #'number-to-string (number-sequence 1 30) "\n")) > (redisplay t) > (fit-window-to-buffer)) > > Again, only about half of the numbers are visible and the window looks > as if its buffer has been scrolled down. But now by scrolling up I can > check that all the numbers fit the window. So the height of the window > is right but there is that unnecessary scrolling down of the contents. > > 4) Now I repeat with the forced redisplay even earlier: > > (progn > (switch-to-buffer-other-window "popup") > (redisplay t) > (erase-buffer) > (insert (mapconcat #'number-to-string (number-sequence 1 30) "\n")) > (fit-window-to-buffer)) > > This seems to work around the issue. > > I believe that in 3 there is some miscalculation during the insertion > of text into the buffer that forces a scroll, but I'm having a hard > time trying to explain that. Anyway, it's another case the > redisplay-before-fit advice can't cope with. In (3) the redisplay happens _after_ the insertion so redisplay may have to scroll the buffer to make point, which is at its maximum, visible. The subsequent 'fit-window-to-buffer' and the final implicit redisplay won't change the window's start position after that. If the window after the split were large enough to encompass 30 lines, this won't happen. In (4) the redisplay happens _before_ the insertion so erasing the buffer will set 'window-start' to 'point-min' and the implicit redisplay at the end will see point within the visible portion and not change 'window-start'. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 19 08:22:38 2021 Received: (at 38181) by debbugs.gnu.org; 19 Oct 2021 12:22:38 +0000 Received: from localhost ([127.0.0.1]:49769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mco8c-0005Oi-BD for submit@debbugs.gnu.org; Tue, 19 Oct 2021 08:22:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34960) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mco8a-0005OU-8v for 38181@debbugs.gnu.org; Tue, 19 Oct 2021 08:22:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51428) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mco8U-0001wb-Fu; Tue, 19 Oct 2021 08:22:30 -0400 Received: from [87.69.77.57] (port=4979 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mco8U-0003mZ-3u; Tue, 19 Oct 2021 08:22:30 -0400 Date: Tue, 19 Oct 2021 15:22:40 +0300 Message-Id: <83ilxtcigf.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-Reply-To: (message from martin rudalics on Tue, 19 Oct 2021 11:25:09 +0200) Subject: Re: bug#38181: Actual height of mode-line not taken into account References: <87eeyd3ul0.fsf@bernoul.li> <2a0bf8c7-69df-0532-c6d8-5315ee9fee28@gmx.at> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> <312e15c3-83d3-99ee-ef73-8fd6013153cc@gmx.at> <7626992f-ab12-5df2-9061-77cb1e276556@gmx.at> <831r4idw8s.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38181 Cc: carlosjosepita2@gmail.com, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: carlosjosepita2@gmail.com, 38181@debbugs.gnu.org > From: martin rudalics > Date: Tue, 19 Oct 2021 11:25:09 +0200 > > > There is, for some value of "display": this function actually > > generates a glyph row in the glyph matrix. > > The same thing happens with 'pos-visible-in-window-p', I suppose. If it calls display_mode_line, yes. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 22 05:04:20 2021 Received: (at 38181) by debbugs.gnu.org; 22 Oct 2021 09:04:21 +0000 Received: from localhost ([127.0.0.1]:59381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mdqTM-0002QR-Le for submit@debbugs.gnu.org; Fri, 22 Oct 2021 05:04:20 -0400 Received: from mout.gmx.net ([212.227.17.20]:54057) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mdqTL-0002Q5-0J; Fri, 22 Oct 2021 05:04:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634893452; bh=GPMT9/uyCUYpNzzzwGVpt+0m/q/eQfsVPwnFQf8Y+B4=; h=X-UI-Sender-Class:Subject:From:To:Cc:References:Date:In-Reply-To; b=hn5UvVK+5jJrCC6kjrr6hkcCwdlhPfFVYLV8JDij7OuTWHMXOVPVxhCAeD/TaxzbV xqQp1SW4TT38myZ13nF+WrIcUvwDYR55hlWnwx44lxqWKeCz8jFE6GkgfcbetFUBLo K3DGE4reAUJbfwTsUcIKR29MXHgLiio7weVrxG5k= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([212.95.7.231]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N8ofO-1mio0o0iww-015u1F; Fri, 22 Oct 2021 11:04:12 +0200 Subject: Re: bug#38181: Actual height of mode-line not taken into account From: martin rudalics To: Eli Zaretskii References: <87eeyd3ul0.fsf@bernoul.li> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> <312e15c3-83d3-99ee-ef73-8fd6013153cc@gmx.at> <7626992f-ab12-5df2-9061-77cb1e276556@gmx.at> <831r4idw8s.fsf@gnu.org> Message-ID: Date: Fri, 22 Oct 2021 11:04:10 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:G+ZHgfdVDkD2SneOoLhxhi04g9iYCdXFHuXCr2NWM1J/lvJS4c/ GwXtAW1lBCxAjHkXkxSngBy5qFwPiDR17X2gxYyESty5DlknCk7oZzwAeozrfj5PuO1FATP gWwEHFTPiLnfTglMdCW9vzJrIV2eT6gjPK+5gs0Mccy07f4t/hjkeM+pIA0uuav9/v6cGqR 60JJWbXyD5fyZuWYJdY3Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:CWRZKttvT8Q=:R36pmyt8VrOO2UGcb+6+Zl 96VhMG9bB1q4aBIBn06o46Os2Rn4G44jn8+Loz9SxjFj9Rt1IUtanwYhcBoWOA+HG4sl7ev7n oi3slPBYFwCUFhcT1iqpth0mwlBnTx4xS0Z6wMbYxPdSENz+SI8A3JvLTkJiWUXmiz+4B1S3u WOR5XZE1wtJrqBYshjZT2oTXKQyDU/gOmeMfQL59tZ5bujRT6e0d2N7vQc9dI1cogjsomrepq 7Z/gumUecVEtv98VKKTWESDkOtsVS4Hiv9FR6xTnmy9TS3wKn4xcZ0A6K8AkFp0fgwcNke6Ie rgrDcHJ6cZAbZH7YIpzttrkF/oNEtn5r4NmGb1KDkg2YM+UY4I25zzUJedlgas8s0PefWUzK0 Yn+EJkchB21INbT+JhiA07qJE6XiMpw+yBisP2HzfNHmbAhhWsLx3dE0sFg+lG1Gj08mWd4ob nyI3uF+r7dMJx/BArlYczecDghQlV6IjecOD3vascPp2gLXWNH0PKkL3b1dgQZzGch0eNF/vx ULY+vV4PrcrLIii3n+lt+p3gSfqVLCYg8B+LA/+uBAiCSJlR+zPMpEaqv2ZCpKeg6RNmNbQfy HSCGsIC3eSJAXvNBVfW1HHQKKG7RTrCUPsdwNSRiIHFdLCKTMs3H1zO1PKU+lGi+xtOEJpFCR D5yW6SL94i8j9fYsABo5xXfarUEF56qSnG8GFTgvjA5KSmRCnOu2S8Kpfk2n2LiVClWi4JYJ2 DhD2nHjZAR0bJCfQDq61RY0ULaBIz2G9u2deAZ0yitXhJSDDEEBhZDYPDPpo1/NXvVSliy2zf GLUv6smAujrIvs3qiktjTzqAfj+Nfni8tRnS4VAOi4ecr6cGM3BA1kvihKnBTow4h2ojDqbv1 usqN2u65SihxYgqxRorVHibksocsdUiiDHeZAjbwZbDWwv7DxVWzUVNMmijg9gssIi+wtSOTl eWS6UJ5Sj/dH5Bn+4wU3DqnitZb/9n8S5p1FsSxgcNnfx5gnLbRaPcs/nxSm+QXowsNU4Xngy Hum16ZB35kM67e3iUH5UFkZjJPlYMv4LJsOSX6xe68HiuHMMM+m4vyGeNV/STrwQ7TPoJDG/N p3koHxS0gQNAPE= X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 38181 Cc: carlosjosepita2@gmail.com, 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 38181 29.1 quit > > No, it's too radical, and the problem it fixes is too obscure. Let's > > install it on master, please. > > I'll wait a couple of days and do that if Carlos doesn't see any > problems. Done. Bug closed. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 22 10:55:43 2021 Received: (at 38181) by debbugs.gnu.org; 22 Oct 2021 14:55:43 +0000 Received: from localhost ([127.0.0.1]:33585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mdvxP-0001If-Cz for submit@debbugs.gnu.org; Fri, 22 Oct 2021 10:55:43 -0400 Received: from mail-yb1-f176.google.com ([209.85.219.176]:38541) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mdvxM-0001IO-M9 for 38181@debbugs.gnu.org; Fri, 22 Oct 2021 10:55:41 -0400 Received: by mail-yb1-f176.google.com with SMTP id b9so7572277ybc.5 for <38181@debbugs.gnu.org>; Fri, 22 Oct 2021 07:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AlSjj/pfFe87hwTDLOJw6em/KXaZm7bNtOd9hy+VNMo=; b=LXm13Tf3qEJoXtOX/jzmLzKyZoJkpCjY/EH6K5d3iaw97Ph/80gV8Cc4BON6iYXQKR K9Ex9IxH8lmXf45TDTDSXOx98m7yG1526nala6+o+R0w6FQB0xBXADNk+ChX+MmG8y9O T98Dog7VkyMT7EROWSzetoG1m7bj9ivzpUU+wQk6yXtfgRzlAYZL8/IJ0kXb5c6B/0pC JCiH9Oo7QLhR7LolRJr56+bSJizSk/EaIOe3dsI4ho0kFJHlcZzlwx5wQqVxl+NlLYyf ZE/9b7a/Id4ClCIBKqksGlixyn+OBrj3Id2QeaxufomXFX0qYPwSlSootZYqmVKpvEcX iYxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AlSjj/pfFe87hwTDLOJw6em/KXaZm7bNtOd9hy+VNMo=; b=oWmvWHtSoibudLTHfXxk/F2cIiv3TpM2j3f9na626Ab90Qa/ZeYrm1+LyLYj9MOGax 2YnUUg7+uZgj5IXXdwfats9uUDCqBZb0DDK9wz2jI8xt4H2j9vvxuaVyn68vvI6WvHUi bTyGOCyTGHEUAkMNQCgBREYNj0BzMkm7ijcvA0NQTf0sokp7sLX6nzxwz9EYM1+OExC4 6w3i5KQruAePBx3I7gej2JHmT57HFmwOLgdrOfDF3srdlK0bEzVxMrXr9yvQxUt++ble GuKl3bI8aIP1CC3QmJsK/1F86ExNq1Dm2B/99I4kgvq/Ub3W/qVYQjQkchXf3LHhxhjW 8TtA== X-Gm-Message-State: AOAM533pkczM/H/hjHGbd0n7gQpymhTgauoLLuUlLjh/oGAReV5Y/2Pj 018Z3MqQlaus7cPiwP1rtf0MbqeGAwYfwMv5Q/0= X-Google-Smtp-Source: ABdhPJwBbs5fzEXIdcpAGKeoxPL9kVFLMzdkPT4DRBRc1qZV8CHqAaLCz4W9lIlp1N1GpVMSRrN6MCuqpWplT+IOZ+k= X-Received: by 2002:a25:1a46:: with SMTP id a67mr220298yba.21.1634914535117; Fri, 22 Oct 2021 07:55:35 -0700 (PDT) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> <312e15c3-83d3-99ee-ef73-8fd6013153cc@gmx.at> <7626992f-ab12-5df2-9061-77cb1e276556@gmx.at> <831r4idw8s.fsf@gnu.org> In-Reply-To: From: Carlos Pita Date: Fri, 22 Oct 2021 11:55:23 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: martin rudalics Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: Eli Zaretskii , 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Hi Martin, > > I'll wait a couple of days and do that if Carlos doesn't see any > > problems. sorry I didn't take that couple of days in a literal sense, but was waiting for the weekend to give it a more thorough test. In any case, I'll keep you informed of the results. Thank you very much to both of you for your patience in dealing with me and for your effort in finding a solution to this problem! From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 07 13:49:03 2021 Received: (at 38181) by debbugs.gnu.org; 7 Nov 2021 18:49:03 +0000 Received: from localhost ([127.0.0.1]:54723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mjnDz-0008HV-GQ for submit@debbugs.gnu.org; Sun, 07 Nov 2021 13:49:03 -0500 Received: from mail-yb1-f182.google.com ([209.85.219.182]:40768) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mjnDw-0008H1-Np for 38181@debbugs.gnu.org; Sun, 07 Nov 2021 13:49:02 -0500 Received: by mail-yb1-f182.google.com with SMTP id 131so37741595ybc.7 for <38181@debbugs.gnu.org>; Sun, 07 Nov 2021 10:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=42oEUzvnJ2JFNt17qZ/KxVL6uK+sRPqFh+p4h3BXMcQ=; b=VHvncRaI6a8WnHNRW5H1NDG31T7KE2MELCChu1qhD6qqq/GAPZzjBcJaBsZRxKM569 gr5Ubujz7EWcTO6npYCkBDkiwFjUZbeQPP0F8FY4QNq5Y8yQBYWZQYzmaXnGMBIYoyFu 0idyuuzrDYZtlya/aNY87qkQqzn+zBDvM90kmkdEcQyRQowRmseD6micxdRFew4G7zVl /+iXdZgrQJFfFikWQ+irSFKvPwWyM+I72lPRzIPQ86uRtUTGglQm7Z1ipBi0DtFeWL3t bf7O0qpniyMMoTDTMMdi578cJjC8pEHd9IoPjuP51jOrBIp4iFbYSA/x1pERzxEVnxK6 byKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=42oEUzvnJ2JFNt17qZ/KxVL6uK+sRPqFh+p4h3BXMcQ=; b=SzxON1WXnv4eR4c48LUcXeOY1vAcd/DnUOK7izOnVt0ZKFiE5Muw8mKqoFmD81uVxT jnGS5Rq2VsedZcnOjmcPkdxMS3O9pPg4j6uWh492bq5MrmdzM3umsCMpbGigt9pv6Aaa ElsbnEltyhifw+6R9VyDGUyKYFpUOnSYdHVc9wjJshroCxRLeZghN2FfRpkVtitqPDTN mIC+9nnQ6kq2PHWQSOWszqnX87/buJEmpP5Cz6sVK60YDHa1LQ2SKVovrF+xi3mui2UU 3BALy9gd7R+Pfv8ILP+geCS47I6xucB9MemSXjPvyZtFpy7hvpuqcoYqEg2CzAtcEIV9 iLhw== X-Gm-Message-State: AOAM530olviN3blHnzMPL3CFhETgxKAcncGsovvoBv21HwyLFA36MHAR mPx9WBIhjNfqIuddbJwM86J0iG130Ud8WWBNXGg= X-Google-Smtp-Source: ABdhPJxdxoKHe+YfDrsrPwUbrL2ZR2lhEbI9JS0eq0VFUr05Ryh052XxB3IIrmqz4pcuVnoSTlVFWNc5TfSU4tpiLi4= X-Received: by 2002:a05:6902:1023:: with SMTP id x3mr49435517ybt.267.1636310935134; Sun, 07 Nov 2021 10:48:55 -0800 (PST) MIME-Version: 1.0 References: <87eeyd3ul0.fsf@bernoul.li> <67bcd8c4-2028-46bb-7971-244304bb7c0a@gmx.at> <776a35b7-1920-2987-88ae-6dcab958a8e4@gmx.at> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> <312e15c3-83d3-99ee-ef73-8fd6013153cc@gmx.at> <7626992f-ab12-5df2-9061-77cb1e276556@gmx.at> <831r4idw8s.fsf@gnu.org> In-Reply-To: From: Carlos Pita Date: Sun, 7 Nov 2021 15:48:44 -0300 Message-ID: Subject: Re: bug#38181: Actual height of mode-line not taken into account To: martin rudalics Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38181 Cc: Eli Zaretskii , 38181@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Just for the record: I've been running emacs-28 with Martin's patch for a couple of weeks now and I've not seen any issue that may be related to it. I've not done any tests on master yet. From unknown Wed Jun 25 03:52:30 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 06 Dec 2021 12:24:12 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator