Fixing precision scrolling in terminal buffers

Fixing precision scrolling in terminal buffers

[Po Lu]

Does anyone mind if I make the following change to term.el, so that
precision scrolling works correctly when point is at the end of process
output?  Thanks.

diff --git a/lisp/term.el b/lisp/term.el
index e0a2f0a9a4..5961350ff9 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -3300,13 +3300,16 @@ term-goto-process-mark-maybe
 `term-char-mode' to prevent commands from putting the buffer into
 an inconsistent state by unexpectedly moving point.
 
-Mouse events are ignored so that mouse selection is unimpeded.
+Mouse and wheel events are ignored so that mouse selection and
+mouse wheel scrolling is unimpeded.
 
 Only acts when the pre-command position of point was equal to the
 process mark, and the `term-char-mode-point-at-process-mark'
 option is enabled.  See `term-set-goto-process-mark'."
   (when term-goto-process-mark
-    (unless (mouse-event-p last-command-event)
+    (unless (or (mouse-event-p last-command-event)
+                (memq (event-basic-type last-command-event)
+                      '(wheel-down wheel-up)))
       (goto-char (term-process-mark)))))
 
 (defun term-process-mark ()

Re: Fixing precision scrolling in terminal buffers

[Phil Sainty]

On 2021-12-27 18:45, Po Lu wrote:
> Does anyone mind if I make the following change to term.el, so that
> precision scrolling works correctly when point is at the end of process
> output?

Offhand I think we should support this behaviour.  I added the term code
in question, and I think I hadn't noticed this deficiency.  I possibly
thought `mouse-event-p' was capturing these events.

I note that on my system the wheel events are `mouse-4' and `mouse-5',
as described at (info "(elisp)Misc Events") :

‘(wheel-up POSITION)’
‘(wheel-down POSITION)’
      These kinds of event are generated by moving a mouse wheel.  The
      POSITION element is a mouse position list (*note Click Events::),
      specifying the position of the mouse cursor when the event
      occurred.

      This kind of event is generated only on some kinds of systems.  On
      some systems, ‘mouse-4’ and ‘mouse-5’ are used instead.  For
      portable code, use the variables ‘mouse-wheel-up-event’ and
      ‘mouse-wheel-down-event’ defined in ‘mwheel.el’ to determine what
      event types to expect for the mouse wheel.

However I see that `mouse-event-p' doesn't capture those either, and
it's actually `mouse-wheel-mode' which is handling those, by binding
those events (amongst others) to `mwheel-scroll'.

So some comments/questions:

1. It sounds like this change should actually use `mouse-wheel-up-event'
    and `mouse-wheel-down-event'?

2. Is the problem actually that `mouse-wheel-mode' isn't handling this
    in terminals the way it does in GUIs?  I'm not sure what's supposed
    to happen -- I'm not sure I've ever used a mouse wheel when running
    Emacs inside a terminal before now, but what I observe is that in a
    *terminal* buffer the mouse wheel cycles the shell command history
    in terminal frames, but scrolls the window in GUI frames.

3. `mouse-event-p' seems weird.  It describes itself as capturing click
    events, but additionally captures movement events (and contains a
    comment questioning this), and ignores wheel events.  I feel that
    it would be nicer if `mouse-event-p' meant "events involving the 
mouse
    in some way", and that there was a mouse-click-event-p which only
    meant click events.  We also have a separate `mouse-movement-p' for
    only movement events, but no analogue for wheel events.  Perhaps
    we should consider (a) adding `mouse-any-event-p' which means "any
    mouse-related event"; (b) adding `mouse-click-event-p' for just the
    click events; and (c) consider whether `mouse-event-p' should be
    marked as obsolete in favour of one of the alternatives, or a new
    `mouse-click-or-movement-event-p' which better describes it?

    (I am unsure about all of that -- I expect there are many things
    that I don't understand about mouse support.)


-Phil



> diff --git a/lisp/term.el b/lisp/term.el
> index e0a2f0a9a4..5961350ff9 100644
> --- a/lisp/term.el
> +++ b/lisp/term.el
> @@ -3300,13 +3300,16 @@ term-goto-process-mark-maybe
>  `term-char-mode' to prevent commands from putting the buffer into
>  an inconsistent state by unexpectedly moving point.
> 
> -Mouse events are ignored so that mouse selection is unimpeded.
> +Mouse and wheel events are ignored so that mouse selection and
> +mouse wheel scrolling is unimpeded.
> 
>  Only acts when the pre-command position of point was equal to the
>  process mark, and the `term-char-mode-point-at-process-mark'
>  option is enabled.  See `term-set-goto-process-mark'."
>    (when term-goto-process-mark
> -    (unless (mouse-event-p last-command-event)
> +    (unless (or (mouse-event-p last-command-event)
> +                (memq (event-basic-type last-command-event)
> +                      '(wheel-down wheel-up)))
>        (goto-char (term-process-mark)))))

Re: Fixing precision scrolling in terminal buffers

[Po Lu]

Phil Sainty <psainty@orcon.net.nz> writes:

> So some comments/questions:
>
> 1. It sounds like this change should actually use `mouse-wheel-up-event'
>    and `mouse-wheel-down-event'?

The precision scrolling code doesn't work with mouse-4 and mouse-5
events, as they are only generated by ttys and the Core Input code, both
of which don't provide pixel deltas.  (The manual you want is the Lisp
reference manual for Emacs 29: yours is too old to describe this.)

> 2. Is the problem actually that `mouse-wheel-mode' isn't handling this
>    in terminals the way it does in GUIs?  I'm not sure what's supposed
>    to happen -- I'm not sure I've ever used a mouse wheel when running
>    Emacs inside a terminal before now, but what I observe is that in a
>    *terminal* buffer the mouse wheel cycles the shell command history
>    in terminal frames, but scrolls the window in GUI frames.

No, you have to turn on (for example) xterm-mouse-mode for the mouse
wheel to work properly in supported terminals.  My theory for why
scrolling used to work is that the scroll functions force the window
start, and post-command-hook is run before redisplay has a chance to, so
it can't move the point outside the visible area without it being moved
back in by redisplay.  However, the precision scrolling code can't force
start, as that resets vscroll.

Thanks.

Re: Fixing precision scrolling in terminal buffers

[Phil Sainty]

On 2021-12-27 22:14, Po Lu wrote:
> The manual you want is the Lisp reference manual for Emacs 29

Ah, ok.  I don't know anything about these changes, then.

I'll just say that the intention of the term.el code is certainly
to allow the user to move point around with the mouse, so if this
is the best fix when precision scrolling is used, then I'm in
favour of it.

(I do still wonder whether the set of mouse event predicates could
be improved, though.)


-Phil

Re: Fixing precision scrolling in terminal buffers

[Po Lu]

Phil Sainty <psainty@orcon.net.nz> writes:

> I'll just say that the intention of the term.el code is certainly
> to allow the user to move point around with the mouse, so if this
> is the best fix when precision scrolling is used, then I'm in
> favour of it.

> (I do still wonder whether the set of mouse event predicates could
> be improved, though.)

Indeed, but that's a topic for another time.

I'll make the change now, thanks.