GNU bug report logs - #47860
28.0.50; Mini buffer resize when lines are truncated regression

Previous Next

Full log

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

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47860 <at> debbugs.gnu.org, Gregory Heytings <gregory <at> heytings.org>
Subject: Re: bug#47860: 28.0.50;
 Mini buffer resize when lines are truncated regression
Date: Mon, 19 Apr 2021 09:02:24 -0500

 On Mon, Apr 19, 2021 at 8:10 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Date: Mon, 19 Apr 2021 12:40:12 +0000
> > From: Gregory Heytings <gregory <at> heytings.org>
> > cc: Eli Zaretskii <eliz <at> gnu.org>, 47860 <at> debbugs.gnu.org
> >
> > Thanks.  But what do you expect this code to do?  I tested it, and for
> > Emacs 24 to 27 you see only "a" in the minibuffer.  After commit
> > 56c42bd28d, you see two lines, "a" and "bbb...".
>
> Exactly the questions to which I would like to know the answers,
> thanks.
>
> IOW, given that the current code does "somewhat" better than
> everything we had before, what exactly is the problem you (Aaron) see
> with the offending commit that you call it "regression"?

I have not tested with Emacs 27. I have, however, tested with Emacs 28
with and without the commit I mentioned.

With the commit reverted, I see this:

https://cln.sh/sNpBcb

Without it reverted, I see this:

https://cln.sh/RtPEie

What I expect is for the minibuffer to be sized as the first example
and not the second.

I have not tested my repro on Emacs 27, so it's interesting to hear
that only the first line is displayed. However,

This is what it looks like when using selectrum in Emacs 27:

https://user-images.githubusercontent.com/8199224/114367956-3f4a8e00-9b7d-11eb-8307-5372fb48de63.png

and Emacs 28:

https://user-images.githubusercontent.com/8588/114411541-e1fd0f80-9b71-11eb-8ba3-5bf1437a7806.png

In Emacs 28, the minibuffer is not resized to be large enough to see
all candidates. It also never scrolls, so it's difficult to pick any
candidate that is not visible.

I do know that Selectrum does some vertical resizing after adding text
to the minibuffer, so that may be what causes Emacs 27 to look right.
It may also be that that vertical resizing now fails in Emacs 28 for
some reason. I did not need the resizing code to reproduce what
appears to be *an* issue, but it could very well not be the exact
issue I'm seeing in Selectrum if it is indeed the resizing code that's
not working properly.

I'll spend a little time adding the resize code in and testing in
Emacs 27 to see if that helps narrow down to the exact issue I'm
seeing on selectrum.

Thanks,

Aaron

Previous Next

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