From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Steven Allen via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0 Date: Sun, 28 Jul 2024 13:07:09 -0700 Message-ID: <877cd59t76.fsf@stebalien.com> References: <87zfq2hg4n.fsf@stebalien.com> <86ikwq1z92.fsf@gnu.org> <87v80qha04.fsf@stebalien.com> <86cymy15n2.fsf@gnu.org> Reply-To: Steven Allen Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34914"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 72323@debbugs.gnu.org, storm@cua.dk To: Eli Zaretskii , Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 28 22:08:11 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 1sYABd-0008rA-UB for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 28 Jul 2024 22:08:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sYABM-0003xN-Dk; Sun, 28 Jul 2024 16:07:52 -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 1sYABK-0003wx-Ji for bug-gnu-emacs@gnu.org; Sun, 28 Jul 2024 16:07:50 -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 1sYABK-0004Cc-A4 for bug-gnu-emacs@gnu.org; Sun, 28 Jul 2024 16:07:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=8uyxwmsoQ4dqkdKXaaCl3jjWaH8gWrzrWC+nBG7qoBM=; b=LU1G/pFgGPz7YLzEGleOzlDOxw+ob9qNlo6gg2U4/eaTWgPqOnrvvkXBB4Q8cGlgNz6t4MqzS3UCHCknWde3eU66+PCmFOAc4xzQfZsiTzIfsqc5z2MFYDVb54zaoLiucCnRf2DV4lfYZLXMiSLePKupVO4Zn2nO8d3HYO3A/IXXKm/0cFOMhmZTQkfkIbeJlyH24Loy/YhWDqbPAcEm36TkhR60EOqgwqJkz2btnpsD+PrV/YU3TsmkJ28VhkYhlIgcWW4Smu2Pyya7ATwK38/adQ+KdsM3r0h+hWPd7Hhrycamo2YrYmjN9g/Cdsi/nYLfqhSqBxffdginmb1tEA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sYABV-0002cT-Uh for bug-gnu-emacs@gnu.org; Sun, 28 Jul 2024 16:08:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Steven Allen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 28 Jul 2024 20:08:01 +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.172219725810031 (code B ref 72323); Sun, 28 Jul 2024 20:08:01 +0000 Original-Received: (at 72323) by debbugs.gnu.org; 28 Jul 2024 20:07:38 +0000 Original-Received: from localhost ([127.0.0.1]:44382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sYAB7-0002bj-EZ for submit@debbugs.gnu.org; Sun, 28 Jul 2024 16:07:38 -0400 Original-Received: from fout8-smtp.messagingengine.com ([103.168.172.151]:44983) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sYAB3-0002bP-Bs for 72323@debbugs.gnu.org; Sun, 28 Jul 2024 16:07:36 -0400 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfout.nyi.internal (Postfix) with ESMTP id 6A2A313801A2; Sun, 28 Jul 2024 16:07:11 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 28 Jul 2024 16:07:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stebalien.com; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm2; t=1722197231; x= 1722283631; bh=8uyxwmsoQ4dqkdKXaaCl3jjWaH8gWrzrWC+nBG7qoBM=; b=f YgIGBPQFPayW5a04GqSmJzT6BkOSMvaLuE1xPkPdDdHFQERJwz/Hl5O/c7X/Kh0d QGU2R61AxpcvhMKzcqbp/z/pMWowqiPdaHiCb2uhQIz1BbbSw94CHMJSowmZbarv 0XyzHeXquC0yM5pQ9mgbFyhsuVzkqCM6LieUauhLZ3yZt+KfF/6hdSSc+lAU1E4T LoICfXbyqueQm6IqBVVA6AwCvgt7H34tK6B5VgWk2GfKZhOgmzLau7+jVB5HB+0x +AyVxaRZGb7v2O2IwNTE69wIfD2fR8w6sOw7lJC5k/Ak2TSHabvsRQFfWthgzSYi G8fClMJkQlJOcldr6N+bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1722197231; x=1722283631; bh=8uyxwmsoQ4dqkdKXaaCl3jjWaH8g WrzrWC+nBG7qoBM=; b=BYVXRnM+ljW8xgpx02E+k4VyIzWFCUqSKHqClLLGmmlu JKs6fdMaw56W+Zko24dGjYQbt95XXeE2o2IlaMIryfaIZq22KoTrIGN+id8F+WhY J0OY+w96GB7Z5vUm+q1GswC01nlJ/ucKARJU+BRHhyH0fWjNwICEYl/7ge8U1CsO JEmHaXVkcovLXM4CnIIUSu4RkcxqcKyIUabXxnXpLg7rSSlKBZjjXamFyNpzOms2 H77CD6OkffuCW1u4SK8ecQ/YV1KRKB4klyIi9FAcwgMT+2Gw8EG07F8cSCsSekbw tKKhiN74oxX6Xo9It2KM+7JZtZjVkL9Obw9yYrXOQA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrjedtgddugeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefujghffffkgggtsehttdertddttddtnecuhfhrohhmpefuthgvvhgv nhcutehllhgvnhcuoehsthgvvhgvnhesshhtvggsrghlihgvnhdrtghomheqnecuggftrf grthhtvghrnhepvdekheekgeelheehgefgudelkeethffhgfeuffetkeegtddvfeduuddt tdejjedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epshhtvghvvghnsehsthgvsggrlhhivghnrdgtohhmpdhnsggprhgtphhtthhopedt X-ME-Proxy: Feedback-ID: ie8a146a7:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 28 Jul 2024 16:07:10 -0400 (EDT) In-Reply-To: <86cymy15n2.fsf@gnu.org> 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:289493 Archived-At: Eli Zaretskii writes: >> From: Steven Allen >> Cc: 72323@debbugs.gnu.org, storm@cua.dk >> Date: Sat, 27 Jul 2024 13:10:03 -0700 >> >> >> Fixing home/end (beginning of line, end of line) case seems trivial: >> >> don't call `line-move' in these cases (or have `line-move' short-circuit >> >> when `arg' is 0). However, even after reading all the comments about >> >> scrolling images, I'm still not sure why it's necessary to reset vscroll >> >> to 0. >> > >> > Because otherwise what line-move does cannot be described in sensible >> > terms. If vscroll is not reset, then what would be the reference for >> > such a "line move"? By its very definition, line-move moves N screen >> > lines wrt the line which was its starting point, but with vscroll >> > non-zero that starting point could be anywhere. >> >> I'm a bit confused because vscroll is about scrolling the window and >> `line-move' is about moving point (only incidentally scrolling the >> window if the point leaves it). Clearly `set-window-start' needs to >> reset `vscroll', but I'm not sure I understand why `line-move' does. > > 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. >> Is this about detecting the correct column? > > No, I don't think columns are related. > >> > line-move is not just for scrolling across images, it is also about >> > scrolling across tall text lines and other display elements. In any >> > case, asking for removal of that reset is a non-starter, for the >> > reasons explained above, so it isn't going to happen. The solution >> > for any Lisp program that doesn't want vscroll to be rest is not to >> > call line-move. >> >> Now that I do more testing, I can see how removing that line breaks >> `line-move' although I'm still not sure why. >> >> Would it be acceptable to restore the vertical scroll position as long >> as `line-move' hasn't otherwise scrolled the screen? See attached patch. > > 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, I tried both and they seemed to work. All this patch does is restore the vertical scroll position after moving point (`line-move' is, first and foremost, a function to move point). > 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. The only options I can see for `pixel-scroll-precision-mode' are: 1. Advising `line-move' to restore the vertical scroll position. 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'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.