GNU bug report logs -
#64139
28.2; Scrolling problems in miniwindow
Previous Next
To reply to this bug, email your comments to 64139 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64139
; Package
emacs
.
(Sun, 18 Jun 2023 00:27:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Al Petrofsky <al <at> petrofsky.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 18 Jun 2023 00:27:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64139
; Package
emacs
.
(Sun, 18 Jun 2023 07:10:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 64139 <at> debbugs.gnu.org (full text, mbox):
> From: Al Petrofsky <al <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64139
; Package
emacs
.
(Sun, 18 Jun 2023 09:09:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 64139 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> > > 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.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64139
; Package
emacs
.
(Mon, 19 Jun 2023 17:23:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 64139 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64139
; Package
emacs
.
(Mon, 19 Jun 2023 22:34:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 64139 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64139
; Package
emacs
.
(Wed, 21 Jun 2023 15:02:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 64139 <at> debbugs.gnu.org (full text, mbox):
> From: Al Petrofsky <al <at> petrofsky.org>
> Date: Mon, 19 Jun 2023 18:33:38 -0400
> Cc: Juri Linkov <juri <at> linkov.net>, 64139 <at> 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.
This bug report was last modified 1 year and 359 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.