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: Mon, 29 Apr 2024 15:51:46 +0300 Message-ID: <8634r4s55p.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> <865xwknvhs.fsf@gnu.org> <86bk6aloj7.fsf@gnu.org> <838b8ff4-36f2-476f-acef-6f331867bb1d@gmx.at> <86r0f4gn8f.fsf@gnu.org> <26d27f66-e4df-43a2-8968-18b3cc013137@gmx.at> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28486"; 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 Mon Apr 29 14:53:32 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 1s1QVg-00076n-0N for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Apr 2024 14:53:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1QVD-00022s-Ct; Mon, 29 Apr 2024 08:53:03 -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 1s1QV0-00021O-4k for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 08:52:55 -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 1s1QUs-00073R-Ht for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 08:52:43 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s1QVC-0002Fy-GD for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 08:53: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: Mon, 29 Apr 2024 12:53: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.17143951428650 (code B ref 70038); Mon, 29 Apr 2024 12:53:02 +0000 Original-Received: (at 70038) by debbugs.gnu.org; 29 Apr 2024 12:52:22 +0000 Original-Received: from localhost ([127.0.0.1]:57107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1QUY-0002FS-AE for submit@debbugs.gnu.org; Mon, 29 Apr 2024 08:52:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47836) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1QUV-0002FL-CX for 70038@debbugs.gnu.org; Mon, 29 Apr 2024 08:52:21 -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 1s1QU5-0006ye-KD; Mon, 29 Apr 2024 08:51:53 -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=sbEjfsYiuBrjyBZygPayRFS4Uy2aTPlu55reeDKA/+E=; b=o4L2GuXKqtwV iBHOo8QVJ1XF40ROz4wKQeVvOaEux9U+bO19UlmfU7q8FdLS10U4lRBmVxl0hrRII4UERc1toJcyz mNBRDyX83iItF/D4IE8V20LIAOiVNA96YUF7srTwOVtyeL40c3tz/xZmVPZEZwjuHGlKy+E0MKuq4 dMBeK8oCaXcx/kxmviKk6VSj/9oHPa/kzYbG/s4METokfrZQymNeVtCq0MrCBkHAJntEQZH9arwpQ 4YZQkWwxxhNjXq8ZDNt0JXc+qtKSZh6FewZDA86A0ym5soDl0SMZMo1K+Oq+Qm65DillAx2WPCj3N qjlfxIGY4QRv1dfc6B6fuQ==; In-Reply-To: <26d27f66-e4df-43a2-8968-18b3cc013137@gmx.at> (message from martin rudalics on Sun, 28 Apr 2024 10:51:38 +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:284145 Archived-At: > Date: Sun, 28 Apr 2024 10:51:38 +0200 > Cc: luangruo@yahoo.com, 70038@debbugs.gnu.org > From: martin rudalics > > > Where would you like to put the comment, and what should that comment > > say? > > There are three issues I don't understand well in this context. The > first one concerns the preserve_vscroll_p flag we currently check as: > > if (!w->preserve_vscroll_p && !window_frozen_p (w)) > w->vscroll = 0; > > Here, in all scenarios I tried, I observed that w->preserve_vscroll_p > implies window_frozen_p (w) which IIUC means that the preserve_vscroll_p > flag is not needed and we could simplify the above to > > if (!window_frozen_p (w)) > w->vscroll = 0; > > What am I missing here? I'll let Po Lu answer that, since the preserve_vscroll_p flag was introduced to support precise pixelwise scrolling. > The second issue is why we freeze window starts at all. Conceptually, > when window starts are frozen, redisplay should not change the start > position of _any_ window whenever we enlarge the mini window. But > window_frozen_p returns false for the selected and minibuffer scroll > windows. Hence, freezing does not set force_start for these windows. > > While this discrimination seems unwanted (in particular when resizing > the echo area), it apparently doesn't matter in any of the scenarios I > tried here - the start positions of all windows remain unchanged in > precisely the same way regardless of whether they are selected or not. > So IIUC we could do away with freezing as well. Your conclusions are too drastic, IMO. Freezing window-starts is an advisory, not a mandatory, setting. So the fact that it isn't always obeyed doesn't mean it has no place: when it _is_ obeyed, it enables some optimizations, as I described several messages up-thread. Giving up those optimizations when we can use them is not wise. > I suppose that I'm missing some optimization issue here but fail to see > what it is. I described those optimizations in so many words in one of my previous messages. > The third issue is that of the optional_new_start flag: All 'recenter' > effectively does is to calculate a new start position of a window and > ask redisplay to apply it. Now why does 'recenter' in particular set > that flag and why does none of the other functions that set a window's > start position like 'scroll-up' or 'scroll-down' set it? Scrolling commands set force_start, which is a stronger condition than optional_new_start. I guess recenter doesn't have to make sure the window starts exactly where it thinks it should, or something. > Note that I'm not asking to revise code that works sufficiently well > now. But clarifying the issues I tried to sketch above in the comment > preceding redisplay_window could be useful to better understand bugs > like the one that triggered this thread. I still don't know what to comment, because you seem to ask the same questions again, although I already answered them. So I'm probably missing something here. I can think about comments once you say that you understand and agree with the explanations, but would like to see them spelled out in comments, but not before that.