RE: view mode: `q' does not delete frame

[Drew Adams]

    > If frame invisibility were not bugged, I think that would be
    > a good general
    > solution (i.e. good candidate for the default value).

    Could be a good default indeed.  Although having it be an
    option would be even better because I much prefer iconification.

    > But it is bugged.

    Could you resend your bug-reports?

OK. However, some of what I have to report is incomplete - I encountered
flaky behavior some time ago that I never really tracked down completely.

Below are some emails on this subject. The (end of the) first one summarizes
what's in most of the others, I think, with the exception of the message of
January 18, 2005 - "multiple frames with same name on (frame-list)", which
is a separate problem.

Anyway, HTH.

--------------8<-----------------

    -----Original Message-----
    From: Drew Adams [mailto:address@hidden
    Sent: Monday, November 07, 2005 8:39 AM
    To: address@hidden
    Subject: RE: ibuffer problem with pop-up-frames non-nil


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

--------------8<-----------------

    -----Original Message-----
    From: Drew Adams [mailto:address@hidden
    Sent: Monday, November 07, 2005 11:07 AM
    To: address@hidden
    Subject: RE: ibuffer problem with pop-up-frames non-nil

        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.

--------------8<-----------------

    -----Original Message-----
    From: Drew Adams [mailto:address@hidden
    Sent: Tuesday, January 18, 2005 8:35 AM
    To: Emacs-Devel
    Subject: multiple frames with same name on (frame-list) - what is the
    cause?

    I didn't get any reply on this from help-gnu-emacs. I'm hoping
    that someone here might have some insight on it. Thanks - Drew

    ----

    As far as I know, I am not creating any multiple frames with
    the same name.
    After a sequence of operations such as `iconify-frame',
    `make-frame-invisible', and `make-frame-visible', however, I
    somehow end up
    with some frames listed multiple times in `(frame-list)'.  I'm
    not sure of
    the exact sequence of such operations that leads to the problem.

    Actually, the "duplicate" frames have the same name, but they
    are different
    frames, as indicated by their hex ids. One of them will have
    frame-parameter
    `(visible . t)', and the others will have frame-parameter `(visible)'.
    Again, all of these frames are listed in `(frame-list)'.

    These multiple frames are messing things up when I try, for instance, to
    iterate over `(frame-list)'.

    Anyone have an idea where the multiple frames on `(frame-list)'
    are coming
    from? I don't see anything in the various function definitions
    or the doc
    that would indicate that one of the functions (e.g.
    `make-frame-visible' or
    `make-frame-invisible') would create a new frame instead of
    operating on an
    existing frame (its argument).

    BTW, the only way that I'm using `make-frame-visible' is through
    `frame-configuration-to-register' followed by
    `jump-to-register', and these
    functions use `current-frame-configuration', which just iterates over
    `(frame-list)'.

    I see this problem in both Emacs 20.7 and Emacs 21.3.50 (from CVS July
    2004).

--------------8<-----------------

-----Original Message-----
From: Drew Adams [mailto:address@hidden
Sent: Friday, March 19, 2004 2:09 PM
To: address@hidden
Subject: modify-frame-parameters

Emacs 20.7

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.

This is important if you change the scroll-bar setting for all frames: it
ends up making the invisible frames inaccessible, because they are
physically invisible but their visibility parameter is set to t.

Changing the value of other frame parameters doesn't seem to affect the
visibility parameter (I didn't test them all, however).

(setq tttt (selected-frame))
(make-frame-invisible tttt)
(frame-parameters tttt) => (...(visibility)...)
(modify-frame-parameters tttt '((vertical-scroll-bars)))
(frame-parameters tttt) => (...(visibility . t)...(vertical-scroll-bars)...)

I use Emacs 20, so it doesn't help me if this is fixed in Emacs 21. Is there
a fix or workaround for Emacs 20? modify-frame-parameters is built-in; is
there an equivalent lisp definition that could be corrected for the fix?

--------------8<-----------------

    -----Original Message-----
    From: Drew Adams [mailto:address@hidden
    Sent: Tuesday, May 31, 2005 6:30 AM
    To: address@hidden
    Subject: FW: Create an invisible frame -?


    Is this a bug or a "feature"? Shouldn't default-frame-alist
    affect the visibility parameter of newly created frames?

    -----Original Message-----
    From: Drew Adams
    Sent: Saturday, May 28, 2005 12:48 PM
    To: address@hidden
    Subject: RE: Create an invisible frame -?

        can someone tell me how to create an invisible frame?
        I tried setting visibility to nil in default-frame-alist, but that
        doesn't do the job.

    This works for me:

      (make-frame '((name . "foo") (visibility)))

    But you're right; if I do this, then `C-x 5 f RET bar', the
    resulting new
    frame is visible (visibility . t):

      (setq default-frame-alist (append '((visibility))
    default-frame-alist))

    I wonder if this doesn't represent a bug?

--------------8<-----------------

Here's part of a reply from Stefan to me that speaks of invisible-frame
problems:

    > I suggested making the frame invisible (instead of deleting
    > or iconifying
    > it) when the buffer is left definitively - that should keep the
    > size&positition info. Have you tried that? After all, that's
    > what we're
    > after here: I want to stop displaying the frame, and you want
    > to retain its
    > size&position info. Just set the visible frame parameter to
    > nil, and leave
    > the size and position info as is.

    invisible frames are poorly supported (they'd require
    significant further
    changes since pop-to-buffer wouldn't make it visible again), and
    I definitely prefer it being iconified.  If it's really so
    important for the
    two of us to have different behaviors in the same cases, maybe
    a config var  is in order.