From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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, 28 Apr 2024 10:51:38 +0200 Message-ID: <26d27f66-e4df-43a2-8968-18b3cc013137@gmx.at> 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> Reply-To: martin rudalics Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34284"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: luangruo@yahoo.com, 70038@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 28 10:53:01 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 1s10HM-0008l5-KQ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 28 Apr 2024 10:53:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s10H7-0003M9-Ae; Sun, 28 Apr 2024 04:52:45 -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 1s10H5-0003Ik-Ox for bug-gnu-emacs@gnu.org; Sun, 28 Apr 2024 04:52:43 -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 1s10H5-00013Z-Ei for bug-gnu-emacs@gnu.org; Sun, 28 Apr 2024 04:52:43 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s10HO-0003PQ-BN for bug-gnu-emacs@gnu.org; Sun, 28 Apr 2024 04:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 28 Apr 2024 08: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.171429433113095 (code B ref 70038); Sun, 28 Apr 2024 08:53:02 +0000 Original-Received: (at 70038) by debbugs.gnu.org; 28 Apr 2024 08:52:11 +0000 Original-Received: from localhost ([127.0.0.1]:50086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s10GZ-0003P9-9j for submit@debbugs.gnu.org; Sun, 28 Apr 2024 04:52:11 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:52979) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s10GX-0003P3-1n for 70038@debbugs.gnu.org; Sun, 28 Apr 2024 04:52:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1714294301; x=1714899101; i=rudalics@gmx.at; bh=xfTpIqq6fMUNc0mbeCb2310eu/W9GvQAH3ANTN4Tm1M=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=eThSbMknOJIlPaHSwuagjv3ooHRPHiEf9lM12nwu5nEX6Up4ndBjhZNE7ovaSjV2 k1rZq6wwWqu7TTkgvlyrw6ZDtVVFYlfZveY2Oh9kYtLpfjewtEruTUGzoZ5540YvW yteRAayML2inXO9axkeDxYhBMaPEKjqM5DcuzshZfO48uOr1afyShtoItR99jD7rs ysFjmP0jpMQnIUXKAAUx+c6J8mLipksCnAKAKcFgbpSb7MVJryjU2UZNM+zsuR0n7 7SoZu1mHlBS3qNixSiRuQc7BL+KysQgypQn4Qj/8QLdkYtvi+QkAU2Mn0BYMKaczL 7DTFrgBUNraJD0fKTA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([212.95.7.225]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MJE6F-1sGBct3cBX-00LEnx; Sun, 28 Apr 2024 10:51:41 +0200 Content-Language: en-US In-Reply-To: <86r0f4gn8f.fsf@gnu.org> X-Provags-ID: V03:K1:D/hfOWnagfc/yc3yDrml6Db9iUHaz+6GUcmaDG9xMliykNNfiMS FhjYXm62EUQzGBy952anTiwkiVa92hY8pAq+nMgWc+clKzUDXloJNAQ3BzNMt7yQmrMvxlG w0ZOpIns3u2FBhLjVyZEBb+/TztVyb8lOGniqn7q9ZUub/+61Ky3KU4GHAx6Ym/j7OmjUiI YB9ZHKwkK/a00L8ICZARw== UI-OutboundReport: notjunk:1;M01:P0:JUoiFlMogt8=;RmY3Qkq4wIw6Ch2qyJVXj+y8bba riUJcEshPfwUmaG+CKZ3bdR+s6lpvT+vQlCHJgb4m3gd3XLA4hRJokWI+7z9IO1nj2K/Lmm9y ZyhbgyQjk6tDheN+PsWO+vHZ2FFW7nK4mkAPD9jASjrniPwcRHWeWGhr/ao+tpt7g8phy2UBz pi3QwtYV8HA1Ge+2w/SbZI6K+YF9tehYYxdeyoQVnk/FSPAkMwFUuT277cs3TTQsKuOjEG/Q7 UEJ+z57OZoojILmU8Xv9EtsWmcl79nKKItTkpnA+jOXbZeE93TDWdjYMUbRoMQYJJnPX8udnA x1m0Ou7qFlHDErY4UEnqfEjaQhKVrDeKRPWc96mSsGTmj/Zj2tQvDMEb+lTStgysw9G6vXr/F oRJk/qPyNQRe3YvdOD9KuGieyLUhDqK0FP/FF6GsN5o5oa8aBgc5QhUoiWK2DSaHuGaAn3D6r qFVoaa58zxXLVgNdJl5OXA8HIE2TYCsoGeN2sPwQxkwURnImJR5OKpP9pHrbyYsksN/ZH7BYD gfv4JJFucGXJ7lOJZbaMsplEGtKER1uaIhk0sZ9QdSY0QCTG+73mu/IEbYuMxD4KLJbmw9Bso XwSvEwyDLjcC3iJ7UUyQjgsJM6IuBnd1eKi1F4A7n+JMrJQQ709eUO+FsWpd1dHsSXFTab8Iv ZI5WCaqh7T4Vw8DGZ4+GSSQ2UrszrjEA63F1Z2eFiM1xKI7mjp9C+3sCTIA7yLPdcj+IY1gOK M0R6q51QgXVJxpoP+/I0gTeJcqUcuvWdTFEGf4MRjmOlegXdbMON+JAxcJeypF/qIOPbzY6r 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:284080 Archived-At: > 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? 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. The only new issue now is that if window starts are no more frozen, we'd always (or never) reset w->vscroll in force_start. But, as mentioned before, resetting w->vscroll only in non-selected, non-minibuffer windows doesn't seem very optimal anyway. And resetting w->vscroll is IMHO problematic in another way: After having set vscroll for a window, why does moving point _within_ that window reset it? Wouldn't it be more logical to reset vscroll iff a new start position for the window has to be found - either explicitly due to a scroll command or implicitly to move point back into view (including the case where vscroll itself caused point to move off-screen)? I suppose that I'm missing some optimization issue here but fail to see what it is. 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? IIUC nothing should prevent us from doing away with that flag too. Unless, again I'm missing something important here too. Maybe also some of the force vs ignore window starts dichotomy stems from earlier versions of redisplay where, as for example, in the if ((w->optional_new_start || window_frozen_p (w)) section, we did not care about scroll margins but somewhere below we now check them anyway. Or pathological cases we didn't handle earlier like that of a cursor not becoming fully visible when the line it is on is too high to fit into its window's body. 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. Thanks, martin