GNU bug report logs - #61702
Minibuffer scrolling not working when long lines get truncated

Previous Next

To reply to this bug, email your comments to 61702 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Johann Höchtl <johann.hoechtl <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Minibuffer scrolling not working when long lines get truncated
Date: Wed, 22 Feb 2023 07:59:04 +0100

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #8 received at 61702 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Johann Höchtl <johann.hoechtl <at> gmail.com>
Cc: 61702 <at> debbugs.gnu.org
Subject: Re: bug#61702: Minibuffer scrolling not working when long lines get
 truncated
Date: Wed, 22 Feb 2023 14:38:00 +0200

> From: Johann Höchtl <johann.hoechtl <at> 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

Message #11 received at 61702 <at> debbugs.gnu.org (full text, mbox):

From: Johann Höchtl <johann.hoechtl <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61702 <at> debbugs.gnu.org
Subject: Re: bug#61702: Minibuffer scrolling not working when long lines get
 truncated
Date: Thu, 23 Feb 2023 08:12:09 +0100

[Message part 1 (text/plain, inline)]

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 <at> gnu.org>:

> > From: Johann Höchtl <johann.hoechtl <at> 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
>

[Message part 2 (text/html, inline)]

Message #14 received at 61702 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Johann Höchtl <johann.hoechtl <at> gmail.com>,
 João Távora <joaotavora <at> gmail.com>
Cc: 61702 <at> debbugs.gnu.org
Subject: Re: bug#61702: Minibuffer scrolling not working when long lines get
 truncated
Date: Thu, 02 Mar 2023 13:52:18 +0200

> From: Johann Höchtl <johann.hoechtl <at> gmail.com>
> Date: Thu, 23 Feb 2023 08:12:09 +0100
> Cc: 61702 <at> 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?

Message #17 received at 61702 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Johann Höchtl <johann.hoechtl <at> gmail.com>,
 61702 <at> debbugs.gnu.org
Subject: Re: bug#61702: Minibuffer scrolling not working when long lines get
 truncated
Date: Thu, 2 Mar 2023 11:57:15 +0000

On Thu, Mar 2, 2023 at 11:52 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Johann Höchtl <johann.hoechtl <at> gmail.com>
> > Date: Thu, 23 Feb 2023 08:12:09 +0100
> > Cc: 61702 <at> 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

Message #20 received at 61702 <at> debbugs.gnu.org (full text, mbox):

From: Johann Höchtl <johann.hoechtl <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 61702 <at> debbugs.gnu.org
Subject: Re: bug#61702: Minibuffer scrolling not working when long lines get
 truncated
Date: Thu, 2 Mar 2023 13:20:18 +0100

[Message part 1 (text/plain, inline)]

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 <at> gmail.com
>:

> On Thu, Mar 2, 2023 at 11:52 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Johann Höchtl <johann.hoechtl <at> gmail.com>
> > > Date: Thu, 23 Feb 2023 08:12:09 +0100
> > > Cc: 61702 <at> 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
>

[Message part 2 (text/html, inline)]

Message #23 received at 61702 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Johann Höchtl <johann.hoechtl <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 61702 <at> debbugs.gnu.org
Subject: Re: bug#61702: Minibuffer scrolling not working when long lines get
 truncated
Date: Thu, 2 Mar 2023 13:48:17 +0000

On Thu, Mar 2, 2023 at 12:20 PM Johann Höchtl <johann.hoechtl <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.