From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#38181: Actual height of mode-line not taken into account Date: Sun, 17 Nov 2019 19:16:32 +0100 Message-ID: <5db0ddbf-7473-ca8e-8279-7f8435297771@gmx.at> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="259097"; mail-complaints-to="usenet@blaine.gmane.org" Cc: jonas@bernoul.li, 38181@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 17 19:22:34 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iWPBy-0015CO-Fi for geb-bug-gnu-emacs@m.gmane.org; Sun, 17 Nov 2019 19:22:34 +0100 Original-Received: from localhost ([::1]:55428 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWPBx-0005RY-2E for geb-bug-gnu-emacs@m.gmane.org; Sun, 17 Nov 2019 13:22:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45491) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWPBT-0005PF-RJ for bug-gnu-emacs@gnu.org; Sun, 17 Nov 2019 13:22:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iWPBS-0001RQ-Ma for bug-gnu-emacs@gnu.org; Sun, 17 Nov 2019 13:22:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33739) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iWPBS-0001RK-JA for bug-gnu-emacs@gnu.org; Sun, 17 Nov 2019 13:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iWPBS-0004H2-E7 for bug-gnu-emacs@gnu.org; Sun, 17 Nov 2019 13:22:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2019 18:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38181 X-GNU-PR-Package: emacs Original-Received: via spool by 38181-submit@debbugs.gnu.org id=B38181.157401491516412 (code B ref 38181); Sun, 17 Nov 2019 18:22:02 +0000 Original-Received: (at 38181) by debbugs.gnu.org; 17 Nov 2019 18:21:55 +0000 Original-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 Original-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 Original-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 In-Reply-To: <83blta5sep.fsf@gnu.org> Content-Language: de-AT X-Provags-ID: V03:K1:jxdhMrZ9ORwFcOsazYZnqxdn3BnZgux0tNlpoW0Ha333BW2Aqhj fW/XTIyMvT4vQ0qlafGUA3znOTWU9NG/aIfHBIMKY46KjWccJkqkvgskkhCgmUJ2imFglgp hhO70pCiCWyEQYLnP/nLHmDaRKb1s9MxRlFTf3E1qxXHEpcM1qANkVyHTJ68JuogXFqFqlk 0+yy+t3/St2A3MfVGSVew== 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/1iOeZ1wQ6UZprfprW38uXi8hCYlg94dT39AwH4qc1Un2TbS6r0wMwb3SbK X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:171832 Archived-At: > 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