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

["Drew Adams" <drew.adams@oracle.com>]

    >> I would prefer, of course, that if pop-up-frames = non-nil,
    the behavior of
    >> view-remove-frame-by-deleting would follow automatically (by
    default).

    > Well, I'm not sure about this: is it really true that someone who
    > wants view-mode to create a frame for every new buffer in view mode
    > would like such frame to automatically go away when they quite view
    > mode?

    To "go away"?  Probably. But "to delete"?  No.

    I know Drew always wants to delete such frames because his
    window-manager and use pattern make it inconvenient to have
    too many iconified windows.

    OTOH with my window manager and my usage pattern, it's the
    reverse: deleting frames is a major pain in the rear because
    when they are re-created, I have to manually place them
    again (and set various other attributes like size,
    set of workspaces they should appear in, ...).

    So we should have a function to "make a frame go away"
    (probably bury-buffer or quit-window or both) and use that,
    and then make this function customizable so that we can
    decide whether to delete or to iconify.

I agree with Stefan. Iconifying is terrible in Windows and frame
deletion/creation is instantaneous. Other platforms can be the other way
around. And users can prefer one or the other behavior.

If frame invisibility were not bugged, I think that would be a good general
solution (i.e. good candidate for the default value). But it is bugged. For
quite a while (Emacs 19 or 20) I made frames invisible instead of iconifying
or deleting them - when bugs don't raise their ugly heads, it's an elegant
solution. Most of the time spent creating a frame (at least back then, on
Unix) was apparently spent defining it, not displaying it, so making an
invisible frame visible again was instantaneous - and it returns to the same
place it last was, with the same properties (which is Stefan's main problem
with frame deletion and re-creation, IIUC).

If others agree with Stefan and I, the next question would be the default
value for quitting. I obviously vote for frame deletion (e.g. via
quit-window), and I'm sure Stefan votes for frame iconification (e.g. via
bury-buffer). As long as this is an option, the default value is of course
not that important.

(BTW - The problem with iconification on Windows is not just the presence of
numerous unneeded icons; it's the distraction of the animated iconification:
the frame visibly streams to become an icon - it doesn't just disappear and
an icon appear.)

Thanks for looking into this. Perhaps, after the release, we can look at
fixing frame invisibility, so that could be used in cases like this. (I
don't know - perhaps it's already been looked at and deemed unfixable.)