From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.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 Oct 2021 10:33:52 +0200 Message-ID: <65006f88-1151-34fe-2741-a80d328f96c5@gmx.at> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7273"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 38181@debbugs.gnu.org To: Carlos Pita Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 17 10:35:56 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mc1e7-0001kV-Li for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Oct 2021 10:35:55 +0200 Original-Received: from localhost ([::1]:35018 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mc1e5-0007I2-4N for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Oct 2021 04:35:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35752) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mc1dG-0007HN-ML for bug-gnu-emacs@gnu.org; Sun, 17 Oct 2021 04:35:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60242) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mc1dG-0005Le-Df for bug-gnu-emacs@gnu.org; Sun, 17 Oct 2021 04:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mc1dG-0004HT-7H for bug-gnu-emacs@gnu.org; Sun, 17 Oct 2021 04:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Oct 2021 08:35: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.163445964416349 (code B ref 38181); Sun, 17 Oct 2021 08:35:02 +0000 Original-Received: (at 38181) by debbugs.gnu.org; 17 Oct 2021 08:34:04 +0000 Original-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 Original-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 Original-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 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:JodvF73p2WBtW3fVOIsTM0Mc3HNuXSdtKsMPb5WKFADkul+PYgS swC92j9ElPbxEiQWr47LfORGp9zzP0wnqtInCCj7RJUIsBu763xFE74zbSHhsN5UKbOprcl Bq9oJoXxRhqkfyBUu4TxxNj16kv1zlCIwUPS8VZUfW5G5yOBIri32zhVtDrNWz8wK93NEZr EGZ4vRRf8BKB+3Q6gQ8bQ== 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/t3Pb8usqR3eQcS5L X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:217412 Archived-At: > 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