From unknown Wed Jun 18 23:14:41 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#67333 <67333@debbugs.gnu.org> To: bug#67333 <67333@debbugs.gnu.org> Subject: Status: pixel-scroll-precision: scroll-up-page gets trapped by invisible characters Reply-To: bug#67333 <67333@debbugs.gnu.org> Date: Thu, 19 Jun 2025 06:14:41 +0000 retitle 67333 pixel-scroll-precision: scroll-up-page gets trapped by invisi= ble characters reassign 67333 emacs submitter 67333 JD Smith severity 67333 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 21 11:25:22 2023 Received: (at submit) by debbugs.gnu.org; 21 Nov 2023 16:25:22 +0000 Received: from localhost ([127.0.0.1]:57318 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r5TYv-0007h2-Nn for submit@debbugs.gnu.org; Tue, 21 Nov 2023 11:25:22 -0500 Received: from lists.gnu.org ([2001:470:142::17]:48618) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r5TYt-0007gm-8y for submit@debbugs.gnu.org; Tue, 21 Nov 2023 11:25:19 -0500 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 1r5TYk-0004KL-LH for bug-gnu-emacs@gnu.org; Tue, 21 Nov 2023 11:25:10 -0500 Received: from mail-qk1-x72e.google.com ([2607:f8b0:4864:20::72e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r5TYi-00015H-RD for bug-gnu-emacs@gnu.org; Tue, 21 Nov 2023 11:25:10 -0500 Received: by mail-qk1-x72e.google.com with SMTP id af79cd13be357-77897c4ac1fso377080585a.3 for ; Tue, 21 Nov 2023 08:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700583906; x=1701188706; darn=gnu.org; h=to:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=UBYuiIIhdzsG02Xv8QKPJLeuQU7MqpSWoKoMzvP/s50=; b=drN/yJTsjHB5D1otpBG4LYauucJPBQ4jmFAgAd8QRFQTb2zbzZKU8tg18h0LFgcsg6 g8fwRWqszQ414LRCQcS2xm3zK4TC/v10iUxiYYukFgyZ4C5UxDjO5H+rPma4Cy0EvwH3 cvE9H0JItzfKhPtT0B+nDzEJxLtEN/8UAJ2HRbninph0hVj7Ly2YbT470hOwDHMCfNbz k7SPzoEqI4JekoW6AakUqA301gJ9nKcopyQsYyUa99FrO42EQt5oLkbayLdVMBFwsDe4 +P1RbF3qWHUHSj6fpTfXSLj0t9UMCR6IKpcOk5ZDgiaS3XCPN6vavx/2wGzKPVl6s7Sw x26A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700583906; x=1701188706; h=to:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UBYuiIIhdzsG02Xv8QKPJLeuQU7MqpSWoKoMzvP/s50=; b=QDDd++f8HWubf8CTBr8AXWYHYoPosksAE65eTM8VhhbP34R7fbhPYnhr2U5e+hps0Z UQCt+QOVqbJ0hIOdYmybx4DZh/NNx1tMqlV+yxNOShcyVADQYEEdx5zEGjfqpHsE3ipr b0AjaE6pcu48+pWgIeh5wy/Gby4vu9zxZvs5xLbKru/rrmzVGNIZoXBMe7uxkoJn4TCp 5nKc7uiqmuxxnstpjq3ZxcIy9cWrfPgyb2ZqoMv+pYIge66+9yDiJBBsLCX+7dHvK+Jf CUVGWxC/Vrgt3/IbqqrZJY0LBi/UdpBnbDil9ZtP1U3zsMLvBxRb5smEOme7Adnrgw3i vLug== X-Gm-Message-State: AOJu0Yxwq2PsMZX5oejiGihXOnEoY7SejmNRgPgVNzlnXGeXYf47hEGA H8GpyIcBPzgzZT+FDmU9se+71JnslJY= X-Google-Smtp-Source: AGHT+IFzJO6gIvURDD99nRj8nui4wStrjDSNmlmlIQeHZzz0+LlQp67wo9VQiD94x2iNneOf2Rtdog== X-Received: by 2002:a05:622a:d1:b0:41e:1d15:69a6 with SMTP id p17-20020a05622a00d100b0041e1d1569a6mr14016217qtw.31.1700583906214; Tue, 21 Nov 2023 08:25:06 -0800 (PST) Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id z8-20020ac86b88000000b00421a0b66bd2sm3723624qts.4.2023.11.21.08.25.05 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2023 08:25:05 -0800 (PST) From: JD Smith Content-Type: multipart/alternative; boundary="Apple-Mail=_449ACCC9-BB79-4EA5-B532-AD335CE6AA4F" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: pixel-scroll-precision: scroll-up-page gets trapped by invisible characters Message-Id: Date: Tue, 21 Nov 2023 11:24:54 -0500 To: bug-gnu-emacs@gnu.org X-Mailer: Apple Mail (2.3774.200.91.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::72e; envelope-from=jdtsmith@gmail.com; helo=mail-qk1-x72e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --Apple-Mail=_449ACCC9-BB79-4EA5-B532-AD335CE6AA4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 `pixel-scroll-precision-mode' is quite amazing, running 20-50x faster = than other comparable pixel scrolling event callbacks. I=E2=80=99ve = found just a few issues with it. One issue is well-known and mentioned in the pixel-scroll.el commentary: ;; This works well almost all of the time, but is impossible to get = right with images larger than ;; the window they're displayed in. A feature that will allow ;; redisplay to skip recentering is in the works, and will completely ;; resolve this problem. When attempting to pixel-precise-scroll past an image that overfills the = window height, automatic recentering causes =E2=80=9Cjump back=E2=80=9D, = and you cannot get past it. Is the mentioned =E2=80=9Cskip recentering = feature=E2=80=9D slated for Emacs 30? Would be glad to test it.=20 Here=E2=80=99s the small bug: when scrolling from the bottom up to the = top of the buffer, pixel-scroll-precision-scroll-up-page gets trapped if = it encounters a wrapped invisible character in the first column. By = this I mean the line and cursor are pinned to the center of the window, = only jiggling up and down with further scrolling in either direction. = Note that this only happens when scrolling from the bottom of the buffer = up to the top. Scrolling from top to bottom works fine. So there=E2=80=99= s an asymmetry there.=20 A simple reproducer: Create a new fundamental mode buffer. =20 Enable `pixel-scroll-precision-mode=E2=80=99. =20 Be sure you have lorem-ipsum installed, and M-100 M-x = lorem-ipsum-insert-paragraphs, to insert lots of text.=20 M-x visual-line-mode (not required to trigger the bug, but makes it more = likely). =46rom the beginning of buffer, run the following (via M-:) to make the = 1st character of every 11th word invisible: (cl-loop for cnt from 1 while (forward-word) for p =3D (point)=20 if (=3D (% cnt 11) 0) do (set-text-properties (1+ p) (+ 2 p) = '(invisible t))) Now from the bottom of the buffer, start scrolling up to the top. As = point moves, it will eventually encounter an invisible character at = column 0, jump immediately to the window=E2=80=99s center, and get stuck = there, jiggling around. Scrolling neither up nor down escapes the trap. --Apple-Mail=_449ACCC9-BB79-4EA5-B532-AD335CE6AA4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
`pixel-scroll-precision-mode' is = quite amazing, running 20-50x faster than other comparable pixel = scrolling event callbacks.  I=E2=80=99ve found just a few issues = with it.

One issue is well-known and mentioned = in the pixel-scroll.el commentary:

;; = This works well almost all of the time, but is impossible to get right = with images larger than
;; the window they're displayed in. =  A feature that will allow
;; redisplay to skip = recentering is in the works, and will completely
;; resolve = this problem.

When attempting to = pixel-precise-scroll past an image that overfills the window height, = automatic recentering causes =E2=80=9Cjump back=E2=80=9D, and you cannot = get past it. Is the mentioned =E2=80=9Cskip recentering feature=E2=80=9D = slated for Emacs 30?  Would be glad to test = it. 

Here=E2=80=99s the small bug: = when scrolling from the bottom up to the top of the buffer, = pixel-scroll-precision-scroll-up-page gets trapped if it encounters a = wrapped invisible character in the first column.  By this I mean = the line and cursor are pinned to the center of the window, only = jiggling up and down with further scrolling in either direction. =  Note that this only happens when scrolling from the bottom of the = buffer up to the top.  Scrolling from top to bottom works fine. =  So there=E2=80=99s an asymmetry = there. 

A simple = reproducer:

  1. Create = a new fundamental mode buffer.  
  2. Enable = `pixel-scroll-precision-mode=E2=80=99.  
  3. Be sure you have = lorem-ipsum installed, and M-100 M-x lorem-ipsum-insert-paragraphs, = to insert lots of text. 
  4. M-x visual-line-mode (not required to = trigger the bug, but makes it more likely).
  5. =46rom the = beginning of buffer, run the following (via M-:) to make the 1st = character of every 11th word invisible:

      (cl-loop for cnt = from 1 while (forward-word) for p =3D (point)
        if (=3D = (% cnt 11) 0) do (set-text-properties (1+ p) (+ 2 p) '(invisible = t)))
  6. Now from the bottom of the buffer, start scrolling up to = the top.  As point moves, it will eventually encounter an invisible = character at column 0, jump immediately to the window=E2=80=99s center, = and get stuck there, jiggling around.  Scrolling neither up nor = down escapes the = trap.

= --Apple-Mail=_449ACCC9-BB79-4EA5-B532-AD335CE6AA4F-- From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 24 16:25:48 2023 Received: (at 67333) by debbugs.gnu.org; 24 Nov 2023 21:25:48 +0000 Received: from localhost ([127.0.0.1]:37356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r6dgK-000610-BV for submit@debbugs.gnu.org; Fri, 24 Nov 2023 16:25:48 -0500 Received: from mail-oo1-xc33.google.com ([2607:f8b0:4864:20::c33]:56806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r6dgI-00060m-Qn for 67333@debbugs.gnu.org; Fri, 24 Nov 2023 16:25:47 -0500 Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-58a7d13b00bso1278504eaf.1 for <67333@debbugs.gnu.org>; Fri, 24 Nov 2023 13:25:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700861135; x=1701465935; darn=debbugs.gnu.org; h=to:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=9wdJ3nC487CDbv/JzJOaUgT9FtMWedW8hyrpNYrhdks=; b=TP1Y6OHbjxxZ+WZoRi27E4bTO+P52SjUnmpVXuNh1xGtz5XVqfvftzaqjKvgzvwoyb Ph1jzUNPPq37+z2QoyfEiHon9N4+QUjeyUJhgb485Tk3XpIALEQe5kqBgIaH4Mf6RoMP kRdYbudKHBWumG/0adMyFf8hzi7EJOK4rNaqTmvNyU7IO2wl2u29s5htOPnNXbUudrU8 Qtuoj1cE2w057B/ijKjjgG8jVenw63Yfp2EfCKXA0xfUhwxOhazdWW5avCvGxYZWTt7K IXEQBKLJnVg4QxZlmqVSd1mqoCIEOKSA+TaUnYFqRVxRpt1mFwI7azlTaJPYgOt+Q+7d vAKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700861135; x=1701465935; h=to:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9wdJ3nC487CDbv/JzJOaUgT9FtMWedW8hyrpNYrhdks=; b=Ak/gCRsuW+mwr4ywc3HVL8YzLUWaSZ71ZHM9B9M3G61A/lFLq2UNR+KkVoO3pNwl2k lMymSqbT36jEzbgwsIzLonD89fK8xGLPljPG+hCuwfVtHk/cZpGdHbdjee09gVN9p0po 2apWYZT9OJRyw2GBReHluId0LgRwEi7k7R0NXwC0jCvUq3JczWdTdOdgFPHtkKZMH8xy hvzuId00yssoa+SsZULTH4js9pFHAavG2X4Ht9couHV+Ym4GGVBlh0VjsPOEuGLGRKe3 G+V9rEFKCUmG7W9/HIn0vMjvHpkOnl75FGPfeD2F6cLURr3NtzKUJSFhLZc3X1dkBny1 N4JA== X-Gm-Message-State: AOJu0YyACuWCn7LASNliiENMo+brtXQAqwjah2nyK0mtMxLcF2TQatBk kuy0JHWQ0mw8U4IS0n39s5R2Z3ZDHA8= X-Google-Smtp-Source: AGHT+IHz+FQ0ea8HUJ32/2WOAlcetBFS63dG5nAuq6kBAH0poH/p7+S9b6iCm/WJd+oEMUt3i1smJg== X-Received: by 2002:a05:6820:2204:b0:581:ea96:f800 with SMTP id cj4-20020a056820220400b00581ea96f800mr3978836oob.6.1700861135273; Fri, 24 Nov 2023 13:25:35 -0800 (PST) Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id kc9-20020a056214410900b0067a15610d3csm855902qvb.72.2023.11.24.13.25.34 for <67333@debbugs.gnu.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Nov 2023 13:25:34 -0800 (PST) From: JD Smith Content-Type: multipart/alternative; boundary="Apple-Mail=_E9D809C7-BBF2-487E-8235-174DF9AD0CBF" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Additional info Message-Id: <8F5959F6-5CB6-493E-BF2B-6F69FA1FBF83@gmail.com> Date: Fri, 24 Nov 2023 16:25:23 -0500 To: 67333@debbugs.gnu.org X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67333 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --Apple-Mail=_E9D809C7-BBF2-487E-8235-174DF9AD0CBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I can confirm the problem is exclusively related to automatic point = moves which happen during scrolling, landing on an invisible character = at the start of a line. This seems to happen due to automatic redisplay = point repositioning, and not line-move, for example. I tested Po Lu=E2=80=99s new updates in master to pixel-scroll-precision = (of Aug, 2023). With the new version, the behavior w.r.t. invisible = chars has changed: when point moves to an invisible character as you = scroll point towards the window's bottom, that line jumps back up to the = middle of the window, but is not =E2=80=9Ctrapped=E2=80=9D: scroll can = continue, and you can get past the line. As before, scrolling the other = direction, from top of buffer to bottom does not place point on = invisible characters and so is unaffected. So some improvement, but still not correct. --Apple-Mail=_E9D809C7-BBF2-487E-8235-174DF9AD0CBF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I can confirm the problem is = exclusively related to automatic point moves which happen during = scrolling, landing on an invisible character at the start of a line. =  This seems to happen due to automatic redisplay point = repositioning, and not line-move, for example.

I = tested Po Lu=E2=80=99s new updates in master to pixel-scroll-precision = (of Aug, 2023).  With the new version, the behavior w.r.t. = invisible chars has changed: when point moves to an invisible character = as you scroll point towards the window's bottom, that line jumps back up = to the middle of the window, but is not =E2=80=9Ctrapped=E2=80=9D: = scroll can continue, and you can get past the line.  As before, = scrolling the other direction, from top of buffer to bottom = does not place point on invisible characters and so is = unaffected.

So some improvement, but still not = correct.

= --Apple-Mail=_E9D809C7-BBF2-487E-8235-174DF9AD0CBF--