all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: emacs-devel@gnu.org
Subject: Re: Selecting tooltip frames considered harmful
Date: Mon, 26 Feb 2018 10:06:21 +0100	[thread overview]
Message-ID: <5A93CE0D.4050308@gmx.at> (raw)
In-Reply-To: <jwvlgfg4fu2.fsf-monnier+Inbox@gnu.org>

 >> The obvious candidate here is the minibuffer window of tip_last_frame
 >> (making sure the tooltip frame gets deleted when tip_last_frame is
 >> deleted).
 >
 > I was rather thinking of the selected-window at the time the tooltip
 > frame is created

A minibuffer or echo area window is specified frame-wise and is found
in the minibuffer_window slot of each frame.  So you probably mean the
mini window for the frame of the window selected at the time the
tooltip frame is created.  That window is in fact the mini window of
tip_last_frame.

 > (plus some way to re-set the "transient-for" field so
 > the same tooltip-frame can be reused?).

The same tooltip-frame (and its buffer and window) can be already
reused.  So what does the "transient-for" field stand for?

 > First we need to decide what's The Right Thing, and I think that keeping
 > track of the "parent" frame/window is the right thing.
 >
 > Once we agree on this, we can think about how best to
 > implement/approximate it.

We currently refuse to delete a frame when its minibuffer window
serves as the minibuffer window of another frame.  Since this sounds
like a bad idea in the context of tooltips, we probably would have to
delete a tooltip frame before deleting the frame whose minibuffer
serves as the surrogate for the tooltip.

So yes, we have to agree on what TRT is.  Either insist on all frames
having a minibuffer frame (or producing one on demand) or disallow
selecting frames which don't.

martin



  reply	other threads:[~2018-02-26  9:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-24  9:52 Selecting tooltip frames considered harmful martin rudalics
2018-02-24 10:41 ` Eli Zaretskii
2018-02-25 19:08   ` martin rudalics
2018-02-25 19:55     ` Eli Zaretskii
2018-02-26  9:05       ` martin rudalics
2018-02-26 15:50         ` Eli Zaretskii
2018-02-26 18:54           ` martin rudalics
2018-02-26 19:31             ` Eli Zaretskii
2018-02-27  2:57               ` Stefan Monnier
2018-02-25 13:33 ` Stefan Monnier
2018-02-25 19:08   ` martin rudalics
2018-02-26  3:02     ` Stefan Monnier
2018-02-26  9:06       ` martin rudalics [this message]
2018-02-26 13:21         ` Stefan Monnier
2018-02-26 18:54           ` martin rudalics

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

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

  git send-email \
    --in-reply-to=5A93CE0D.4050308@gmx.at \
    --to=rudalics@gmx.at \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.