From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#38181: Actual height of mode-line not taken into account Date: Sat, 16 Nov 2019 18:19:55 +0200 Message-ID: <837e3z7pzo.fsf@gnu.org> References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <878sofon8v.fsf@bernoul.li> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="211093"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38181@debbugs.gnu.org To: Jonas Bernoulli Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 16 17:21:26 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 1iW0pC-000slq-BJ for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2019 17:21:26 +0100 Original-Received: from localhost ([::1]:48844 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iW0pA-0001QG-H3 for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Nov 2019 11:21:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57313) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iW0op-0001Pu-D7 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2019 11:21:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iW0oo-0007TJ-70 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2019 11:21:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59025) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iW0oo-0007T7-3h for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2019 11:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iW0on-0007Gt-V5 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2019 11:21:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2019 16:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38181 X-GNU-PR-Package: emacs Original-Received: via spool by 38181-submit@debbugs.gnu.org id=B38181.157392122027881 (code B ref 38181); Sat, 16 Nov 2019 16:21:01 +0000 Original-Received: (at 38181) by debbugs.gnu.org; 16 Nov 2019 16:20:20 +0000 Original-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 Original-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 Original-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 Original-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 In-reply-to: <878sofon8v.fsf@bernoul.li> (message from Jonas Bernoulli on Sat, 16 Nov 2019 16:27:12 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:171729 Archived-At: > 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.