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: Mon, 21 Sep 2020 16:27:51 +0000

>> Perhaps I misunderstood something, but for me "start the display at the 
>> beginning of the screen line where we end up after 
>> move_it_vertically_backward" would mean that if the prompt and the user 
>> input so far needs more than one line, only the last line would be 
>> displayed.  So instead of having, say,
>>
>> Find file: <user input>
>> <user input>|
>> <completion candidates>
>>
>> (where | represents the cursor) we would only have:
>>
>> <user input>|
>> <completion candidates>
>
> Yes.
>
> This bug was filed to request that Emacs behaves with overlay-string in 
> the minibuffer prompt the same as with regular buffer text.
>

Hmmm...  no, this bug was filed after a discussion on emacs-devel (about 
implementing vertical icomplete), and the problem is clearly stated by 
Stefan: the prompt and user input so far disappear.

>
> What I propose will do that, or as close as possible to it.  By 
> contrast, you seem to suggest a change in the current behavior for 
> buffer text as well.
>

Which is why my proposal is to not break anything, but only to give 
applications the control of how what they insert in the minibuffer is 
displayed.  A start_display_at_beginning_of_minibuffer variable that would 
be reset in read_minibuf() and that an application could set in 
minibuffer-setup-hook.  I don't understand why you would be opposed to 
such a change.

>
> That may or may not be a good idea, but it's a separate issue, so should 
> be discussed separately
>

It's _not_ a separate issue, it's the issue at hand.

>
> (and in that separate discussion I will generally be opposed to the 
> change you are proposing, because we had the current behavior for many 
> years, and so changes like the one you propose run serious risk of 
> breaking expectations of some package out there).
>

Why would a change that does not change Emacs' behavior in any way except 
if the user requests it "run serious risk of breaking expectations of some 
package out there"?  It only gives application writers the freedom to 
decide what Emacs should do, which is IMO a good thing in general.

Previous Next

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