GNU bug report logs - #29805
27.0; doc of `tooltip-resize-echo-area'

Previous Next

Full log

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "stefan <at> marxist.se" <stefan <at> marxist.se>,
 "29805 <at> debbugs.gnu.org" <29805 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#29805: 27.0; doc of `tooltip-resize-echo-area'
Date: Sat, 23 Oct 2021 19:50:27 +0000

> > A standalone "minibuffer" frame also manifests the
> > echo area
> 
> No, it doesn't.  It serves as the minibuffer window,
> but it isn't the echo-area.

(No one said it "is" the echo area.  And no one but
you has said that such a frame is, or "serves as",
a window.)

Where do you think the echo area is manifested, if
you have a minibuffer-only frame and no other frame
has a minibuffer?

Bingo - that's what we're talking about.  That's the
(most common, and probably the only) use case of a
standalone minibuffer frame - it provides THE
mini-window.

The echo area always uses the same real estate as a
minibuffer.  If the only minibuffer is standalone
then - guess what - that's where the echo are is, in
that standalone "minibuffer" frame.

> > Doc that tells you the echo area gets resized to show
> > all of the message text should also tell you that this
> > doesn't apply - the ECHO AREA is not resized - if the
> > echo area is the only thing in its frame (a so-called
> > minibuffer-only, or standalone-minibuffer, frame).
> 
> It makes no sense to talk about resizing the minibuffer-only frame,
> because it has more than one line to begin with.

Nonsense.  It has whatever number of lines it's
configured to have.  See `minibuffer-frame-alist'.

Previous Next

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