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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <ghe <at> sdf.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: Wed, 23 Sep 2020 17:34:13 +0300

> Date: Wed, 23 Sep 2020 07:15:15 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
> cc: monnier <at> iro.umontreal.ca, 43519 <at> debbugs.gnu.org
> 
> > 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.

But the changes you proposed didn't distinguish between the completion
use case and the other use cases.  resize_mini_window is used for any
display of the mini-window` that includes alls displays of the
minibuffer and also the display of the echo area.  The changes you
proposed will affect all of them, because they don't distinguish
between them.

> 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.

The change I installed either improves on the current behavior or
keeps the current behavior in the more complex cases, and improves the
behavior in the simple case that started this bug report.

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

Coming up.

Previous Next

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