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#72323: 31.0.50; line-move unconditionally resets vscroll to 0 Date: Mon, 29 Jul 2024 14:12:23 +0300 Message-ID: <86jzh4zc2w.fsf@gnu.org> References: <87zfq2hg4n.fsf@stebalien.com> <86ikwq1z92.fsf@gnu.org> <87v80qha04.fsf@stebalien.com> <86cymy15n2.fsf@gnu.org> <877cd59t76.fsf@stebalien.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6464"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 72323@debbugs.gnu.org, storm@cua.dk To: Steven Allen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 29 13:15:22 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 1sYOLY-0001VJ-S2 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Jul 2024 13:15:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sYOLD-0008LT-BI; Mon, 29 Jul 2024 07:14:59 -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 1sYOLB-0008Ka-2I for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2024 07:14:57 -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 1sYOL4-0003JN-0L for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2024 07:14:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=VgM078pmyHI/FbNefgH4k0peoTzG7LEEgT0HmUpynCo=; b=a8qUpH7A2NWgC6zqZ1jMJCC5fr3KjYjiQQ0jJz4CU2WcVLGKOMU1j6U6T43yyakfIwZnnXKBxMl97yNNLNOb+TxLt41lRVlRibiK+es0qoyxepX1p+x35UEILWjmZqNVFKpMGcBPv9RpL7n7fiynjl0u8ceix5nP7OzqbAWZvqHvj0bs9TE2Dqg/Dc+m9TxS0CiE5ewo0pRQ+/ODQdBhmD4p+IfQpwTlw1+J7zc66TXOHJ38fjhvdbangP89hWe9bCeJPYM7QCFAQ8ziRz9iZxcbJ70ADqW/Rm3GWuoFe2IU161Za8Q7a7dOwqVLG6mn0CIntd/RaGmVwDTaYLKDsA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sYOLG-0000Zn-B7 for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2024 07:15: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 Jul 2024 11:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72323 X-GNU-PR-Package: emacs Original-Received: via spool by 72323-submit@debbugs.gnu.org id=B72323.17222517002197 (code B ref 72323); Mon, 29 Jul 2024 11:15:02 +0000 Original-Received: (at 72323) by debbugs.gnu.org; 29 Jul 2024 11:15:00 +0000 Original-Received: from localhost ([127.0.0.1]:45018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sYOLE-0000ZM-8U for submit@debbugs.gnu.org; Mon, 29 Jul 2024 07:15:00 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37174) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sYOLB-0000Z9-1R for 72323@debbugs.gnu.org; Mon, 29 Jul 2024 07:14:58 -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 1sYOIl-0002yF-Dl; Mon, 29 Jul 2024 07:12:27 -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=VgM078pmyHI/FbNefgH4k0peoTzG7LEEgT0HmUpynCo=; b=HiXEa2ieRTsP lwqxZoRgIBokxK9TQP1hEZkEdpEg0fs5fS+dS7ZnfmEoZ5h0KT8VYwUqoxnwJJxqm2kagbcpOHE6C tfr7pFHtXq7qYRgfl3vYti5ckHqqOIFbuz/X4uhNTMsmmV3zuMdGELHd206JeTE8TJDvWICnWPYP2 OaSM82XdsUMG+AVMNpCKimGSvVZvOEHvF/onEB78fPsNB17Tvbr1UfAlk7JyRKeG2uB2wb2p46KSC KD0SLLkoMmbJ4gegDXLw9qWXOQzZ5iVY2j1047OC8E6DlZxpcPanYTKsm4s5/SkuTZ+XnQwjw9Six KAfIu2FuJewjI46yR8rU0w==; In-Reply-To: <877cd59t76.fsf@stebalien.com> (message from Steven Allen on Sun, 28 Jul 2024 13:07:09 -0700) 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:289512 Archived-At: > From: Steven Allen > Cc: 72323@debbugs.gnu.org, storm@cua.dk > Date: Sun, 28 Jul 2024 13:07:09 -0700 > > Eli Zaretskii writes: > > > vscroll is not just about scrolling the window. It is basically a > > vertical offset from the screen line that shows window-start to the > > top-most pixel shown in the window. It is meant to enable to see the > > tall screen line at window-start in its entirety. Once point moves > > off that screen line, vscroll is no longer pertinent, since the > > important line, for which vscroll has been determined, has changed. > > For example, imagine that the line into which point moves cannot be > > displayed in its entirety with this vscroll, because it starts at a > > different vertical coordinate (so its lower part could be below the > > window bottom). > > No? E.g., if I have half a line (or half an image) visible and move my > point off that line, I wouldn't expect that line to suddenly scroll out > of view _unless_ the entire screen needs to scroll because the > text/image is larger than the entire screen. It depends on the details of the line from which you move cursor and the one into which you move. For example, if the former takes up almost the entire window, then moving into the next one could cause that next line to be only partially visible, and that is unacceptable for the Emacs redisplay. Once again: the vscroll value is pertinent only for the screen line for which it was computed, because the way it is computed uses the metrics of that line. Once you move to another line, the value is no longer pertinent. > > Sorry, I don't want to make changes in that function whose purpose is > > to serve use cases which this function is not designed to support. > > The code there is quite fragile and it needs to support a large number > > of use cases, some of which with subtle aspects (e.g., did you try > > line truncation? did you try visual-line-mode? etc.). In addition, > > the code there is too tightly-coupled with code in the related > > functions: line-move-1, line-move-partial, and line-move-finish. They > > all work in unison to support the various use cases, and changing one > > without the others is very risky. It took us a long time to arrive at > > what we have there, solving quite a few bugs as we went. Making > > significant changes that at this point in support of application-level > > issues would be unimaginable from where I stand. > > I'm not sure how visual-line-mode and/or truncation might be affected They are relevant because the workhorse of vertical cursor movement is vertical-motion, which needs special handling for each of these (and other) use cases. The fundamental reason is that each of these features affects the layout of physical lines differently. > I tried both and they seemed to work. I believe you. But I have too much gray hair from changes there that then cause subtle problems in rare enough cases. > > Problems with pixel-scroll-precision-mode should be solved in that > > mode. I'm against modifying line-move and related subroutines in > > order to solve problems in Lisp programs that are not bugs in the > > algorithm of line-move. > > It sounds like vscroll may not have been intended to be used this way, > but (a) it's now used this way by a package shipped with Emacs and (b) > smooth pixel-scrolling is a feature expected of all modern GUIs. It > would be a pity to have a half-broken implementation. Emacs supports smooth scrolling only within a single screen line, and that uses vscroll. That's the original design intent of vscroll. Smooth scrolling between lines is not really supported. pixel-scrolling attempts to solve that, and does it well, but it does have some problematic corners. Those corners need to be solved inside pixel-scroll code. > 1. Advising `line-move' to restore the vertical scroll position. That's not necessary. If someone can come up with a version of line-move that is specific to pixel-scroll, we can always call it instead of line-move when pixel-scroll is in effect. > 2. Forcibly aligning the vertical scroll on touch end (which kind of > defeats the point of the mode). > 3. Leaving things as-is and accepting that the window will scroll a bit > when the user calls a command that eventually calls `line-move'. > > None of these options are acceptable, in my opinion. I don't understand the latter two alternatives, but the first one should show a way of fixing these issues without affecting all the users of line-move. > > I've added Po Lu to this discussion in the hope that he could have > > comments and suggestions for solving the problems in > > pixel-scroll-precision-mode you mentioned in the original message. > > See the comment above that function: > > ;; This is like line-move-1 except that it also performs > ;; vertical scrolling of tall images if appropriate. > ;; That is not really a clean thing to do, since it mixes > ;; scrolling with cursor motion. But so far we don't have > ;; a cleaner solution to the problem of making C-n do something > ;; useful given a tall image. > > This function is very clearly about cursor motion, not scrolling, and > shouldn't mess with the current scroll position. Po Lu will tell, but my understanding of the comment is that it does what it does out of necessity.