RE: ibuffer problem with pop-up-frames non-nil

[Drew Adams]

    >     Maybe here it makes sense.  But be super extra careful with t in
    >     such places: it considers all frames including frames on
    >     other displays.

    > I didn't know that. Is that behavior special for `t'?
    > Wouldn't it logically apply to `visible' and `0' also?
    > If not:
    >  - Why is `t' an exception in this regard?
    >  - Is there no way to get the invisible-frames-too behavior
    >    of `t', without also the other-displays-too behavior?

    I think it makes sense: frames that are invisible are similar
    to frames on other displays in the sense that no amount of
    `display-buffer' (or pop-to-buffer) will be sufficient to
    display them.

Just because some function (e.g. `display-buffer') treats two things
similarly does not mean they should be treated equally everywhere (or
considered equal). IOW, `display-buffer' does not display an invisible
frame - so what?

Besides, why shouldn't `display-buffer' show an invisible frame? It should,
if the FRAME arg is `t' (i.e. this is a bug, IMO). The same argument for
`get-buffer-window' applies to `display-buffer'.

An invisible frame is simply that (according to its current description).
How (and whether) programmers use them is up to them. Nothing should be
assumed about those uses - unless we're going to stipulate (i.e. both
require and document) that invisible frames have this exceptional behavior.

    BTW, why do you worry so much about invisible frames?  I've
    never actually bumped into one.

I used to use invisible frames all the time, to avoid deleting and
recreating frames, back when the frame-creation process was slow (at least
on my machine & OS), and (IIRC) before there was `special-display-function'.
Lately, I've gone back to deleting them, mainly because I ran into some
buggy behavior [see *, below] wrt invisible frames.

(More exactly, I used a function `remove-window', which did `delete-window'
unless the window was dedicated and alone in its frame, in which case it
made the frame invisible. Now, I just use `delete-window'. Because of a
`raise-frame' bug, I did not make the frame invisible if it was already
iconified.)

Just because people might not use invisible frames much now is no reason to
suppose things about their possible use - and to make code depend on such
supposition. We should either:

- Treat them as they are described in the documentation (that is, treat them
the same way we treat visible and iconified frames, since nothing special is
said about them).

or

- Implement the supposition as a requirement (e.g. a check), and document
it.

I see no reason to give invisible frames special treatment wrt other
displays, even if that behavior were to be documented.

Again, if this exceptional behavior is to remain:

1. It should be documented.

2. There should be some way "to get the invisible-frames-too behavior of
`t', without also the other-displays-too behavior.


* Buggy behavior for invisible frames includes:

1. `raise-frame' doesn't.

2. `default-frame-alist' doesn't affect the visibility parameter of newly
created frames - see email "Create an invisible frame" sent to emacs-pretest
2005-05-31.

3. If you change the value of parameter `vertical-scroll-bars' (whatever the
new & old values) for an invisible frame, the value of parameter
`visibility' is also changed to t, as a side effect. What's worse, the frame
remains physically invisible, in spite of the parameter value. See email
"`modify-frame-parameters' for scroll-bars makes invisible frames
inaccessible" sent to emacs-pretest 2004-03-19.