From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts Date: Sat, 13 Apr 2024 13:10:32 +0300 Message-ID: <86jzl1po87.fsf@gnu.org> References: <87ttkrl8w1.fsf@gmail.com> <86zfuihp7t.fsf@gnu.org> <87bk6yl4hu.fsf@gmail.com> <8734sal2bc.fsf@gmail.com> <87wmpm2rd7.fsf@zohomail.eu> <86bk6m3c20.fsf@gnu.org> <867cha37of.fsf@gnu.org> <3ee13fbd-2ba0-4fca-b5ed-b61f1d8dc527@gmx.at> <864jcd1qok.fsf@gnu.org> <8634rx1kfb.fsf@gnu.org> <028e677b-6d6b-42b2-95ac-0e0c5d1f3dd1@gmx.at> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8745"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 70038@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 13 12:11:05 2024 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 1rvaLh-00027P-PS for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Apr 2024 12:11:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rvaLV-0000ej-UC; Sat, 13 Apr 2024 06:10:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rvaLU-0000eT-Qe for bug-gnu-emacs@gnu.org; Sat, 13 Apr 2024 06:10:52 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rvaLU-0008Eh-J4 for bug-gnu-emacs@gnu.org; Sat, 13 Apr 2024 06:10:52 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rvaLe-0006y0-Jf for bug-gnu-emacs@gnu.org; Sat, 13 Apr 2024 06:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Apr 2024 10:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70038 X-GNU-PR-Package: emacs Original-Received: via spool by 70038-submit@debbugs.gnu.org id=B70038.171300305926751 (code B ref 70038); Sat, 13 Apr 2024 10:11:02 +0000 Original-Received: (at 70038) by debbugs.gnu.org; 13 Apr 2024 10:10:59 +0000 Original-Received: from localhost ([127.0.0.1]:60200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rvaLY-0006wz-St for submit@debbugs.gnu.org; Sat, 13 Apr 2024 06:10:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36602) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rvaLV-0006vQ-Dn for 70038@debbugs.gnu.org; Sat, 13 Apr 2024 06:10:55 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rvaLF-0008BM-5f; Sat, 13 Apr 2024 06:10:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=H61dxuyVN+1lKTcMALD5aKgH9SZ//OsSZvQkHOQgSpM=; b=Z+l+gMYjbY2n W30c9aD8KYX9kYB3Myz+y7n5JJ7kjwkGIPFCnSydFxvSmCb6JaM43HzewfYajWQxUM+GTmhNAnX5B pHbtmkc1oq2rgslYWlEkkaYSEoYXhjcfUZywjsd7Mis3W2UoP5GpaD4fRUbBIzHgvQN2BFT448+SL mwgazNcyNRbQYfgqDSNAPk6yUeOc1rHhWRp92Qj8T9BdusCvGD2CqrutT4dCt4MZ1Pg2sjjj8JxpW Q8uSBG595yL9yHal4IasCsRw1l23UkwZ3xqvD8GF0BYrWIs1AORtLUYWiixKwEZcblv9AUes8EmYT wMpI0VbWYPSdg+yWIJPHkg==; In-Reply-To: <028e677b-6d6b-42b2-95ac-0e0c5d1f3dd1@gmx.at> (message from martin rudalics on Mon, 8 Apr 2024 11:07:50 +0200) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:283198 Archived-At: > Date: Mon, 8 Apr 2024 11:07:50 +0200 > Cc: r.diaz@uam.es, luangruo@yahoo.com, rahguzar@zohomail.eu, > rdiaz02@gmail.com, 70038@debbugs.gnu.org > From: martin rudalics > > A possibly heretical question is in which way freezing start positions > permanently can harm. IIUC, after a minibuffer interaction, currently > the only way to unfreeze start positions is to resize the minibuffer > window and trigger the corresponding call in shrink_mini_window. But > setting the start position of any window while a minibuffer interaction > is going on seems to work here without problems. The (slight) harm this does is that it might make redisplay of the window slightly more expensive, because it disables some optimizations, like if nothing changed except the position of point. Another kind of harm is what triggered this bug report: it could cause us to reset the window's vscroll for now good reason, because when start positions are frozen, we set the window's force_start flag, and that sometimes forces us to reset vscroll. > That was silly. minibuffer_unwind seems to care only about replacing > one minibuffer with another. read_minibuf_unwind already should handle > this here (don't ask me what a future_mini_window is) > > /* When we get to the outmost level, make sure we resize the > mini-window back to its normal size. */ > if (minibuf_level == 0 > || !EQ (selected_frame, WINDOW_FRAME (XWINDOW (future_mini_window)))) > resize_mini_window (XWINDOW (minibuf_window), 0); > > The only problem is that if the mini window was _not_ enlarged, > shrink_mini_window won't unfreeze starts. Unconditionally unfreezing > start positions there as I mentioned in my first mail should fix that. Thanks. So the patch below is the only change we need to make sure the frame's frozen_window_starts is reset when the mini-window is resized back? Should it matter whether, if the minibuffer is active, we do that only at the outer level of minibuffer? diff --git a/src/window.c b/src/window.c index fe26311..0945b24 100644 --- a/src/window.c +++ b/src/window.c @@ -5407,13 +5407,13 @@ shrink_mini_window (struct window *w) eassert (MINI_WINDOW_P (w)); + FRAME_WINDOWS_FROZEN (f) = false; if (delta > 0) { Lisp_Object root = FRAME_ROOT_WINDOW (f); struct window *r = XWINDOW (root); Lisp_Object grow; - FRAME_WINDOWS_FROZEN (f) = false; grow = call3 (Qwindow__resize_root_window_vertically, root, make_fixnum (delta), Qt);