GNU bug report logs - #43519
28.0.50; Overlay at end of minibuf hides minibuf's real content

Previous Next

Full log

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

From: Gregory Heytings <ghe <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 43519 <at> debbugs.gnu.org
Subject: Re: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's
 real content
Date: Mon, 21 Sep 2020 16:00:01 +0000

>>> The solution I proposed in my other message (assuming that it is 
>>> accepted) is more general, I think.
>>
>> If you mean "to start the display at the beginning of the screen line 
>> where we end up after move_it_vertically_backward returns", it is IMO 
>> worse.
>
> I think you misunderstand my proposal, because the beginning of the 
> screen line where we end up in the use case we are discussing is the 
> BOB.
>

I'm not sure they are, but I'm not an expert.  If they are, then of course 
your proposal would be okay.

The purpose of the discussion (AFAIU) is to introduce a change to make it 
possible for icomplete/ido/... to put a too long overlay at EOB (with say 
two or three more candidates than can be displayed in the mini-window), in 
such a way that the prompt will always be displayed, and the last part of 
the overlay will not.  What happens with your proposal when 
max-mini-window-height is 10, and the overlay needs 13 lines?  What 
happens when max-mini-window-height, the overlay needs 10 lines, and the 
prompt and user input so far need two lines?

Previous Next

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