bug#64139: 28.2; Scrolling problems in miniwindow

bug#64139: 28.2; Scrolling problems in miniwindow

[Al Petrofsky]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

I'm seeing some weird scrolling bugs in the miniwindow when the
minibuffer contains more lines than the window.  I think these
problems exist on ttys and graphical terminals of all sizes, but for
ease of reproducibility use an 80x24 tty.

   emacs-28.2 -Q -nw
   M-: C-@ C-x ( C-x C-k TAB C-q C-j C-u 9 9 C-x e C-x C-x C-v

The C-v, instead of scrolling a few lines, scrolls all the way down to
line 97.

Also, if you now repeatedly M-v, the buffer will just scroll up and
down three lines.  When I use a large X frame, repeated M-v will
scroll up to the top of the buffer, but then glitch and cycle around
back to the bottom.

[-- Attachment #2: Type: text/html, Size: 705 bytes --]

bug#64139: 28.2; Scrolling problems in miniwindow

[Eli Zaretskii]

> From: Al Petrofsky <al@petrofsky.org>
> Date: Sat, 17 Jun 2023 20:26:19 -0400
> 
> I'm seeing some weird scrolling bugs in the miniwindow when the
> minibuffer contains more lines than the window.  I think these
> problems exist on ttys and graphical terminals of all sizes, but for
> ease of reproducibility use an 80x24 tty.
> 
>    emacs-28.2 -Q -nw
>    M-: C-@ C-x ( C-x C-k TAB C-q C-j C-u 9 9 C-x e C-x C-x C-v
> 
> The C-v, instead of scrolling a few lines, scrolls all the way down to
> line 97.

I tried to use this recipe, but it produces weird results, and I don't
see what you describe.  Would you like to show an easier to understand
recipe, or describe what should be in the min-window as result of the
recipe?  And what exactly are your expectations from C-v/M-v in this
case?

I tried this:

  M-x C-u 99 C-q C-j M-<

after that, C-v scrolls the mini-window as expected, so that I get to
the end in 13 C-v keypresses.  Which looks reasonable to me.

> Also, if you now repeatedly M-v, the buffer will just scroll up and
> down three lines.  When I use a large X frame, repeated M-v will
> scroll up to the top of the buffer, but then glitch and cycle around
> back to the bottom.

M-v in the minibuffer is bound to switch-to-completions, so I'm unsure
what you expected here.

Adding Juri who worked on the scrolling commands in the minibuffer.

bug#64139: 28.2; Scrolling problems in miniwindow

[Al Petrofsky]

[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]

>
> > > I'm seeing some weird scrolling bugs in the miniwindow when the
> > > minibuffer contains more lines than the window.  I think these
> > > problems exist on ttys and graphical terminals of all sizes, but for
> > > ease of reproducibility use an 80x24 tty.
> > >
> > >    emacs-28.2 -Q -nw
> > >    M-: C-@ C-x ( C-x C-k TAB C-q C-j C-u 9 9 C-x e C-x C-x C-v
> > >
> > > The C-v, instead of scrolling a few lines, scrolls all the way down to
> > > line 97.
> >
> > I tried to use this recipe, but it produces weird results, and I don't
> > see what you describe.  Would you like to show an easier to understand
> > recipe, or describe what should be in the min-window as result of the
> > recipe?  And what exactly are your expectations from C-v/M-v in this
> > case?
>
> After the C-x e, the minibuffer contains 100 lines, each with a number
> "0" to "99".  After the C-x C-x, the miniwindow contents are, as
> expected, this:
>
>    Eval: 0
>    1
>    2
>    3
>    4
>
> After the C-v, I expect to see this:
>
>    3
>    4
>    5
>    6
>    7
>
> Instead I see this:
>
>    96
>    97 [cursor is at start of this line]
>    98
>    99
>    [empty line]
>
> > I tried this:
> >
> >   M-x C-u 99 C-q C-j M-<
> >
> > after that, C-v scrolls the mini-window as expected, so that I get to
> > the end in 13 C-v keypresses.  Which looks reasonable to me.
>
> I don't think 13 is right.  The miniwindow is only 5 lines (if tty is
> 80x24), so C-v should only be scrolling 3 lines at a time.
>
> Try this:
>
>    M-x C-@ C-u 9 9 C-q C-j C-x C-x C-v C-v C-v C-v
>
> I get "scroll-up-command: End of buffer" on only the fourth C-v.
>
> > > Also, if you now repeatedly M-v, the buffer will just scroll up and
> > > down three lines.  When I use a large X frame, repeated M-v will
> > > scroll up to the top of the buffer, but then glitch and cycle around
> > > back to the bottom.
>
> (By "scroll up" there I meant the window contents scroll down,
> i.e. the thing the PC keyboard key labeled "Page Up" does, which Emacs
> calls scroll-down.)
>
> > M-v in the minibuffer is bound to switch-to-completions, so I'm unsure
> > what you expected here.
>
> M-: doesn't do completion (although you can complete symbols within
> the expression with C-M-i), and leaves M-v bound to
> scroll-down-command.

[-- Attachment #2: Type: text/html, Size: 2818 bytes --]

bug#64139: 28.2; Scrolling problems in miniwindow

[Juri Linkov]

> M-v in the minibuffer is bound to switch-to-completions, so I'm unsure
> what you expected here.
>
> Adding Juri who worked on the scrolling commands in the minibuffer.

I worked only on the <down> key bound to next-line-or-history-element.

bug#64139: 28.2; Scrolling problems in miniwindow

[Al Petrofsky]

[-- Attachment #1: Type: text/plain, Size: 366 bytes --]

Here's a simpler and clearer recipe that should show the problem on
any tty or X display:

   emacs-28.2 -Q
   M-: C-u 9 9 C-q C-j x C-@ M-< C-v

This creates a 100-line minibuffer with "x" on the last line.  After
the M-< and C-v, we should be one windowful down from the top, but
instead we've scrolled nearly to the end and the "x" has shown up on
the last line.

[-- Attachment #2: Type: text/html, Size: 462 bytes --]

bug#64139: 28.2; Scrolling problems in miniwindow

[Eli Zaretskii]

> From: Al Petrofsky <al@petrofsky.org>
> Date: Mon, 19 Jun 2023 18:33:38 -0400
> Cc: Juri Linkov <juri@linkov.net>, 64139@debbugs.gnu.org
> 
> Here's a simpler and clearer recipe that should show the problem on
> any tty or X display:
> 
>    emacs-28.2 -Q
>    M-: C-u 9 9 C-q C-j x C-@ M-< C-v
> 
> This creates a 100-line minibuffer with "x" on the last line.  After
> the M-< and C-v, we should be one windowful down from the top, but
> instead we've scrolled nearly to the end and the "x" has shown up on
> the last line.

Thanks.

This is a feature: scrolling (and redisplay in general) in the
mini-window is tailored to try and display the most important part of
the minibuffer text.  The feature is intended to support various
minibuffer-editing packages which display a lot of text in the
mini-window when the user is prompted for a file name or other similar
stuff, of which there are a lot of possible candidates.

If you set the variable redisplay-adhoc-scroll-in-resize-mini-windows
to a nil value, you will get the "normal" scrolling behavior in the
mini-window.