From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Carlos Pita Newsgroups: gmane.emacs.bugs Subject: bug#38181: Actual height of mode-line not taken into account Date: Sat, 16 Oct 2021 15:00:51 -0300 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6568"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 38181@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 16 20:02:24 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 1mbo0l-0001Zp-Vb for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Oct 2021 20:02:24 +0200 Original-Received: from localhost ([::1]:38874 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mbo0k-0008Nq-Gb for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Oct 2021 14:02:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39248) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mbo0Q-0008MR-4B for bug-gnu-emacs@gnu.org; Sat, 16 Oct 2021 14:02:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59709) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mbo0P-0001Wc-QL for bug-gnu-emacs@gnu.org; Sat, 16 Oct 2021 14:02:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mbo0P-0003wf-Lb for bug-gnu-emacs@gnu.org; Sat, 16 Oct 2021 14:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Carlos Pita Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Oct 2021 18:02: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.163440727115107 (code B ref 38181); Sat, 16 Oct 2021 18:02:01 +0000 Original-Received: (at 38181) by debbugs.gnu.org; 16 Oct 2021 18:01:11 +0000 Original-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 Original-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 Original-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) In-Reply-To: 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:217382 Archived-At: 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