From: "Drew Adams" <drew.adams@oracle.com>
To: <emacs-devel@gnu.org>
Subject: test for a (really) visible frame? test if a frame is the only (really visible) one?
Date: Tue, 2 Mar 2010 10:29:48 -0800 [thread overview]
Message-ID: <C6ADAF21677F4942B2D6C6BCC0A0A110@us.oracle.com> (raw)
IIUC (please correct any misconceptions - consider these as questions):
1. Every terminal frame is considered visible, always, whether or not you can
see it currently.
2. `visible-frame-list' (and `frame-visible-p') can include not only frames that
you actually see but also (terminal) frames that you cannot see.
3. `emacs --daemon' adds an extra terminal frame named (usually? always?) `F1'
that is not (necessarily? ever?) visible to the eye, but is considered visible
by Emacs (since it is a terminal frame).
It seems that it is _never_ visible to the eye: If you delete (only) the other
visible frames, then you can no longer see any frames at all.
4. It is impossible to test whether a given frame is a terminal frame. There is
no predicate for this and no frame parameter that indicates this.
5. It is impossible to test whether a given frame is a/the hidden-to-the-eye
(but "visible") frame that is used only to implement `--daemon'.
6. It is impossible to test whether a given frame is the sole frame visible to
the eye.
One could try to test #6 using (cdr (visible-frame-list)), but that will
apparently never be nil if `--daemon' is used, because of the extra,
under-the-covers frame, F1.
One could try to test whether, if `visible-frame-list' is a doubleton, the
second (or is it sometimes the first?) frame has the name "F1", to try to handle
the `--daemon' case. But that's fragile. Anyone could name any frame "F1" - the
name is not a reliable indication of the kind of frame it is.
[Caveat: I haven't tested any of the `--daemon' stuff myself, since I'm using
Windows, and AFAIK `--daemon' isn't supported on Windows. This is my
understanding based on hearing from others and reading the doc.]
---
Request: If the above are correct, could we please have some way to effect the
tests #4, #5, and #6?
Simple use case: Define a function to delete the selected window or, if only one
window, the selected frame - but never delete the last frame visible to the eye
(including when `--daemon' is used).
It seems like the following choices together have resulted in a fragile
situation that doesn't make it easy (or even possible?) to know what's going on:
a. Considering all terminal frames as "visible". (Why?)
b. Naming the terminal frames with mundane names like "F1". (Why?)
c. Not having any frame parameter or predicate that distinguishes a terminal
frame. (Why not?)
d. Adding an invisible "visible" frame, F1, as part of the way to implement
`--daemon'. (Why?)
I can understand (a) and (b), I guess. In some sense, terminal frames _are_
always visible. And it's useful to refer to them using simple names.
But things seem very different for the extra frame that is used to implement
`--daemon':
(a) It is not there to take over and be shown if you delete all other visible
frames. If you do that, you lose all frames visible to the eye - you lose any
way to interact with Emacs other than by the external command line.
(b) A user will never, I think, refer to that special `--daemon' frame by name,
switching to it as `F1' (is that even possible?). But unlike hidden buffers
(e.g. ` *foo*'), this frame's name is a normal one.
next reply other threads:[~2010-03-02 18:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 18:29 Drew Adams [this message]
2010-03-02 19:06 ` test for a (really) visible frame? test if a frame is the only (really visible) one? Davis Herring
2010-03-02 19:32 ` 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=C6ADAF21677F4942B2D6C6BCC0A0A110@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
/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).