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

Previous Next

Full log

View this message in rfc822 format

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: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Date: Wed, 23 Sep 2020 07:15:15 +0000

>> You explained that my proposal was unacceptable because a change with 
>> which no completion candidates are displayed where completion 
>> candidates would have been displayed without the change, is 
>> unacceptable.
>
> This is a misunderstanding: I was talking about the cases where the text 
> in the mini-window comes from buffer text, not from an overlay. The 
> simplest example of what I was talking about is what 'message' does when 
> it shows a very long message, too long to show in the mini-window in its 
> entirety.  In that case, Emacs after the change still behaves as I 
> described: it shows the last portion of the text.
>

I don't understand how you came to think about something like this.  All 
examples I gave (and the example with which this bug thread started) were 
about completion candidates displayed at EOB with an overlay, and I 
mentioned icomplete and ido several times.  I never claimed that in the 
case you mention the display should start at BOB.

>> In general I don't know, but for the usecase with which this bug 
>> started (namely displaying completion candidates after point with an 
>> overlay), the answer is clearly and definitely no.  The best solution 
>> is not to fit the stuff to be displayed to the dimensions of the 
>> mini-window, the best solution is to put a too large overlay at EOB and 
>> request that the display starts at BOB (and not at BOL as your change 
>> does, because this means that the prompt and user input so far can 
>> disappear, which is counter-intuitive).
>
> In the simplest case, where there's a single overlay string at EOB, 
> these two are identical.
>

In the simplest case they are, in more complex cases they are not.  And 
I'm proposing a solution that would work in all cases, not just in the 
simplest ones.

Let's continue this discussion in bug#43572, where I eagerly wait for your 
comments.

Previous Next

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