emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29805: closed (27.0; doc of `tooltip-resize-echo-area')


From: GNU bug Tracking System
Subject: bug#29805: closed (27.0; doc of `tooltip-resize-echo-area')
Date: Sun, 24 Oct 2021 05:53:02 +0000

Your message dated Sun, 24 Oct 2021 08:52:35 +0300
with message-id <83k0i33r6k.fsf@gnu.org>
and subject line Re: [External] : bug#29805: 27.0; doc of 
`tooltip-resize-echo-area'
has caused the debbugs.gnu.org bug report #29805,
regarding 27.0; doc of `tooltip-resize-echo-area'
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
29805: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29805
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 27.0; doc of `tooltip-resize-echo-area' Date: Thu, 21 Dec 2017 14:06:00 -0800 (PST)
I don't see where this resizing is done (by grepping Lisp sources), so I
suppose it is done in C.

In any case, it seems to have no effect, AFAICT, on a standalone
minibuffer frame (i.e., on an echo area in such a frame).  The doc says
nothing about this..



In GNU Emacs 27.0.50 (build 4, x86_64-w64-mingw32)
 of 2017-12-21
Repository revision: b1cf262a79463f28164ea1c2ffee3c657ce02ea4
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install -C 'CFLAGS=-O2 -static -g3'
 host_alias=x86_64-w64-mingw32 PKG_CONFIG_PATH=/mingw64/lib/pkgconfig'



--- End Message ---
--- Begin Message --- Subject: Re: [External] : bug#29805: 27.0; doc of `tooltip-resize-echo-area' Date: Sun, 24 Oct 2021 08:52:35 +0300
> From: Drew Adams <drew.adams@oracle.com>
> CC: "stefan@marxist.se" <stefan@marxist.se>,
>         "29805@debbugs.gnu.org"
>       <29805@debbugs.gnu.org>
> Date: Sat, 23 Oct 2021 19:50:27 +0000
> 
> Where do you think the echo area is manifested, if
> you have a minibuffer-only frame and no other frame
> has a minibuffer?

Nowhere.

> > It makes no sense to talk about resizing the minibuffer-only frame,
> > because it has more than one line to begin with.
> 
> Nonsense.

Thank you, this is my final clue that this discussion goes nowhere, as
it happens so frequently with you.

Bug closed.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]