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

[Drew Adams]

    Oops: I never noticed the `frame' arg 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.

    Something has to be assumed: should such frames be made visible
    by the 99%
    of the code that just uses display-buffer or pop-to-buffer
    without passing
    any `frame' argument?

No, of course not. The FRAME arg explicitly has a value (`t') to display
buffers on invisible frames. The doc string makes it clear that the default
(nil) value does not display an invisible frame, unless it is the selected
frame (if that is even possible).

My point was to interpret "invisible frame" as only that, and not also
suppose the special, exceptional behavior wrt displays that you mentioned.
My comments were in the context of this exceptional behavior, which you
described.

    The correct answer depends on the underlying reason why you've made the
    frame invisible.  Most of the current code assumes that the reason why
    you've made it invisible is because you really don't want to
    see it, so it
    should only be made visible by some specific operation, and not just by
    display-buffer.

See my reply above - the `t' value of FRAME is for this; `display-buffer'
should not make a frame visible unless `t' is used (or nil is used and the
invisible frame is selected, if that is possible).

Not sure what you mean by the last part. Not sure if we're disagreeing or
agreeing here.

    If you made it invisible just because you currently don't want
    it to clutter your screen but you'd like it to pop right back
    whenever it's needed, then you're better off iconifying rather
    than making your frame invisible.

    It seems what you want is somewhere between invisible and iconified.

I don't want anything - except for `invisible' to be treated like `visible'
and `iconified', or else for its exceptional behavior to be documented (I
prefer the former).

I'm not looking for advice here ("you're better off") on using invisible or
iconified frames; I'm just mentioning that 1) frames can be invisible, 2)
some people might use such critters, and 3) their treatment shouldn't, a
priori, be different from the treatment of iconified or visible frames.

In particular, you mentioned that the behavior is different wrt other
displays - if so, I don't think it should be different. If it must be
different, then it should be documented.

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

    It's still slow here (Athlon64 2GB GNU/Linux), so I use iconification.
    I also avoid delete&recreate because it loses the size&placement info.

Good point (the latter).

Iconification is not a substitute for invisibility. Depending on your OS,
frame icons can be more or less of a nuisance.

Anyway, regardless of why or whether anyone would use invisible frames, the
question here is how they should be treated. A priori, they should not be
treated exceptionally, in particular, wrt to different displays. That's all
I'm saying.