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 08:23:15 -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="14914"; 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 13:24:13 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 1mbhnR-0003iR-6X for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Oct 2021 13:24:13 +0200 Original-Received: from localhost ([::1]:53500 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mbhnP-0007mu-OW for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Oct 2021 07:24:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37858) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mbhnG-0007mg-UK for bug-gnu-emacs@gnu.org; Sat, 16 Oct 2021 07:24:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57718) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mbhnG-0005gn-Lk for bug-gnu-emacs@gnu.org; Sat, 16 Oct 2021 07:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mbhnG-000434-C4 for bug-gnu-emacs@gnu.org; Sat, 16 Oct 2021 07:24:02 -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 11:24: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.163438341515525 (code B ref 38181); Sat, 16 Oct 2021 11:24:02 +0000 Original-Received: (at 38181) by debbugs.gnu.org; 16 Oct 2021 11:23:35 +0000 Original-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 Original-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 Original-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) 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:217358 Archived-At: 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