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: Sun, 17 Oct 2021 03:45:06 -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> <0dff07fa-b56f-1227-9f17-94e9b9b4c296@gmx.at> <83a6j8gp7u.fsf@gnu.org> 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="35360"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 38181@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 17 08:46:26 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 1mbzw9-00094K-Ih for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Oct 2021 08:46:25 +0200 Original-Received: from localhost ([::1]:36780 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mbzw8-0000zv-0x for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Oct 2021 02:46:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55480) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mbzvm-0000zT-LP for bug-gnu-emacs@gnu.org; Sun, 17 Oct 2021 02:46:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60194) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mbzvm-0005Sj-D6 for bug-gnu-emacs@gnu.org; Sun, 17 Oct 2021 02:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mbzvm-0001dw-8v for bug-gnu-emacs@gnu.org; Sun, 17 Oct 2021 02:46: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: Sun, 17 Oct 2021 06:46: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.16344531256271 (code B ref 38181); Sun, 17 Oct 2021 06:46:02 +0000 Original-Received: (at 38181) by debbugs.gnu.org; 17 Oct 2021 06:45:25 +0000 Original-Received: from localhost ([127.0.0.1]:43507 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbzvA-0001d5-OK for submit@debbugs.gnu.org; Sun, 17 Oct 2021 02:45:24 -0400 Original-Received: from mail-yb1-f170.google.com ([209.85.219.170]:37481) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbzv8-0001cr-Ui for 38181@debbugs.gnu.org; Sun, 17 Oct 2021 02:45:23 -0400 Original-Received: by mail-yb1-f170.google.com with SMTP id w10so871245ybt.4 for <38181@debbugs.gnu.org>; Sat, 16 Oct 2021 23:45:22 -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=9hDI/KgKfuNJLeW2hJGfAp3TVc/YMEYbdX7fnvmKk0o=; b=gJkhBpyjPAr/kIiUMTH+qcD4dC9pj5j4nDLX9am2DwkveCUpblvw8eyEIacmNd93TX PGjvVbsp5RsiWdzbZkg1uX3VlYfKNvLlhFufV4DIQusl/hQ855zH5vrHF14LvGYLdlJ3 84izlW9+rsv//2ciKUc7iay5po253I4ZOnAI7OoismhxkVa5ZNIYEFIpGgIETsAOnMoE 0T2QFIgRTa3zukGTuMtx7NMAOZvCs8wm0MWMzXHGF2QFwup7F7hf1gjTyJHj4oTdGso6 79oLOSxiPQdqwpt97qxnVtCSZhgFoomTBykrCQ0xiadTZqLXrWKQ2Zgd5Y3KLRaOb8Kp 1EKA== 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=9hDI/KgKfuNJLeW2hJGfAp3TVc/YMEYbdX7fnvmKk0o=; b=IjBjysS3UFIfHgZa+y8hzfqWbJdanoLe5LDqHqa3QquQwCfouwDuOMT8EJREJSis1R ijzBQiHXiS4zL7X1DSgZxzGX6kydG6vT9gu3TIuGygh1wLfBilLcNaCw5/7ilwP9OLIf QUBxVIpwvzk+GrmrC5DG4EXhjslkLorZ5MIxI8VmzQhwiMVIAV+LSAxgxb7C/7t0UUDL x4MISaYNX4e2V2qtdd6cdRZbyYGj2QIIi4baPjrtCvj8fE01+MFapFehmziwyfPlw35K tY3+BYsCnLUQWgUm69mhnWNSOvDZ2qskMMefXDEtdhHKF+UP/Ikr0sVsPG7eMQeSUkfd Gsxw== X-Gm-Message-State: AOAM531Y/5kP8MiGpYb6gg6s/APnu7GquHe4a7G5hehD/VII4sovb9Yz UGUH0X2t7GMB+iAgZdjQdSPl7EtJxkA/LRsrR8o= X-Google-Smtp-Source: ABdhPJz8vcS8o91JEg2LNbUWE4PD5i9SVTI8n1lmGZIS4IAInDComGKeglkA0yw9GGcaijaJsxpQDJbgNcpvIpig488= X-Received: by 2002:a25:ae92:: with SMTP id b18mr22773626ybj.220.1634453117188; Sat, 16 Oct 2021 23:45:17 -0700 (PDT) In-Reply-To: <83a6j8gp7u.fsf@gnu.org> 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:217409 Archived-At: Hi Eli, > > In practice this seems to nicely cover the relevant cases: > > > > (defun my-redisplay-hack (&rest _) > > (when mode-line-format > > (redisplay t))) > > (advice-add #'split-window :after #'my-redisplay-hack) > > I wonder how this fixes anything, since split-window already triggers > redisplay. In the use cases discussed above, IIUC the problem is that the redisplay is triggered at some point, but only after fit-window-to-buffer has already taken place. Consider for example what org-attach does: 1. Create a new window 2. Enter a window excursion and insert stuff into the new window 3. After the excursion fit the new window to the buffer (this is done from another window) 4. Wait for user input Seemingly, at point 3 the redisplay has not happened yet. The redisplay-before-fit advice won't work in this case because the current window is not the popup anymore when the fit (and hence the forced redisplay) happens. Another different example is org-set-tags-command, this is what it does: 1. Create a new window 2. Enter a window excursion and insert stuff into the new window 3. Inside the excursion fit the new window to the buffer (now this is done while the popup is the current window) 4. After the excursion, wait for user input So in this case the redisplay-before-fit advice works fine since it's triggered inside the popup. But then the popup is killed while its buffer remains hidden, outliving the popup. Remember that the advice is really a redisplay-before-fit-once-per-buffer advice, so the next time you call org-set-tags-command it will fail to redisplay. This is why I believe these cases weren't properly addressed by the previous workaround but are now. > Which means there are two redisplay cycles, and the first one (which > produces incorrect display) is the one from your hack. So once again, > I wonder why that call to 'redisplay' is needed. Yes, I know that is the cause. The redisplay is not needed per se and, worse, produces undesirable visual artifacts, but apparently it's the only way we have to update the information about the mode-line height before fit-window-to-buffer runs. Now, if you are saying that step 1 in the examples above already triggered a redisplay, and if a redisplay always updates whatever information about the modeline geometry that needs to be updated, then something is not adding up. Best regards -- Carlos