RE: special buffer frames again

[Drew Adams]

> Maybe a more significant difference is that my window-manager is
> configured to not auto-place new windows, so whenever Emacs
> creates a new frame I have to manually place it.  So remembering
> placement is particularly important.

I see. That would make a big difference.

> I have 2 separate icon-managers: one for Emacs windows, and
> another for the rest.  So my Emacs icon-manager acts as a
> "buffer list".  So I can just select the relevant buffer
> with the mouse rather than use C-x b.

I see.

FWIW, when I do want to iconify a frame, I actually use my own
thumbnail-frame pseudo-icons, instead of iconifying to the Window task bar
(http://www.emacswiki.org/cgi-bin/wiki/FisheyeWithThumbs). So the behavior
is similar to that of other window mgrs: icons on the desktop vs in the task
bar. (But the "icons" are really frames, so I can stack them any way I want,
scroll, select text, monitor process progress, and so on.) This is not very
relevant here, however.

> > Thought experiment: Imagine if Emacs windows were always
> > iconified instead of simply disappearing when you are done
> > with them - do you think many users would complain?
> > I'll bet that such a feature would be removed within 48 hours.
>
> I'm not sure I see the relation.

`pop-up-frames' = t makes Emacs use frames instead of windows, by default.
If Emacs treated its windows the way it currently treats its frames (e.g.
iconify when done), then I think more people would realize how poorly Emacs
plays with `pop-up-frames' = t.

> To me it's more like buffers: buffers can be displayed or
> (not in which case they're like iconified, visible in the
> buffer-list).

The main annoyances with iconification are 1) distraction of seeing the
frame zoom into an icon (at least on Windows), and 2) visible presence of
the icons.

When a buffer is no longer displayed, it is not apparent anywhere - unless
you explicitly choose to show a list of buffers. If a buffer list were
always visible, taking up screen real estate, and if the displayed buffers
zoomed into that buffer list in an animated way whenever you undisplayed
them, then, yes, your analogy would fit, and undisplay of a buffer would be
as annoying as undisplay of a frame is now.

But buffers and Emacs windows don't suffer from these distractions - they
just disappear (Poof!). That's what should happen to most frames (including
*Help* and *Completions*), when you are finished with them (even
temporarily). Choosing a completion or hitting C-g or hitting q in *Help*
should never iconify the frame; it should just delete it.

As you mention, as long as a buffer exists, you can always redisplay it via
the buffer list - there is no reason to also have every undisplayed buffer
in an omnipresent icon list somewhere.

> Some users are bothered by the ever growing list of buffers,

Not I, in any case. But that is one reason I do iconify some frames (using
thumbnails). I use a short list of iconified buffers, and, for less
frequently used buffers, I explicitly call upon the long buffer list (or use
completion).

> but they can always use C-x k when it's a problem.

And that would be felt sooner to be a problem if the buffer list were
displayed continually, as are icons.

> And I do the same: basically all my frames are "dedicated",
> so if I do C-x k, it deletes the relevant frame.

Same here. And I've tweaked basic code so that the display of "temporary"
buffers also goes "Poof!" when it's done.

> In any case, the main problem for me with deletion of frames is
> the loss of information (mostly placement).

Yeah, that sounds like a bummer.

If your preference for auto-iconification is based mainly on your needing to
position frames manually, would you agree that frame deletion is generally
better for people who don't share that window-mgr limitation?

> > FWIW, the OP specifically pointed to the annoyance of
> > iconification - he was looking for a way to eliminate that.
> > Maybe you have a suggestion for him, explaining how you
> > avoid this annoyance - or how you avoid being annoyed by
> > it ;-)?
>
> I don't think the problem is iconification, but it's the accumulation of
> frames: so a better solution might be to reuse a special frame
> dedicated to those temporary buffers.

That might be worth considering, but there can often be multiple such
temporary buffers at any time. I, for instance often display *Help* during
minibuffer completion.

In any case, I think the problem the OP mentioned was not accumulation of
frames, but iconification, and the fact that the iconified frames remained
iconified when he tried to access them again. *Completions* and *Help* were
sitting there as icons, making it impossible to see what was in them without
explicitly deiconifying them. Here is what he said:

Tyler> This also affects help windows. For example, if I c-h v, then use
> completions to select the variable I want to see, and then exit the
> help window with q, I end up with a completions frame and a help
> frame, both minimized on the toolbar. They update themselves with
> subsequent calls to help or completions, but don't restore themselves
> to be visible when they do so.

and

> the window minimizes itself, and stays minimized...
> this means I can't see the window without selecting its icon...

Perhaps one improvement here would be to raise frames whenever their buffers
are updated. But that might not always be desirable, depending on the frame
and the context. Frame deletion still gets my vote.