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)))))