GNU bug report logs - #67715
28.2; Minibuffer content is sometimes unexpectedly partially hidden

Previous Next

Package: emacs;

Reported by: Markus Triska <triska <at> metalevel.at>

Date: Fri, 8 Dec 2023 19:05:02 UTC

Severity: normal

Tags: wontfix

Found in version 28.2

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 67715 <at> debbugs.gnu.org
Subject: Re: bug#67715: 28.2;
 Minibuffer content is sometimes unexpectedly partially hidden
Date: Sat, 09 Dec 2023 09:59:14 +0200
> From: Markus Triska <triska <at> metalevel.at>
> Cc: 67715 <at> debbugs.gnu.org
> Date: Sat, 09 Dec 2023 08:04:40 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Why did you expect the mini-window to resize in this case?
> 
> The Emacs Lisp documentation states in section 21.1:
> 
>     The minibuffer’s window is normally a single line; it grows
>     automatically if the contents require more space.

As I said, this is currently limited to showing echo-area messages and
prompts for the user to type some input.  The text above didn't
imagine someone will want to use the mini-window as a normal window
and just insert there some arbitrary text.

> I added (fit-window-to-buffer) after inserting the text, and still the
> text is not fully visible. fit-window-to-buffer is documented as:
> 
>     Adjust size of WINDOW to display its buffer’s contents exactly.
> 
> I would greatly prefer if Emacs works as documented. Should I file a
> separate issue for this, or is this also a case of wontfix? Is there any
> way to solve the issue?

I don't know.  You haven't actually explained what you are trying to
accomplish and why you use this strange way of accomplishing it.  Why
not, for example, use the minibuffer-prompt face instead to show the
prompt in a different typeface?

But yes, it is possible that we will not want to fix that, since the
change was to solve a more serious issue, and I don't see how these
two issues could be reconciled given the way redisplay currently
works.

The basic technical reason for what you see is that redisplay is
inhibited when with-selected-window returns and restores the selected
window, which is in your case the opportunity to resize the
mini-window.  When redisplay is inhibited, the code which resizes the
mini-window returns without doing anything.  So one way of fixing this
would be to try to avoid with-selected-window, and instead use some
other way of achieving what you want to do.




This bug report was last modified 158 days ago.

Previous Next


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