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