unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.





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