bug#61702: Minibuffer scrolling not working when long lines get truncated

bug#61702: Minibuffer scrolling not working when long lines get truncated

[Johann Höchtl]

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

I experience the following annoying behavior: If the text in the minibuffer
get's longer than the display width and lines are therefore continued on
the next line, the minibuffer scrolling no longer works.

What I mean by that is that it "logically" works as when I press <down> or
<up> the indicator correctly displays the number of the item I am supposed
to choose when pressing <RET> yet I can't visually see what I would select.

First I thought it was a marginalia issue but that's not the case. With
marginalia it only shows much more easily as marginalia adds text to
minibuffer entries thus making lines longer. So this is a thing I can
easily reproduce when making the whole Emacs window narrow enough to
trigger continuation lines in the minibuffer.

Seems to be an issue with the highlight line logic and scrolling?

Emacs version 30.0.50

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

bug#61702: Minibuffer scrolling not working when long lines get truncated

[Eli Zaretskii]

> From: Johann Höchtl <johann.hoechtl@gmail.com>
> Date: Wed, 22 Feb 2023 07:59:04 +0100
> 
> I experience the following annoying behavior: If the text in the minibuffer get's longer than the display width
> and lines are therefore continued on the next line, the minibuffer scrolling no longer works.
> 
> What I mean by that is that it "logically" works as when I press <down> or <up> the indicator correctly
> displays the number of the item I am supposed to choose when pressing <RET> yet I can't visually see
> what I would select.
> 
> First I thought it was a marginalia issue but that's not the case. With marginalia it only shows much more
> easily as marginalia adds text to minibuffer entries thus making lines longer. So this is a thing I can easily
> reproduce when making the whole Emacs window narrow enough to trigger continuation lines in the
> minibuffer.
> 
> Seems to be an issue with the highlight line logic and scrolling?

Thank you for your report.

To help investigate and eventually fix the issue, please provide a
reproducible recipe, preferably starting from "emacs -Q" (if
additional packages are needed, include their loading and activation
in the recipe).  This will make sure we see and investigate the same
issue that you are experiencing, and will prevent misunderstandings.

TIA

bug#61702: Minibuffer scrolling not working when long lines get truncated

[Johann Höchtl]

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

I left an important part out of my report: I am using fido-vertical-mode.
So to reproduce:

emacs -Q
M-x fido-vertical-mode
M-x <consta> <-- any search term to narrow down the potential completions,
in this case 12 items remain matching
narrow the whole emacs window so the search results have to "break" because
of long lines
<down> <down> ...
The highlighted active line remains visible until the last items, than the
active line becomes invisible

I hope it's more clear now.

Am Mi., 22. Feb. 2023 um 13:37 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:

> > From: Johann Höchtl <johann.hoechtl@gmail.com>
> > Date: Wed, 22 Feb 2023 07:59:04 +0100
> >
> > I experience the following annoying behavior: If the text in the
> minibuffer get's longer than the display width
> > and lines are therefore continued on the next line, the minibuffer
> scrolling no longer works.
> >
> > What I mean by that is that it "logically" works as when I press <down>
> or <up> the indicator correctly
> > displays the number of the item I am supposed to choose when pressing
> <RET> yet I can't visually see
> > what I would select.
> >
> > First I thought it was a marginalia issue but that's not the case. With
> marginalia it only shows much more
> > easily as marginalia adds text to minibuffer entries thus making lines
> longer. So this is a thing I can easily
> > reproduce when making the whole Emacs window narrow enough to trigger
> continuation lines in the
> > minibuffer.
> >
> > Seems to be an issue with the highlight line logic and scrolling?
>
> Thank you for your report.
>
> To help investigate and eventually fix the issue, please provide a
> reproducible recipe, preferably starting from "emacs -Q" (if
> additional packages are needed, include their loading and activation
> in the recipe).  This will make sure we see and investigate the same
> issue that you are experiencing, and will prevent misunderstandings.
>
> TIA
>

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

bug#61702: Minibuffer scrolling not working when long lines get truncated

[Eli Zaretskii]

> From: Johann Höchtl <johann.hoechtl@gmail.com>
> Date: Thu, 23 Feb 2023 08:12:09 +0100
> Cc: 61702@debbugs.gnu.org
> 
> emacs -Q
> M-x fido-vertical-mode
> M-x <consta> <-- any search term to narrow down the potential completions, in this case 12 items remain
> matching
> narrow the whole emacs window so the search results have to "break" because of long lines
> <down> <down> ... 
> The highlighted active line remains visible until the last items, than the active line becomes invisible

Thanks.

It looks like the code in icomplete--render-vertical implicitly
assumes that every candidate takes just one screen line, which is
false in your scenario.  A workaround is to set truncate-lines non-nil
in the minibuffer.

João, can you take a look, please?

bug#61702: Minibuffer scrolling not working when long lines get truncated

[João Távora]

On Thu, Mar 2, 2023 at 11:52 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Johann Höchtl <johann.hoechtl@gmail.com>
> > Date: Thu, 23 Feb 2023 08:12:09 +0100
> > Cc: 61702@debbugs.gnu.org
> >
> > emacs -Q
> > M-x fido-vertical-mode
> > M-x <consta> <-- any search term to narrow down the potential completions, in this case 12 items remain
> > matching
> > narrow the whole emacs window so the search results have to "break" because of long lines
> > <down> <down> ...
> > The highlighted active line remains visible until the last items, than the active line becomes invisible
>
> Thanks.
>
> It looks like the code in icomplete--render-vertical implicitly
> assumes that every candidate takes just one screen line, which is
> false in your scenario.  A workaround is to set truncate-lines non-nil
> in the minibuffer.
>
> João, can you take a look, please?

I'll take a better look later, but I can say that that truncate-lines
idea sounds very sensible.  Johann can you try this patch?

diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 014f38b2024..4e85e20fddb 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -644,6 +644,7 @@ icomplete--vertical-minibuffer-setup
   (setq-local icomplete-hide-common-prefix nil
               ;; Ask `icomplete-completions' to return enough
completions candidates.
               icomplete-prospects-height 25
+              truncate-lines t
               redisplay-adhoc-scroll-in-resize-mini-windows nil))

 ;;;###autoload

bug#61702: Minibuffer scrolling not working when long lines get truncated

[Johann Höchtl]

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

Sure that works. I am uncertain however if it is "the right thing" (r) to
do. Note, that in conjunction with eg. marginalia, the information to an
entry can become quite long, hopefully because it provides helpful
information. This added information would no longer be visible and I don't
know how to scroll to the left / right to make it visible.

Additionally, if you press two times <TAB> <TAB>
(requiring  '(completion-auto-select 'second-tab) to be set) you get a
different (arguably better) scrolling behaviour, breaking long lines while
retaining the whole information. Similar functionality, different code?

Sidenote: fido-vertical mode makes little sense in conjunction with
(completion-auto-select 'second-tab) but I get what I ask for.

Am Do., 2. März 2023 um 12:57 Uhr schrieb João Távora <joaotavora@gmail.com
>:

> On Thu, Mar 2, 2023 at 11:52 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Johann Höchtl <johann.hoechtl@gmail.com>
> > > Date: Thu, 23 Feb 2023 08:12:09 +0100
> > > Cc: 61702@debbugs.gnu.org
> > >
> > > emacs -Q
> > > M-x fido-vertical-mode
> > > M-x <consta> <-- any search term to narrow down the potential
> completions, in this case 12 items remain
> > > matching
> > > narrow the whole emacs window so the search results have to "break"
> because of long lines
> > > <down> <down> ...
> > > The highlighted active line remains visible until the last items, than
> the active line becomes invisible
> >
> > Thanks.
> >
> > It looks like the code in icomplete--render-vertical implicitly
> > assumes that every candidate takes just one screen line, which is
> > false in your scenario.  A workaround is to set truncate-lines non-nil
> > in the minibuffer.
> >
> > João, can you take a look, please?
>
> I'll take a better look later, but I can say that that truncate-lines
> idea sounds very sensible.  Johann can you try this patch?
>
> diff --git a/lisp/icomplete.el b/lisp/icomplete.el
> index 014f38b2024..4e85e20fddb 100644
> --- a/lisp/icomplete.el
> +++ b/lisp/icomplete.el
> @@ -644,6 +644,7 @@ icomplete--vertical-minibuffer-setup
>    (setq-local icomplete-hide-common-prefix nil
>                ;; Ask `icomplete-completions' to return enough
> completions candidates.
>                icomplete-prospects-height 25
> +              truncate-lines t
>                redisplay-adhoc-scroll-in-resize-mini-windows nil))
>
>  ;;;###autoload
>

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

bug#61702: Minibuffer scrolling not working when long lines get truncated

[João Távora]

On Thu, Mar 2, 2023 at 12:20 PM Johann Höchtl <johann.hoechtl@gmail.com> wrote:
>
> Sure that works. I am uncertain however if it is "the right thing" (r) to do.

I think it's a good first step.  Some scrolling commands need to be added,
probably, because we can't guess where the user wants to look.

How does vertico solve this problem?

João