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.devel Subject: Re: Pixel scrolling support Date: Fri, 26 Nov 2021 13:26:34 +0200 Message-ID: <83sfvj2m51.fsf@gnu.org> References: <87a6hrzrcv.fsf.ref@yahoo.com> <87a6hrzrcv.fsf@yahoo.com> <87v90fhayx.fsf@yahoo.com> <835ysf4dyr.fsf@gnu.org> <871r33h0th.fsf@yahoo.com> <8335nj4d53.fsf@gnu.org> <87sfvjfli2.fsf@yahoo.com> <83y25b2u2x.fsf@gnu.org> <87k0gvfeoa.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12879"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 26 12:30:16 2021 Return-path: Envelope-to: ged-emacs-devel@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 1mqZQl-00039N-VK for ged-emacs-devel@m.gmane-mx.org; Fri, 26 Nov 2021 12:30:16 +0100 Original-Received: from localhost ([::1]:45928 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mqZQk-000610-NN for ged-emacs-devel@m.gmane-mx.org; Fri, 26 Nov 2021 06:30:14 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52382) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mqZNA-0001hN-Cd for emacs-devel@gnu.org; Fri, 26 Nov 2021 06:26:33 -0500 Original-Received: from [2001:470:142:3::e] (port=34718 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mqZNA-0003Qv-1I; Fri, 26 Nov 2021 06:26:32 -0500 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=QArFBrS9M9ONVsYHxFkiUhh/GzMGFsPPezCTbbji314=; b=SIBrNQlBW14v Kiy40aE9UBstvOxtrUDDSTuYV/hYpRX/bqkVU5UP2CR/g/0dwssngiuETlxVuc6PaJYtYp5bLXj6S kpx8bVAmPgixwfUnMvHS+6lW/CW7jRrjcpXq4Mwj/Z9uuDFUf5YsBY6LFN7A+MlJIW/EA9G2nFeTA vm8NhY3WfK6hvS47Lev9hJj6aUXts0iAuQDyEUS1e/nfRx0yao9oehzLE+M4WwB3YWndf0ImydImV 3Ej4jbNrHXdRgrb3n5BPiopzrVxvxyzFGPdXB3PCT8w6XCosbCjYR0j0u6ozuBfoE98D2JcZY2bIg jl+Y++hm6yeyulZhYkW/yQ==; Original-Received: from [87.69.77.57] (port=1163 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mqZN9-0001zv-17; Fri, 26 Nov 2021 06:26:31 -0500 In-Reply-To: <87k0gvfeoa.fsf@yahoo.com> (message from Po Lu on Fri, 26 Nov 2021 17:29:25 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:280217 Archived-At: > From: Po Lu > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Fri, 26 Nov 2021 17:29:25 +0800 > > Eli Zaretskii writes: > > > pixel-scroll-precision-mode sounds better to me. > > Hmm, I don't think that's quite right, but I can't explain how it's not. > I think it would be best to keep it as `pixel-scroll-precise-mode'. That name tells me that the _mode_ is "precise", but that's not what you want to convey. The scrolling is precise, not the mode. An alternative would be something like pixel-scroll-smoothly-mode. > >> -** New minor mode 'better-pixel-scroll-mode'. > >> +** New minor mode 'pixel-scroll-precise-mode'. > >> When enabled, using this mode with a capable scroll wheel will result > >> in the display being scrolled precisely according to the turning of > >> that wheel. > > > This text doesn't really describe what the mode does. It basically > > says something like "pixel-scroll-precise-mode scrolls precisely". > > the main part that was left unexplained is "according to the turning of > > that wheel", and specifically the "according" part. > > How about this: "When enabled, you can scroll the display up or down by > individual pixels in a way that corresponds with the movement of your > mouse wheel, if supported by the mouse wheel."? "By individual pixels" is not really accurate, is it? Maybe "at pixel resolution". And now the question becomes "how is this different from pixel-scroll-mode"? Which is a good question regardless of NEWS, btw. > > What is the problem with scrolling by more than the window's height? > > Basically, we use `posn-at-x-y' to find the window start and the vscroll > that's wanted, which doesn't work when y is outside the window. Did you try to use vertical-motion to help you? Or maybe I don't understand the problem, since the vertical dimensions of a window are known in pixels, so what exactly is the problem to determine the window start when it is outside of the window? scroll-down-command does that without any problems. > > I think you should detect the EOB condition early on and simply not > > scroll at all in that case. > > I couldn't find a way to know if scrolling will result in EOB before it > actually happens. Did you try using pos-visible-in-window-p with POS argument passed as t? > >> +(defun pixel-scroll-precise (event &optional arg) > >> + "Scroll the display according to EVENT. > > > This sentence should include something to indicate the "precise" > > feature. Otherwise it is too general, indistinguishable from any > > other scroll command. > > Hmm, how about "Scroll the display by pixels according to EVENT"? Better. > >> +Take into account any pixel deltas in EVENT to scroll the display > >> +according to the user's turning the mouse wheel. If EVENT does > >> +not have precise scrolling deltas, call `mwheel-scroll' instead. > > > This describes what the code does, not what the user should expect in > > terms of the effect on the screen. > > "Scroll the display vertically by pixels according to EVENT. > Move the display up or down by the pixel deltas in EVENT to > scroll the display according to the user's turning the mouse > wheel." > > How's this instead? Where did the "call `mwheel-scroll'" part disappear? If it was important to say that, why there's no reflection of that in the new text? > > And what about horizontal scrolling? > > It doesn't handle horizontal scrolling, so I changed the doc strings to > specify that the display is scrolled vertically by these commands. I'm asking why don't we support pixel-resolution horizontal scrolling in this mode, although the underlying infrastructure does report pixel-resolution mouse-wheel rotation in the horizontal direction?