GNU logs - #61702, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#61702: Minibuffer scrolling not working when long lines get truncated
Resent-From: Johann =?UTF-8?Q?H=C3=B6chtl?= <johann.hoechtl@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 22 Feb 2023 07:00:01 +0000
Resent-Message-ID: <handler.61702.B.167704916316764 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 61702 <at> debbugs.gnu.org
MIME-Version: 1.0
From: Johann =?UTF-8?Q?H=C3=B6chtl?= <johann.hoechtl@HIDDEN>
Date: Wed, 22 Feb 2023 07:59:04 +0100
Message-ID: <CAH4isRxP6fXcQFn+L119N-_Z-shuwmzNCfb9yrsrcJoijtj+Kw@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000031675d05f5446f6e"
Received-SPF: pass client-ip=2001:4860:4864:20::2a;
 envelope-from=johann.hoechtl@HIDDEN; helo=mail-oa1-x2a.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--00000000000031675d05f5446f6e
Content-Type: text/plain; charset="UTF-8"

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

--00000000000031675d05f5446f6e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I experience the following annoying behavior: If the text =
in the minibuffer get&#39;s longer than the display width and lines are the=
refore continued on the next line, the minibuffer scrolling no longer works=
.<br><br>What I mean by that is that it &quot;logically&quot; works as when=
 I press &lt;down&gt; or &lt;up&gt; the indicator correctly displays the nu=
mber of the item I am supposed to choose when pressing &lt;RET&gt; yet I ca=
n&#39;t visually see what I would select.<br><br>First I thought it was a m=
arginalia issue but that&#39;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 who=
le Emacs window narrow enough to trigger continuation lines in the minibuff=
er.<br><br>Seems to be an issue with the highlight line logic and scrolling=
?<br><div><br></div><div>Emacs version 30.0.50</div></div>

--00000000000031675d05f5446f6e--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Johann =?UTF-8?Q?H=C3=B6chtl?= <johann.hoechtl@HIDDEN>
Subject: bug#61702: Acknowledgement (Minibuffer scrolling not working when
 long lines get truncated)
Message-ID: <handler.61702.B.167704916316764.ack <at> debbugs.gnu.org>
References: <CAH4isRxP6fXcQFn+L119N-_Z-shuwmzNCfb9yrsrcJoijtj+Kw@HIDDEN>
X-Gnu-PR-Message: ack 61702
X-Gnu-PR-Package: emacs
Reply-To: 61702 <at> debbugs.gnu.org
Date: Wed, 22 Feb 2023 07:00:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 61702 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
61702: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D61702
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#61702: Minibuffer scrolling not working when long lines get truncated
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 22 Feb 2023 12:38:01 +0000
Resent-Message-ID: <handler.61702.B61702.16770694774065 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Johann =?UTF-8?Q?H=C3=B6chtl?= <johann.hoechtl@HIDDEN>
Cc: 61702 <at> debbugs.gnu.org
Date: Wed, 22 Feb 2023 14:38:00 +0200
Message-Id: <83h6vdswnr.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAH4isRxP6fXcQFn+L119N-_Z-shuwmzNCfb9yrsrcJoijtj+Kw@HIDDEN>
 (message from Johann =?UTF-8?Q?H=C3=B6chtl?= on Wed, 22 Feb 2023 07:59:04
 +0100)
References: <CAH4isRxP6fXcQFn+L119N-_Z-shuwmzNCfb9yrsrcJoijtj+Kw@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Johann Höchtl <johann.hoechtl@HIDDEN>
> 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 sent to bug-gnu-emacs@HIDDEN:

Subject: bug#61702: Minibuffer scrolling not working when long lines get truncated
Resent-From: Johann =?UTF-8?Q?H=C3=B6chtl?= <johann.hoechtl@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 23 Feb 2023 07:13:01 +0000
Resent-Message-ID: <handler.61702.B61702.167713634826228 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 61702 <at> debbugs.gnu.org
MIME-Version: 1.0
References: <CAH4isRxP6fXcQFn+L119N-_Z-shuwmzNCfb9yrsrcJoijtj+Kw@HIDDEN>
 <83h6vdswnr.fsf@HIDDEN>
In-Reply-To: <83h6vdswnr.fsf@HIDDEN>
From: Johann =?UTF-8?Q?H=C3=B6chtl?= <johann.hoechtl@HIDDEN>
Date: Thu, 23 Feb 2023 08:12:09 +0100
Message-ID: <CAH4isRxE_22pFSoSLMqaKesSnHiQDYsLM8X0posU-q9BUDjNcw@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000d2979605f558bbf7"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--000000000000d2979605f558bbf7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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@HIDDEN>:

> > From: Johann H=C3=B6chtl <johann.hoechtl@HIDDEN>
> > 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
>

--000000000000d2979605f558bbf7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I left an important part out of my report: I am using fido=
-vertical-mode. So to reproduce:<div><br></div><div>emacs -Q</div><div>M-x =
fido-vertical-mode</div><div>M-x &lt;consta&gt; &lt;-- any search term to n=
arrow down the potential completions, in this case 12 items remain matching=
</div><div>narrow the=C2=A0whole emacs window so the search results have to=
 &quot;break&quot; because of long lines</div><div>&lt;down&gt; &lt;down&gt=
; ...=C2=A0</div><div>The highlighted active line remains visible until the=
 last items, than the active line becomes invisible</div><div><br></div><di=
v>I hope it&#39;s more clear now.</div></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">Am Mi., 22. Feb. 2023 um 13:37=C2=A0=
Uhr schrieb Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN<=
/a>&gt;:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; Fr=
om: Johann H=C3=B6chtl &lt;<a href=3D"mailto:johann.hoechtl@HIDDEN" targ=
et=3D"_blank">johann.hoechtl@HIDDEN</a>&gt;<br>
&gt; Date: Wed, 22 Feb 2023 07:59:04 +0100<br>
&gt; <br>
&gt; I experience the following annoying behavior: If the text in the minib=
uffer get&#39;s longer than the display width<br>
&gt; and lines are therefore continued on the next line, the minibuffer scr=
olling no longer works.<br>
&gt; <br>
&gt; What I mean by that is that it &quot;logically&quot; works as when I p=
ress &lt;down&gt; or &lt;up&gt; the indicator correctly<br>
&gt; displays the number of the item I am supposed to choose when pressing =
&lt;RET&gt; yet I can&#39;t visually see<br>
&gt; what I would select.<br>
&gt; <br>
&gt; First I thought it was a marginalia issue but that&#39;s not the case.=
 With marginalia it only shows much more<br>
&gt; easily as marginalia adds text to minibuffer entries thus making lines=
 longer. So this is a thing I can easily<br>
&gt; reproduce when making the whole Emacs window narrow enough to trigger =
continuation lines in the<br>
&gt; minibuffer.<br>
&gt; <br>
&gt; Seems to be an issue with the highlight line logic and scrolling?<br>
<br>
Thank you for your report.<br>
<br>
To help investigate and eventually fix the issue, please provide a<br>
reproducible recipe, preferably starting from &quot;emacs -Q&quot; (if<br>
additional packages are needed, include their loading and activation<br>
in the recipe).=C2=A0 This will make sure we see and investigate the same<b=
r>
issue that you are experiencing, and will prevent misunderstandings.<br>
<br>
TIA<br>
</blockquote></div>

--000000000000d2979605f558bbf7--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#61702: Minibuffer scrolling not working when long lines get truncated
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 02 Mar 2023 11:53:02 +0000
Resent-Message-ID: <handler.61702.B61702.167775795312037 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 61702
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Johann =?UTF-8?Q?H=C3=B6chtl?= <johann.hoechtl@HIDDEN>, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 61702 <at> debbugs.gnu.org
Received: via spool by 61702-submit <at> debbugs.gnu.org id=B61702.167775795312037
          (code B ref 61702); Thu, 02 Mar 2023 11:53:02 +0000
Received: (at 61702) by debbugs.gnu.org; 2 Mar 2023 11:52:33 +0000
Received: from localhost ([127.0.0.1]:55999 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1pXhU9-000385-EF
	for submit <at> debbugs.gnu.org; Thu, 02 Mar 2023 06:52:33 -0500
Received: from eggs.gnu.org ([209.51.188.92]:45778)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1pXhU7-00037s-5a
 for 61702 <at> debbugs.gnu.org; Thu, 02 Mar 2023 06:52:32 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1pXhU0-00072X-2q; Thu, 02 Mar 2023 06:52:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=6Hc0ieTvu8ERLOXuQOdlht29SlyhVKxvJ2PUyRMFQgM=; b=mJqTy1WmUDwD3jDj0r+L
 WjoNi/xbJfHOqJz24ekxZkPF3EVmEPLCM/gu21bbjuV+RQ9ZEIO/Oi3dXjTtvXOTbmuBP6+SjGHN+
 XIvBsBCUuvA+vLlNQUsnh0bpGXEtS3W/QsSMYryEdDQCfb3GCXU9aemtiAACsnRM8SpPMb+81fu2I
 8sdadFaxJYN0HLS3M+YYkPy4/qe9r0M8GQXrWb96tXiq99vAfSF77TY59yVx36F8p56nnqVyiFdX8
 CZ2VBPm9p5VbRCJ5PUisDrMVhaiTEW0eLV0ZKM7qfkuCPbv8CaScC2JA7vc3+LWs2O9H8CZSTdLUX
 TCYL/r6+I+Pzzg==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1pXhTy-0002uL-Mv; Thu, 02 Mar 2023 06:52:23 -0500
Date: Thu, 02 Mar 2023 13:52:18 +0200
Message-Id: <83cz5re5fx.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAH4isRxE_22pFSoSLMqaKesSnHiQDYsLM8X0posU-q9BUDjNcw@HIDDEN>
 (message from Johann =?UTF-8?Q?H=C3=B6chtl?= on Thu, 23 Feb 2023 08:12:09
 +0100)
References: <CAH4isRxP6fXcQFn+L119N-_Z-shuwmzNCfb9yrsrcJoijtj+Kw@HIDDEN>
 <83h6vdswnr.fsf@HIDDEN>
 <CAH4isRxE_22pFSoSLMqaKesSnHiQDYsLM8X0posU-q9BUDjNcw@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Johann Höchtl <johann.hoechtl@HIDDEN>
> 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#61702: Minibuffer scrolling not working when long lines get truncated
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 02 Mar 2023 11:58:01 +0000
Resent-Message-ID: <handler.61702.B61702.167775825412717 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 61702
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Johann =?UTF-8?Q?H=C3=B6chtl?= <johann.hoechtl@HIDDEN>, 61702 <at> debbugs.gnu.org
Received: via spool by 61702-submit <at> debbugs.gnu.org id=B61702.167775825412717
          (code B ref 61702); Thu, 02 Mar 2023 11:58:01 +0000
Received: (at 61702) by debbugs.gnu.org; 2 Mar 2023 11:57:34 +0000
Received: from localhost ([127.0.0.1]:56007 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1pXhZ0-0003J3-6C
	for submit <at> debbugs.gnu.org; Thu, 02 Mar 2023 06:57:34 -0500
Received: from mail-ot1-f44.google.com ([209.85.210.44]:39579)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1pXhYy-0003Ip-Jb
 for 61702 <at> debbugs.gnu.org; Thu, 02 Mar 2023 06:57:32 -0500
Received: by mail-ot1-f44.google.com with SMTP id
 o4-20020a9d6d04000000b00694127788f4so5472432otp.6
 for <61702 <at> debbugs.gnu.org>; Thu, 02 Mar 2023 03:57:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20210112; t=1677758247;
 h=content-transfer-encoding:cc:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:from:to:cc:subject:date
 :message-id:reply-to;
 bh=0Xf2MOwjL3zP28VIUXWYFIIk/yyl90bWnMr0c3PB3T0=;
 b=iMREo1wUzv13vQOzFomTyz2CcuXKKuuxEvWd3TtKv/e933m8hYD93p3pxDHOaO0kjY
 JHBZ67aPksk+PDwGPZ/EhZSIxqIWvtMjBPLFW2/PGh0LtbS4T1bZK/qlyRqKquk7ZidO
 SQN9kYQEggXjbPIx4G4D5FW3PQUZdOpBCJuxtQW8prfH24EgTgeJihgSthhSjGvjGrKp
 iRqf/3mRmPcbsG7uu0Av93HfSOUyJmOSsSZM2Vu9cl938ZhpfwAwCNAdh8pUcpAAYInq
 TTm+bKdwkTtycrKk490XYvZc4rwPmoeoLHUhUZfk9+4g8Z2puc72IUZFFnVYSt6kFoXE
 DAWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112; t=1677758247;
 h=content-transfer-encoding:cc:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=0Xf2MOwjL3zP28VIUXWYFIIk/yyl90bWnMr0c3PB3T0=;
 b=yZAVOgVHrQa2UaG/hcOVasYXQa8mk74qpUzUc4HTD+RJ9FaFcL9egt7bL3d/ioLpfK
 Mn9i6VraSA8uXS0wisE2QlVMgVcDXKJNbt32BkovFIkmUpPZKruxodGey8r6gWwfIweu
 NmEAAwSVKRCuk6m08e2l2ylTRTXPb8xMuiRqIJfbeHcZeq7M5pkPB+NU57SOompUOgsw
 3xQcViihTCFO77UxR+mPfYPJ8Q+zQN196b/a7M0Tx6a+MRumwl/SzFFzaVc/BIE53vzs
 0WEuhNEFlCgwhVrMt2Ilxh9jtpsa+vUVdKrleLgT5hGfofG/ERDqp9JTZnS83xr+5Cpa
 Mcgw==
X-Gm-Message-State: AO0yUKXCR/1g9MPCt4F14mBp+zXPWYmyfv6rgpuBES5ZdPTluQJ1Sc5m
 9a7cb/jyaoomdjWCUSLYRcmHtiqzB7KqOaPdPr4=
X-Google-Smtp-Source: AK7set8O6Ckx+tkUbQZ606di4eU9YTi3DlnizONYUFGBW/NlI/Mgkhv/JXn/uMbM8xsVwVF/8bICYi5g6RhakHaJvSc=
X-Received: by 2002:a9d:454a:0:b0:68b:8067:b5d4 with SMTP id
 p10-20020a9d454a000000b0068b8067b5d4mr3451182oti.3.1677758246812; Thu, 02 Mar
 2023 03:57:26 -0800 (PST)
MIME-Version: 1.0
References: <CAH4isRxP6fXcQFn+L119N-_Z-shuwmzNCfb9yrsrcJoijtj+Kw@HIDDEN>
 <83h6vdswnr.fsf@HIDDEN>
 <CAH4isRxE_22pFSoSLMqaKesSnHiQDYsLM8X0posU-q9BUDjNcw@HIDDEN>
 <83cz5re5fx.fsf@HIDDEN>
In-Reply-To: <83cz5re5fx.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Thu, 2 Mar 2023 11:57:15 +0000
Message-ID: <CALDnm50FLzGnsLPFvPznHxLGhvMc5h8BmfEAdcj_9AXGFOp0Zg@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Thu, Mar 2, 2023 at 11:52=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote:
>
> > From: Johann H=C3=B6chtl <johann.hoechtl@HIDDEN>
> > 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 completio=
ns, in this case 12 items remain
> > matching
> > narrow the whole emacs window so the search results have to "break" bec=
ause 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=C3=A3o, 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#61702: Minibuffer scrolling not working when long lines get truncated
Resent-From: Johann =?UTF-8?Q?H=C3=B6chtl?= <johann.hoechtl@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 02 Mar 2023 12:21:02 +0000
Resent-Message-ID: <handler.61702.B61702.167775963714928 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 61702
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 61702 <at> debbugs.gnu.org
Received: via spool by 61702-submit <at> debbugs.gnu.org id=B61702.167775963714928
          (code B ref 61702); Thu, 02 Mar 2023 12:21:02 +0000
Received: (at 61702) by debbugs.gnu.org; 2 Mar 2023 12:20:37 +0000
Received: from localhost ([127.0.0.1]:56027 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1pXhvI-0003sh-Ux
	for submit <at> debbugs.gnu.org; Thu, 02 Mar 2023 07:20:37 -0500
Received: from mail-oa1-f50.google.com ([209.85.160.50]:46625)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <johann.hoechtl@HIDDEN>) id 1pXhvH-0003sU-Jp
 for 61702 <at> debbugs.gnu.org; Thu, 02 Mar 2023 07:20:36 -0500
Received: by mail-oa1-f50.google.com with SMTP id
 586e51a60fabf-172a623ad9aso17776681fac.13
 for <61702 <at> debbugs.gnu.org>; Thu, 02 Mar 2023 04:20:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20210112; t=1677759629;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=G4Awz5whA0zbMA9W8uZHUCZaUvgUJtwgfE9uM4rdw4E=;
 b=ZLiG8S3V9pH8V/pTLyXDNoMVS2ntQwTu4X7/nX8fLHbNz63SHHZ+kupPZnrGyhceZJ
 XkOV5kEkLqSB/gHfxebkt8XmjWRigV6OTaB60nrFppvWJkWKHlHQX2ooPAbYlT2mfxPf
 3vz9mWYTkffaKohjzdF3L2aoPQEDYYLtrWmb/E9MQVfYHd0fq2G5kmyF2MJC4SqhxbNB
 yMyK/8HTme7BszvVtmDNzImbJjRkbBpNGutNuNLw99ypMZdNDYVEAZmPZyKR8R73wYId
 pRs5iaUh2mCpvZAeWm6xFMrVarBxieiFuvA6AuvJo5oEb0QG8ny8Pm8UoJ9WaFjwZ67i
 cEDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112; t=1677759629;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=G4Awz5whA0zbMA9W8uZHUCZaUvgUJtwgfE9uM4rdw4E=;
 b=Gj6pY8ptJE9tLR6QRLuhqIkOCThydYMZhYMPQDBsnNiQjHDUC8gqLiM3TD5TwDVLyL
 Fn17UuDGu9bjZXzZFODnty+ehw4OOwgPjb6WzQtpiPENO5P1O1scMpDjYzJ1SrY1GBUN
 loBoLGrh3GhrPn8FlEDZZfb3MQbLvz7XvzN7hz+ketbLWOo/C2GTKLq7dLdN2nLHGwDf
 KZiMsphhvR6mCs5jdMYHAYj74qiDPcnc0Z6fy+v1ACoI1823V9/iJeKlNJ6dq11vPwcp
 kpyvL/+XwZv/rQ0PlBBZIPfOkrAWz5A7kGoqwO2fG+CwGrvQcMQGnMov2RQt6gtetLII
 eUuQ==
X-Gm-Message-State: AO0yUKW3m0u9pHjqFyMRGWGQRBBMJWxG/2pPIFrk8y+mgxxZtyIfkM5q
 71nqyvB7sU7oxCtUV7F0xFP5mwLEHPBpL7x+UQ==
X-Google-Smtp-Source: AK7set//DC7sAoTTyY8poQOgN83BNPZPNhC9QCJCRKVWwjn6j0F6bfJPlv0nWPcVzvS4LGlb8X7enoqwMeJn4wzwULI=
X-Received: by 2002:a05:6870:9481:b0:16d:e3e4:f12 with SMTP id
 w1-20020a056870948100b0016de3e40f12mr3052433oal.4.1677759629632; Thu, 02 Mar
 2023 04:20:29 -0800 (PST)
MIME-Version: 1.0
References: <CAH4isRxP6fXcQFn+L119N-_Z-shuwmzNCfb9yrsrcJoijtj+Kw@HIDDEN>
 <83h6vdswnr.fsf@HIDDEN>
 <CAH4isRxE_22pFSoSLMqaKesSnHiQDYsLM8X0posU-q9BUDjNcw@HIDDEN>
 <83cz5re5fx.fsf@HIDDEN>
 <CALDnm50FLzGnsLPFvPznHxLGhvMc5h8BmfEAdcj_9AXGFOp0Zg@HIDDEN>
In-Reply-To: <CALDnm50FLzGnsLPFvPznHxLGhvMc5h8BmfEAdcj_9AXGFOp0Zg@HIDDEN>
From: Johann =?UTF-8?Q?H=C3=B6chtl?= <johann.hoechtl@HIDDEN>
Date: Thu, 2 Mar 2023 13:20:18 +0100
Message-ID: <CAH4isRwqCU8qC2kveUJpLsagkFsauuDguT-zrVNghx9G-Zq5+A@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000be2cbd05f5e9daad"
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--000000000000be2cbd05f5e9daad
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=C3=A4rz 2023 um 12:57 Uhr schrieb Jo=C3=A3o T=C3=A1vora <joaot=
avora@HIDDEN
>:

> On Thu, Mar 2, 2023 at 11:52=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrot=
e:
> >
> > > From: Johann H=C3=B6chtl <johann.hoechtl@HIDDEN>
> > > 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, tha=
n
> 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=C3=A3o, 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
>

--000000000000be2cbd05f5e9daad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sure that works. I am uncertain however if it is &quot;the=
 right thing&quot; (r) to do. Note, that in conjunction with eg. marginalia=
, the information to an entry can become quite long, hopefully because it p=
rovides helpful information. This added information would no longer be visi=
ble and I don&#39;t know how to scroll to the left / right to make it visib=
le.<div><br></div><div>Additionally, if you press two times &lt;TAB&gt; &lt=
;TAB&gt; (requiring=C2=A0=C2=A0&#39;(completion-auto-select &#39;second-tab=
) to be set) you get a different (arguably better) scrolling behaviour, bre=
aking long lines while retaining the whole information. Similar functionali=
ty, different=C2=A0code?</div><div><br></div><div>Sidenote: fido-vertical m=
ode makes little sense in conjunction with (completion-auto-select &#39;sec=
ond-tab) but I get what I ask for.</div></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">Am Do., 2. M=C3=A4rz 2023 um 12:57=
=C2=A0Uhr schrieb Jo=C3=A3o T=C3=A1vora &lt;<a href=3D"mailto:joaotavora@gm=
ail.com">joaotavora@HIDDEN</a>&gt;:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">On Thu, Mar 2, 2023 at 11:52=E2=80=AFAM Eli Zaretski=
i &lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>&gt=
; wrote:<br>
&gt;<br>
&gt; &gt; From: Johann H=C3=B6chtl &lt;<a href=3D"mailto:johann.hoechtl@gma=
il.com" target=3D"_blank">johann.hoechtl@HIDDEN</a>&gt;<br>
&gt; &gt; Date: Thu, 23 Feb 2023 08:12:09 +0100<br>
&gt; &gt; Cc: <a href=3D"mailto:61702 <at> debbugs.gnu.org" target=3D"_blank">61=
702 <at> debbugs.gnu.org</a><br>
&gt; &gt;<br>
&gt; &gt; emacs -Q<br>
&gt; &gt; M-x fido-vertical-mode<br>
&gt; &gt; M-x &lt;consta&gt; &lt;-- any search term to narrow down the pote=
ntial completions, in this case 12 items remain<br>
&gt; &gt; matching<br>
&gt; &gt; narrow the whole emacs window so the search results have to &quot=
;break&quot; because of long lines<br>
&gt; &gt; &lt;down&gt; &lt;down&gt; ...<br>
&gt; &gt; The highlighted active line remains visible until the last items,=
 than the active line becomes invisible<br>
&gt;<br>
&gt; Thanks.<br>
&gt;<br>
&gt; It looks like the code in icomplete--render-vertical implicitly<br>
&gt; assumes that every candidate takes just one screen line, which is<br>
&gt; false in your scenario.=C2=A0 A workaround is to set truncate-lines no=
n-nil<br>
&gt; in the minibuffer.<br>
&gt;<br>
&gt; Jo=C3=A3o, can you take a look, please?<br>
<br>
I&#39;ll take a better look later, but I can say that that truncate-lines<b=
r>
idea sounds very sensible.=C2=A0 Johann can you try this patch?<br>
<br>
diff --git a/lisp/icomplete.el b/lisp/icomplete.el<br>
index 014f38b2024..4e85e20fddb 100644<br>
--- a/lisp/icomplete.el<br>
+++ b/lisp/icomplete.el<br>
@@ -644,6 +644,7 @@ icomplete--vertical-minibuffer-setup<br>
=C2=A0 =C2=A0(setq-local icomplete-hide-common-prefix nil<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; Ask `icomplete-co=
mpletions&#39; to return enough<br>
completions candidates.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0icomplete-prospects-=
height 25<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 truncate-lines t<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0redisplay-adhoc-scro=
ll-in-resize-mini-windows nil))<br>
<br>
=C2=A0;;;###autoload<br>
</blockquote></div>

--000000000000be2cbd05f5e9daad--

Last modified: Thu, 2 Mar 2023 12:30:02 UTC

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