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: Sun, 14 Apr 2024 12:28:47 +0300 Message-ID: <865xwknvhs.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> <86jzl1po87.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16635"; 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 Sun Apr 14 11:30:09 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 1rvwBc-0004Bh-W5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 Apr 2024 11:30:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rvwBP-0004MR-7i; Sun, 14 Apr 2024 05:29:55 -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 1rvwBN-0004MJ-UK for bug-gnu-emacs@gnu.org; Sun, 14 Apr 2024 05:29:53 -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 1rvwBN-0005oC-Mg for bug-gnu-emacs@gnu.org; Sun, 14 Apr 2024 05:29:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rvwBY-0006sJ-KZ for bug-gnu-emacs@gnu.org; Sun, 14 Apr 2024 05:30:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 14 Apr 2024 09:30:04 +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.171308696726096 (code B ref 70038); Sun, 14 Apr 2024 09:30:04 +0000 Original-Received: (at 70038) by debbugs.gnu.org; 14 Apr 2024 09:29:27 +0000 Original-Received: from localhost ([127.0.0.1]:34313 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rvwAv-0006mO-2b for submit@debbugs.gnu.org; Sun, 14 Apr 2024 05:29:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50228) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rvwAs-0006lA-DA for 70038@debbugs.gnu.org; Sun, 14 Apr 2024 05:29:23 -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 1rvwAW-0005d7-3K; Sun, 14 Apr 2024 05:29:05 -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=p3M0FwN5NlMDIFSkiKL/4SMfeUv4NpayPDTWxs9UQRI=; b=afz+bXGJIdch PU4yC7QWDL7rksq+o/uUxcZvyizkcROaoq5pePb46hvB/9ELZ1KGduUUXKPbDhWyGF34EXUfc4ruN 5hIIF6wb2VoUY06rgP+Liq0lUHK4G52vgxBE7t7y6+uWk/f8hPbmhK3FtRc1ioMh/DW00R0EBm4oP DfNG7mjuoUFic2Bkr7dXU+2GcAMuTsMPk/U5DoCyq1+f7ZSJCUtxJlQ8psxX2gbJJyV08GZuhGGKy asHVXDYW6kdDIjJ/+SrMFklQjrxynKW0wPeDzJFNW9Fr3dh9CRVSb/8ebC5fNss4sXi4QTXkKRVd7 8bJuoe1zQJ44G/LSGy60kg==; In-Reply-To: (message from martin rudalics on Sun, 14 Apr 2024 10:31:15 +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:283264 Archived-At: > Date: Sun, 14 Apr 2024 10:31:15 +0200 > Cc: luangruo@yahoo.com, 70038@debbugs.gnu.org > From: martin rudalics > > > 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. > > From looking at the code it's hard to understand what you say here. It > might be a good idea to add this as a comment. If the window is frozen, we do this: /* If someone specified a new starting point but did not insist, check whether it can be used. */ if ((w->optional_new_start || window_frozen_p (w)) && CHARPOS (startp) >= BEGV && CHARPOS (startp) <= ZV) { ptrdiff_t it_charpos; w->optional_new_start = false; if (!w->force_start) { [...] /* Make sure we set the force_start flag only if the cursor row will be fully visible. Otherwise, the code under force_start label below will try to move point back into view, which is not what the code which sets optional_new_start wants. */ if (it.current_y == 0 || line_bottom_y (&it) < it.last_visible_y) { if (it_charpos == PT) w->force_start = true; /* IT may overshoot PT if text at PT is invisible. */ else if (it_charpos > PT && CHARPOS (startp) <= PT) w->force_start = true; So this sets w->force_start. Then the code under this condition will be executed: /* Handle case where place to start displaying has been specified, unless the specified location is outside the accessible range. */ if (w->force_start) That code calls try_window, so it's more expensive than the optimization under this condition: ignore_start: /* Handle case where text has not changed, only point, and it has not moved off the frame, and we are not retrying after hscroll. (current_matrix_up_to_date_p is true when retrying.) */ if (current_matrix_up_to_date_p && (rc = try_cursor_movement (window, startp, &temp_scroll_step), rc != CURSOR_MOVEMENT_CANNOT_BE_USED)) which is what we want to do when text has not changed and point didn't move far away. Did I succeed explaining the issue? > > 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? > > Probably not. If 'resize-mini-windows' is t, we never unfreeze window > starts because we don't call shrink_mini_window in that case. > > > Should it matter whether, if the minibuffer is active, we do that only > > at the outer level of minibuffer? > > It shouldn't. Window starts would be frozen immediately as soon as the > mini window grows again. I think that to cover most cases we should > unfreeze window starts every time the mini window gets smaller as in the > patch below. Is that in addition to what I suggested to do in shrink_mini_window? Also, shouldn't we do this instead: > - FRAME_WINDOWS_FROZEN (f) = true; > + FRAME_WINDOWS_FROZEN (f) = (old_height + delta > min_height) ? true : false; IOW, shouldn't we unfreeze only when resizing to the default one-line height?