unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Po Lu <luangruo@yahoo.com>
Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Pixel scrolling support
Date: Fri, 26 Nov 2021 10:35:02 +0200	[thread overview]
Message-ID: <83y25b2u2x.fsf@gnu.org> (raw)
In-Reply-To: <87sfvjfli2.fsf@yahoo.com> (message from Po Lu on Fri, 26 Nov 2021 15:01:57 +0800)

> From: Po Lu <luangruo@yahoo.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 15:01:57 +0800
> 
> > Separate mode should be fine, but we need a good name for it ("better
> > pixel scroll" is not a good name).
> 
> Thanks, how about `pixel-scroll-precise-mode'?

pixel-scroll-precision-mode sounds better to me.

> -** 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.

> +(defun pixel-scroll-precise-scroll-down (delta)
> +  "Scroll the current window down by DELTA pixels.
> +Note that this function doesn't work if DELTA is larger than
> +the height of the current window."

What is the problem with scrolling by more than the window's height?

> +	  (when (eobp)
> +	    (error "End of buffer")))

I think you should detect the EOB condition early on and simply not
scroll at all in that case.

> +(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.

> +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.

> +ARG is passed to `mwheel-scroll', should that be called."

Likewise: the description of ARG should be similar to how we describe
the effect of prefix arg in other similar commands.

> +;;;###autoload
> +(define-minor-mode pixel-scroll-precise-mode
> +  "Toggle pixel scrolling.
> +When enabled, this minor mode allows to scroll the display
> +precisely, according to the turning of the mouse wheel."

Shouldn't this say something about "setting the variable doesn't have
any effect"?

And what about horizontal scrolling?

Thanks.



  reply	other threads:[~2021-11-26  8:35 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87a6hrzrcv.fsf.ref@yahoo.com>
2021-11-26  0:35 ` Pixel scrolling support Po Lu
2021-11-26  2:26   ` Stefan Monnier
2021-11-26  3:06     ` Po Lu
2021-11-26  3:12       ` Po Lu
2021-11-26  6:41         ` Eli Zaretskii
2021-11-26  6:40       ` Eli Zaretskii
2021-11-26  6:45         ` Po Lu
2021-11-26  6:58           ` Eli Zaretskii
2021-11-26  7:01             ` Po Lu
2021-11-26  8:35               ` Eli Zaretskii [this message]
2021-11-26  9:29                 ` Po Lu
2021-11-26 11:26                   ` Eli Zaretskii
2021-11-26 11:38                     ` Po Lu
2021-11-26 12:00                       ` Eli Zaretskii
2021-11-26 12:09                         ` Po Lu
2021-11-26 12:42                           ` Eli Zaretskii
2021-11-26 12:46                             ` Po Lu
2021-11-26 12:49                               ` Po Lu
2021-11-26 13:00                                 ` Eli Zaretskii
2021-11-26 13:03                                   ` Po Lu
2021-11-26 12:07                       ` Stephen Berman
2021-11-26 13:35       ` Stefan Monnier
2021-11-26 13:41         ` Po Lu
2021-11-26 13:46           ` Eli Zaretskii
2021-11-26 13:50             ` Po Lu
2021-11-26  5:57   ` Aaron Madlon-Kay
2021-11-26  6:00     ` Po Lu
2021-11-26  6:11       ` Aaron Madlon-Kay
2021-11-26  6:22   ` Jim Porter
2021-11-26  6:30     ` Po Lu
2021-11-26  6:33   ` Eli Zaretskii
2022-05-18  2:53   ` Michael Heerdegen
2022-05-18  3:11     ` Po Lu
2022-05-18  3:27       ` pixel scroll vs. osm (was: Pixel scrolling support) Michael Heerdegen
2022-05-18  3:47         ` pixel scroll vs. osm Po Lu
2022-05-19  0:34           ` Michael Heerdegen
2022-05-21  0:18           ` Michael Heerdegen
2022-05-21  1:34             ` Po Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83y25b2u2x.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=luangruo@yahoo.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).