From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aaron Jensen Newsgroups: gmane.emacs.bugs Subject: bug#66769: 30.0.50; pixel-scroll-precision-mode and scroll-margin regression Date: Sat, 28 Oct 2023 05:33:06 -0700 Message-ID: References: <877cn7xzg0.fsf@yahoo.com> <83wmv7ckmw.fsf@gnu.org> <87ttqbw66m.fsf@yahoo.com> <83sf5vcfqk.fsf@gnu.org> <87pm0zw3g6.fsf@yahoo.com> <83r0lfcf4o.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c994d30608c601d7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30036"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , 66769@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 28 14:33:49 2023 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 1qwiVg-0007dh-L7 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 28 Oct 2023 14:33:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qwiVQ-0004PU-4v; Sat, 28 Oct 2023 08:33:32 -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 1qwiVO-0004PH-9t for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2023 08:33:30 -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 1qwiVO-0008Mb-1v for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2023 08:33:30 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qwiVt-00079y-Ky for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2023 08:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Aaron Jensen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Oct 2023 12:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66769 X-GNU-PR-Package: emacs Original-Received: via spool by 66769-submit@debbugs.gnu.org id=B66769.169849642727497 (code B ref 66769); Sat, 28 Oct 2023 12:34:01 +0000 Original-Received: (at 66769) by debbugs.gnu.org; 28 Oct 2023 12:33:47 +0000 Original-Received: from localhost ([127.0.0.1]:37902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwiVf-00079P-0C for submit@debbugs.gnu.org; Sat, 28 Oct 2023 08:33:47 -0400 Original-Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]:46203) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwiVc-000797-TY for 66769@debbugs.gnu.org; Sat, 28 Oct 2023 08:33:45 -0400 Original-Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-53e855d7dacso4694928a12.0 for <66769@debbugs.gnu.org>; Sat, 28 Oct 2023 05:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698496387; x=1699101187; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Nu4JhpBoHW0aRv5RVzazdHpds2Cc8sKuMrCkvYDimOM=; b=bbGjO78SMyMKPRDJBwCJGZ09yMHu612q1ia8vhOFchS0cewM6tC4avTeWua6SczZJj iNJEsAVDjkJv9SuymC/kaCPlOgFf2gajttKYaIXg5pO0oZy7+wPFXaVsSY0gMdEYfQ2T mWhqbusEIJNiZXDcNUXZIn8PpfWyTAY0ZuPuGn1SnqGLNIi00J1r1fBuoS62qQXfV60w jVyw9NM0dsztd4ANpF+iL9vgvlyviJZaN9//l5IKRvSxo+xIVqdI2r/n4b4j85MfcvlR ARzIt736AT3X+5N+gvOXoDDFZDxhi4+92vg74pxbUAxkWMIsF4c85HlMjwXAPPSCElqM uzYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698496387; x=1699101187; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Nu4JhpBoHW0aRv5RVzazdHpds2Cc8sKuMrCkvYDimOM=; b=tSHWurDw/Mf9e8u0+MObE5pF6XwIcsCXGQor6O2+rkt9igIkR0N8MrnohZWdfGmgNc qV5eVdX+jOL80jwch8naLhdIMw8pnSkPa4YcraDwdyCcT61JLXGLnTFFGBVIXjh9D9Ro HOFHZLspkHFSNm3kJQhDwyMwyWtZRPD4kq+EH3PY0tDoSRro4Snfgi4u6Sy2AUkwT/A2 OiO0gpEem2J8cT5cKilRn7Tvp7JJWW4umKRsnfj5E/vNyhCjQB1OBGtfq8ooscEf09/K nQNuYwhX1sEbm+znnR6GHV6W59bOFF4TT351a+KIK2wPpn943+IKYqtDzfgDOmzCyFPy 4hEw== X-Gm-Message-State: AOJu0YzONrtZhl+neIj3kHxv4SshT9PjK0CXf1K0hzEYBDMx/PPvqAe9 051WcaKBUypGfEC2y9nt8fnZ8R7wZY1xrvVzkefDu4L0 X-Google-Smtp-Source: AGHT+IEWRcqcragkk1QA0PgmCdPRiry0vrHgvcpYhnEijfAYhxjY43U3WZldAp11Dq/+3WQ75TI1A3HSAesVjPfbjfY= X-Received: by 2002:aa7:d941:0:b0:531:a63:cf25 with SMTP id l1-20020aa7d941000000b005310a63cf25mr4258441eds.33.1698496386797; Sat, 28 Oct 2023 05:33:06 -0700 (PDT) Original-Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Sat, 28 Oct 2023 05:33:06 -0700 X-Superhuman-ID: loa0vqur.50c7f9e5-1868-49ed-a623-b075ff722351 X-Superhuman-Draft-ID: draft00e16b6e311422f6 In-Reply-To: <83r0lfcf4o.fsf@gnu.org> X-Mailer: Superhuman Desktop (2023-10-27T20:19:29Z) 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:273434 Archived-At: --000000000000c994d30608c601d7 Content-Type: text/plain; charset="UTF-8" Depending on what "slow down to a crawl" means exactly in practice, I think the reason is that it would cripple a feature. I don't know how many people use scroll-margin, but I've used it for years. I suppose I just would have to choose between precision scrolling and scroll margin, but I would have to choose between them to support something that doesn't matter to me: scrolling with images. It also introduces additional complexity and variation in the scrolling code, which in general, means higher overall maintenance costs (not that it's my role to police this in Emacs). I gather that it is redisplay that attempts to reconcile scroll-margin, is that correct? If so, is there a way to flip scroll-margin on its head such that it is only intentional point movement operations that cause scroll-margin to trigger scrolling? i.e., when doing pixel scrolling, you either temporarily disable the scroll margin (which has the negative impact of once a user does move the point, it will cause a jump), or, after a pixel scroll is done, you move the point to be outside of the bounds of the scroll margin, rather than allowing the redisplay to change the scroll position. Perhaps that is what you are describing and is what would require posn-at-point. Aaron On Sat, Oct 28, 2023 at 4:42 AM, Eli Zaretskii wrote: > From: Po Lu > Cc: aaronjensen@gmail.com, 66769@debbugs.gnu.org > Date: Sat, 28 Oct 2023 16:34:17 +0800 > > Eli Zaretskii writes: > > And what are the problems in computing this target point in the particular > case described here? > > It should be outside the scroll margin, so additional layout computations > must be performed after scrolling, compounding those performed beforehand > to establish the new window start. > > Even if it's done "only in this case"? It should slow down only this case, > no? > > And what exactly is the crucial difference between "this case" and the > other cases, where scrolling works correctly? > > The distinction is that scroll-margin is set. > > That's what I thought, and which is why I asked whether calling the slow > posn-at-point only when scroll-margin is non-zero wouldn't be the proper > solution, as it should only slow down scrolling for those users who set > scroll-margin. Or what am I missing? > --000000000000c994d30608c601d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Depending on what &= quot;slow down to a crawl" means exactly in practice, I think the reas= on is that it would cripple a feature. I don't know how many people use= scroll-margin, but I've used it for years. I suppose I just would have= to choose between precision scrolling and scroll margin, but I would have = to choose between them to support something that doesn't matter to me: = scrolling with images.=C2=A0

It also introduces additional complexity and variation in the scrolli= ng code, which in general, means higher overall maintenance costs (not that= it's my role to police this in Emacs).=C2=A0
=
I gather that it is redisplay that attempts to re= concile scroll-margin, is that correct? If so, is there a way to flip scrol= l-margin on its head such that it is only intentional point movement operat= ions that cause scroll-margin to trigger scrolling? i.e., when doing pixel = scrolling, you either temporarily disable the scroll margin (which has the = negative impact of once a user does move the point, it will cause a jump), = or, after a pixel scroll is done, you move the point to be outside of the b= ounds of the scroll margin, rather than allowing the redisplay to change th= e scroll position. Perhaps that is what you are describing and is what woul= d require=C2=A0posn-at-point.
<= /div>


Aaron

=

On Sat, Oct 28, 2023 at 4:4= 2 AM, Eli Zaretskii <eliz@gnu.org> wrote:

From: Po Lu <luangruo@yah= oo.com>
Cc: aaronjensen@gmail.com, 66769@debbugs= .gnu.org
Date: Sat, 28 Oct 20= 23 16:34:17 +0800

Eli Zaretskii <eliz@gnu.or= g> writes:

And what are the problems in computing this target point in the particular case described here?

It should be outside the scroll margin, so additional layout computations must be performed after scrolling, compounding those performed beforehand to establish the new window start.

Even if it's done "only in this case"? It should slow down o= nly this case, no?

And what exactly is the crucial difference between "this case" an= d the other cases, where scrolling works correctly?

The distinction is that scroll-margin is set.

That's what I thought, and which is why I asked whether calling the slow posn-at-point only when scroll-margin is non-zero wouldn't be the proper solution, as it should only slow down scrolling for those users who set scroll-margin. Or what am I missing?

<= /div>

--000000000000c994d30608c601d7--