From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Johann =?UTF-8?Q?H=C3=B6chtl?= Newsgroups: gmane.emacs.bugs Subject: bug#61702: Minibuffer scrolling not working when long lines get truncated Date: Thu, 23 Feb 2023 08:12:09 +0100 Message-ID: References: <83h6vdswnr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d2979605f558bbf7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32774"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61702@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 23 08:13:21 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pV5n6-0008Nc-Rk for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Feb 2023 08:13:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pV5mo-0006Vh-Vt; Thu, 23 Feb 2023 02:13:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pV5mo-0006VN-7Y for bug-gnu-emacs@gnu.org; Thu, 23 Feb 2023 02:13:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pV5mn-0004oZ-VT for bug-gnu-emacs@gnu.org; Thu, 23 Feb 2023 02:13:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pV5mn-0006pn-IE for bug-gnu-emacs@gnu.org; Thu, 23 Feb 2023 02:13:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Johann =?UTF-8?Q?H=C3=B6chtl?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Feb 2023 07:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61702 X-GNU-PR-Package: emacs Original-Received: via spool by 61702-submit@debbugs.gnu.org id=B61702.167713634826228 (code B ref 61702); Thu, 23 Feb 2023 07:13:01 +0000 Original-Received: (at 61702) by debbugs.gnu.org; 23 Feb 2023 07:12:28 +0000 Original-Received: from localhost ([127.0.0.1]:32808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pV5mG-0006ox-2j for submit@debbugs.gnu.org; Thu, 23 Feb 2023 02:12:28 -0500 Original-Received: from mail-oi1-f182.google.com ([209.85.167.182]:35833) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pV5mE-0006om-N2 for 61702@debbugs.gnu.org; Thu, 23 Feb 2023 02:12:27 -0500 Original-Received: by mail-oi1-f182.google.com with SMTP id c11so11981091oiw.2 for <61702@debbugs.gnu.org>; Wed, 22 Feb 2023 23:12:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=alFo7jElYLRHgSgOQG4c8X1xg2pTD3eCUpfst0tMrCE=; b=OhBIvwTnVzBifE6zuJJ54K632sPKHAueZkccePmLYgyw168UBH5ozOxnQ35B9UtEB/ OzntkBfOLskgLcjuhAOzzy9Oilcs5qz/81DtPrZoQT9mA0nRVp6Mo9WV3JtJTa4DbZ6+ 41U59JK7LZN8xjLWf9xCTa8HeqS/AdcKNmYxV3Tp8/qjfEdk7S/Jg3t5YQb/S0XhGkYC iuGARm0C6kx+4W+qZjYxVOgQwmYohRWY9s1m2BomBnjvkZXHpJM2S1BCZkRwES3gousL XRaP+cQbaMARaRX50PsSkTXGBzFS8DcbVjwy44sPh6FSJZrjnEkii8ogYHgfQEC3xa+k kNrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=alFo7jElYLRHgSgOQG4c8X1xg2pTD3eCUpfst0tMrCE=; b=g07a1f7i90o7aSJWhjialrAJJjZWDgqra2t3srNgtXjrx3HDKPAUfxExUU3H1qFrCM QqJhD8obQbtTPzJ8Mjt11EKfp0Kyr6VgDevhuwDc4pR76dOfOqonqp7cRfKqZuhL1MxJ hGYncQgZ/ZQHVOAPam/Jd6nKsNzFIt8WamEtJRbeNkXfWxf7Y6bRLZQZ/iB/rHQ56ntz MoxVdTPjALhzksPLNUsMplFO46pLZ8rWy6GsHy5ij6UCSSXsXzDZRlPofK4e39eCbuIj Njhjp2dhplse/Nwhw4L7Ba6fCQwAVWberDERHTVNxdwTULGSQjOvnAEb6S9C095CLYgx zpNw== X-Gm-Message-State: AO0yUKWfW+zZXikYkc2SoIBJRp2rB/6ATZnXbAOp6OXyP0SYrqHuO7rZ 5yXA1kvYdzZUCVjninEGUyENE6UvLYoReo19iA== X-Google-Smtp-Source: AK7set/TAG+RRyz9gcOqOQ9rc+PcYp6pEP2t2WZOi68mDLQGWMrJ6cTRVXr6aJWatus/BHFYecDwl/EK4wQ/nrR8NYo= X-Received: by 2002:a05:6808:2112:b0:378:594:2c76 with SMTP id r18-20020a056808211200b0037805942c76mr1914588oiw.274.1677136340619; Wed, 22 Feb 2023 23:12:20 -0800 (PST) In-Reply-To: <83h6vdswnr.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:256423 Archived-At: --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 <-- 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 ... 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 : > > From: Johann H=C3=B6chtl > > 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 > or the indicator correctly > > displays the number of the item I am supposed to choose when pressing > 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
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 n= arrow down the potential completions, in this case 12 items remain matching=
narrow the=C2=A0whole emacs window so the search results have to= "break" because of long lines
<down> <down>= ; ...=C2=A0
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=C2=A0= Uhr schrieb Eli Zaretskii <eliz@gnu.org<= /a>>:
> Fr= om: Johann H=C3=B6chtl <johann.hoechtl@gmail.com>
> Date: Wed, 22 Feb 2023 07:59:04 +0100
>
> I experience the following annoying behavior: If the text in the minib= uffer get's longer than the display width
> and lines are therefore continued on the next line, the minibuffer scr= olling no longer works.
>
> What I mean by that is that it "logically" works as when I p= ress <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).=C2=A0 This will make sure we see and investigate the same issue that you are experiencing, and will prevent misunderstandings.

TIA
--000000000000d2979605f558bbf7--