unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: martin rudalics <rudalics@gmx.at>, 29805@debbugs.gnu.org
Subject: bug#29805: 27.0; doc of `tooltip-resize-echo-area'
Date: Sat, 23 Dec 2017 07:20:28 -0800 (PST)	[thread overview]
Message-ID: <dc7ae3de-0f0e-4e51-a398-f6c905458a21@default> (raw)
In-Reply-To: <5A3E14EC.3010809@gmx.at>

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





  reply	other threads:[~2017-12-23 15:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-21 22:06 bug#29805: 27.0; doc of `tooltip-resize-echo-area' Drew Adams
2017-12-22 17:57 ` martin rudalics
2017-12-22 18:44   ` Drew Adams
2017-12-23  8:33     ` martin rudalics
2017-12-23 15:20       ` Drew Adams [this message]
2017-12-23 19:07         ` martin rudalics
2021-10-23 17:48           ` Stefan Kangas
2021-10-23 18:08             ` Eli Zaretskii
2021-10-23 18:51               ` bug#29805: [External] : " Drew Adams
2021-10-23 19:23                 ` Eli Zaretskii
2021-10-23 19:50                   ` Drew Adams
2021-10-24  5:52                     ` Eli Zaretskii
2021-10-24 20:45                       ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dc7ae3de-0f0e-4e51-a398-f6c905458a21@default \
    --to=drew.adams@oracle.com \
    --cc=29805@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).