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

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

[Drew Adams]

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'

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

[martin rudalics]

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

I believe we also nowhere say that we do not resize minibuffer/echo
areas on stand-alone minibuffer frames.  So the question to be
answered first is: Do we ever want to fit stand-alone minibuffer
frames to their buffers?  If so, then we can decide whether we want
`tooltip-resize-echo-area' to affect resizing stand-alone minibuffer
frames as well and probably also whether showing a tooltip should
autoraise the minibuffer frame.

But the first question that comes to my mind is why we now have the
option `tooltip-resize-echo-area' which, according to its doc-string
"has effect only on GUI frames" while in Emacs 24.1 we have declared
`tooltip-use-echo-area' obsolete and suggested to disable tooltips
instead.  Resolved that, we should probably then also say that
`tooltip-resize-echo-area' has effect iff `resize-mini-windows' is
non-nil.

martin

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

[Drew Adams]

>  > 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..
> 
> I believe we also nowhere say that we do not resize minibuffer/echo
> areas on stand-alone minibuffer frames.

I believe so too.

> So the question to be
> answered first is: Do we ever want to fit stand-alone minibuffer
> frames to their buffers?

Please don't bother for me, anyway. ;-)

> If so, then we can decide whether we want
> `tooltip-resize-echo-area' to affect resizing stand-alone minibuffer
> frames as well and probably also whether showing a tooltip should
> autoraise the minibuffer frame.

Again, speaking for myself, I don't need any of that.

The bug report was really to suggest that such doc about
resizing the space for the minibuffer / echo area should
not lead people to believe that such resizing resizes a
frame.  It applies only to a window in a frame that is
not minibuffer-only (AFAICT), so that should be made clear.

> But the first question that comes to my mind is why we now have the
> option `tooltip-resize-echo-area' which, according to its doc-string
> "has effect only on GUI frames" while in Emacs 24.1 we have declared
> `tooltip-use-echo-area' obsolete and suggested to disable tooltips
> instead.

1. No idea why we now have it.
2. The doc string is wrong to refer to `tooltip-use-echo-area'.

> Resolved that, we should probably then also say that
> `tooltip-resize-echo-area' has effect iff `resize-mini-windows' is
> non-nil.

And why isn't `resize-mini-windows' enough?  Is this about
resizing ONLY the echo area and not the minibuffer?  (Does
that even make sense?)

It's all unclear to me.

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

[martin rudalics]

 >> So the question to be
 >> answered first is: Do we ever want to fit stand-alone minibuffer
 >> frames to their buffers?
 >
 > Please don't bother for me, anyway. ;-)

If we don't want to, the entire remainder of this discussion is moot.

 > The bug report was really to suggest that such doc about
 > resizing the space for the minibuffer / echo area should
 > not lead people to believe that such resizing resizes a
 > frame.  It applies only to a window in a frame that is
 > not minibuffer-only (AFAICT), so that should be made clear.

Resizing the echo area when showing a tooltip is just a special case
of resizing the minibuffer window so any reasonable discussion of the
former would have to start with the latter.

 >> But the first question that comes to my mind is why we now have the
 >> option `tooltip-resize-echo-area' which, according to its doc-string
 >> "has effect only on GUI frames" while in Emacs 24.1 we have declared
 >> `tooltip-use-echo-area' obsolete and suggested to disable tooltips
 >> instead.
 >
 > 1. No idea why we now have it.
 > 2. The doc string is wrong to refer to `tooltip-use-echo-area'.

Which doc string does (2)?

 >> Resolved that, we should probably then also say that
 >> `tooltip-resize-echo-area' has effect iff `resize-mini-windows' is
 >> non-nil.
 >
 > And why isn't `resize-mini-windows' enough?  Is this about
 > resizing ONLY the echo area and not the minibuffer?  (Does
 > that even make sense?)
 >
 > It's all unclear to me.

To me too.  I have no idea why we (or at least an Emacs user) should
ever have to distinguish betweeen echo area and minibuffer.  There's
no practical need for that.

martin

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

[Drew Adams]

>  >> So the question to be
>  >> answered first is: Do we ever want to fit stand-alone minibuffer
>  >> frames to their buffers?
>  >
>  > Please don't bother for me, anyway. ;-)
> 
> If we don't want to, the entire remainder of this discussion is moot.

I can't speak to what you are discussing, but if "this
discussion" means this bug report, then I don't think
it is moot.

This is the point:

>  > The bug report was really to suggest that such doc about
>  > resizing the space for the minibuffer / echo area should
>  > not lead people to believe that such resizing resizes a
>  > frame.  It applies only to a window in a frame that is
>  > not minibuffer-only (AFAICT), so that should be made clear.

> Resizing the echo area when showing a tooltip is just a special case
> of resizing the minibuffer window so any reasonable discussion of the
> former would have to start with the latter.

I'm not sure what you're arguing (or why you are arguing).
Since minibuffer and echo area share the same real estate,
of course any talk of resizing that real estate can involve
either minibuffer or echo area (depending whether the
resizing affects input or output) - or both.  But so what?

This bug is not about whether or when there should or
should not be resizing.  It is about the doc, which
can (so far) give the impression that this resizing
affects this real estate even when a standalone frame
is involved - which it does not, AFAIK.

>  >> But the first question that comes to my mind is why we now have the
>  >> option `tooltip-resize-echo-area' which, according to its doc-string
>  >> "has effect only on GUI frames" while in Emacs 24.1 we have declared
>  >> `tooltip-use-echo-area' obsolete and suggested to disable tooltips
>  >> instead.
>  >
>  > 1. No idea why we now have it.
>  > 2. The doc string is wrong to refer to `tooltip-use-echo-area'.
> 
> Which doc string does (2)?

#2 was a mistake on my part.

I don't know why we now have this new option.  But
that's not what this bug report is about.

Clearly, if you decide that we should not add this
option then this bug can be closed.  But that question
is really separate.  I can't speak to it; perhaps
someone else can.

But if you and whoever decide to keep this new option
then please look into this doc bug.  That's all.

As for why Emacs might want to provide such an option
(note: I'm not requesting such an option): As the entry
in NEWS says: to avoid truncating help text (it says
"tooltip text") in the echo area.

It's not clear to me, but I get the impression that
you might be thinking that just because option
`tooltip-use-echo-area' is obsolete tooltip/help
text is no longer displayed in the echo area.

That's not the case at all.  I (and many others, I
imagine) turn off `tooltip-mode' so that such text
is shown in the echo area.  It is not such display
that was made obsolete; it is only option
`tooltip-use-echo-area' that is obsolete.

So I can understand why someone might have added
this option.  But as I say, I'm not arguing for
or against having this new option.  My point is
that its doc should not let users mistakenly get
the impression that this option has some effect
in the case of a standalone minibuffer frame.

As for whether option `resize-mini-windows' should
be sufficient to cover this: I can't speak to that.
Presumably someone wanted to be able to resize the
echo area (output) without also resizing the
minibuffer (input)?

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

[martin rudalics]

 > This bug is not about whether or when there should or
 > should not be resizing.  It is about the doc, which
 > can (so far) give the impression that this resizing
 > affects this real estate even when a standalone frame
 > is involved - which it does not, AFAIK.

Any such resizing is governed by the setting of `resize-mini-windows'
and whether the echo area can be resized at all.  There are various
reasons why the echo area can't be resized - for example, when the
root window has fixed size, when the echo area occupies the only
window on its frame or when the frame is too small.  Maybe there are
more.  So the standalone frame case is just one among others.

But this is just my POV of this matter.  As should be clear from my
previous remarks in this thread, I apparently do not understand the
use of the echo area for showing tooltips and neither the difference
between echo area and minibuffer.  So I'll rather leave this for the
inventor of `tooltip-resize-echo-area' to fix.

martin

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

[Stefan Kangas]

martin rudalics <rudalics@gmx.at> writes:

>> This bug is not about whether or when there should or
>> should not be resizing.  It is about the doc, which
>> can (so far) give the impression that this resizing
>> affects this real estate even when a standalone frame
>> is involved - which it does not, AFAIK.
>
> Any such resizing is governed by the setting of `resize-mini-windows'
> and whether the echo area can be resized at all.  There are various
> reasons why the echo area can't be resized - for example, when the
> root window has fixed size, when the echo area occupies the only
> window on its frame or when the frame is too small.  Maybe there are
> more.  So the standalone frame case is just one among others.
>
> But this is just my POV of this matter.  As should be clear from my
> previous remarks in this thread, I apparently do not understand the
> use of the echo area for showing tooltips and neither the difference
> between echo area and minibuffer.  So I'll rather leave this for the
> inventor of `tooltip-resize-echo-area' to fix.

Eli, I guess that unnamed inventor is you.  Perhaps you could take a
look at the above and see what you think.

commit 9b3ce6252115980802adaa562af575bcd73a2c55
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Sat Oct 7 15:04:37 2017 +0300

    New defcustom 'tooltip-resize-echo-area'

    * lisp/tooltip.el (tooltip-resize-echo-area): New defcustom.
    (tooltip-show-help-non-mode): Use it to avoid truncating the
    tooltip text in the echo area.  (Bug#28724)

    * etc/NEWS: Mention 'tooltip-resize-echo-area'.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 23 Oct 2021 10:48:00 -0700
> Cc: 29805@debbugs.gnu.org
> 
> > But this is just my POV of this matter.  As should be clear from my
> > previous remarks in this thread, I apparently do not understand the
> > use of the echo area for showing tooltips and neither the difference
> > between echo area and minibuffer.  So I'll rather leave this for the
> > inventor of `tooltip-resize-echo-area' to fix.
> 
> Eli, I guess that unnamed inventor is you.  Perhaps you could take a
> look at the above and see what you think.
> 
> commit 9b3ce6252115980802adaa562af575bcd73a2c55
> Author: Eli Zaretskii <eliz@gnu.org>
> Date:   Sat Oct 7 15:04:37 2017 +0300
> 
>     New defcustom 'tooltip-resize-echo-area'
> 
>     * lisp/tooltip.el (tooltip-resize-echo-area): New defcustom.
>     (tooltip-show-help-non-mode): Use it to avoid truncating the
>     tooltip text in the echo area.  (Bug#28724)

What is unclear about it?  Drew thinks the doc string should say
something about stand-alone minibuffer frames, but only Drew can
explain why.  The doc string talks specifically about the echo-area,
and about the situation where tooltips are shown in the echo-area; it
says nothing about minibuffers or minibuffer-only frames.

bug#29805: [External] : bug#29805: 27.0; doc of `tooltip-resize-echo-area'

[Drew Adams]

> What is unclear about it?  Drew thinks the doc string should say
> something about stand-alone minibuffer frames, but only Drew can
> explain why.  The doc string talks specifically about the echo-area,
> and about the situation where tooltips are shown in the echo-area; it
> says nothing about minibuffers or minibuffer-only frames.

Yes, it's about the echo area - only; not minibuffers.

As both I and Martin pointed out, resizing the echo area
means resizing the minibuffer area - same real estate.

The doc says that the echo area gets resized.  That
effect doesn't occur with a "minibuffer-only" frame.
The doc would be clearer if it said so.

Such a frame is as much "echo-area-only" as it is
"minibuffer-only".  A standalone "minibuffer" frame
also manifests the echo area - it's a frame for the
minibuffer AND the echo area.

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

Saying that the doc shouldn't be fixed because it's
about the echo area and not about the minibuffer is
a deflection.  No one is saying that it's about the
minibuffer.

It's a minor bug.  But it should at least be obvious
what the (doc) problem is.

bug#29805: [External] : bug#29805: 27.0; doc of `tooltip-resize-echo-area'

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "29805@debbugs.gnu.org" <29805@debbugs.gnu.org>
> Date: Sat, 23 Oct 2021 18:51:29 +0000
> 
> The doc says that the echo area gets resized.  That
> effect doesn't occur with a "minibuffer-only" frame.

The effect only happens when the echo-area displays something that is
longer than a single screen line.  Is something being shown in the
echo-area of your minibuffer-only frame?

> Such a frame is as much "echo-area-only" as it is
> "minibuffer-only".

No, it isn't.  The name "echo-area" is reserved to the mini-window,
see Glossary.

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

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

> It's a minor bug.

It's not a bug at all.  It should be closed.

bug#29805: [External] : bug#29805: 27.0; doc of `tooltip-resize-echo-area'

[Drew Adams]

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

bug#29805: [External] : bug#29805: 27.0; doc of `tooltip-resize-echo-area'

[Eli Zaretskii]

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

bug#29805: [External] : bug#29805: 27.0; doc of `tooltip-resize-echo-area'

[Drew Adams]

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

So where do you think those message we see in that
frame are?  Do you think they're in the minibuffer?
(They're not, as is easily checked.)

> > > 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'.
> 
> Thank you, this is my final clue that this discussion
> goes nowhere, as it happens so frequently with you.

Do you disagree that the minibuffer frame can have any
number of lines?  Do you still claim that it must have
more than one line?  Do you still claim that there's
no echo area in such a frame, so there's no echo area
anywhere, if no other frame has a minibuffer?  Have
you even tried Emacs with only one frame that has a
minibuffer - a minibuffer-only frame?

> Bug closed.

Feel better now?