RE: Usage examples of dedicated windows and popup frames?

[Drew Adams]

> Since lately I've read of many people on this list that they are using
> dedicated windows, dedicated minibuffer frames, and popup frames...
> [I would like some] help finding some appealing overall configuration
> that just works for me.

I'm happy to see interest in using frames more with Emacs!

The more people try, the more they will encounter a few things, as you did, that
don't quite work right.  Bringing attention to such problems is a good thing.  

IMO, it's been too bad that Emacs Dev has long more or less neglected the
non-nil `pop-up-frames' case.  I'm not faulting anyone - that's probably to be
expected, since most people use nil `pop-up-frames'.

But it's a chicken-and-egg thing too: People who do try non-nil `pop-up-frames'
generally give up, precisely because of the problems they encounter and the lack
of obvious ways to work around them.  Problems such as those you ran into.

And Emacs Dev is also consequently at a disadvantage when someone who does use
`pop-up-frames' reports a frames-related bug.  Because I have workaround code to
deal with such problems, when I report a bug involving some frame behavior I
need to provide also my setup code (or a pared down version of it) to help
developers reproduce the bug.  This can mean a lot of extra work for both me and
the developer investigating (e.g. Martin).

> And basically it's not that bad.

Good to hear.  Out of the box, I think it's mostly there.
But there are definitely a few wrinkles to be ironed out.

> But after using it for an hour, I have more than 10 open emacs
> frames now.  Most of them were opened for showing completion
> possibilities, but after I've finished completion they became
> useless.  It would be great if those would be
> closed automagically...

I use several frames at once, and that's not a problem in general
for the frames I want to continue working with.  I can easily work
with a bunch of them at once.  (Thumbifying is handy for this:
http://www.emacswiki.org/emacs/FisheyeWithThumbs.)

But what _is_ a problem are frames that get popped up for temporary purposes and
then remain - as you mentioned wrt *Completions*.  This is actually not that
common aside from *Completions*, but it does happen occasionally.

It would be great for Emacs to have a good, general solution.

In my own use, I:

1. Use a dedicated frame for *Completions*.
2. Use a standalone minibuffer frame.
3. Redirect the *Completions* frame's keyboard input (focus)
   to the minibuffer frame.
4. Automatically delete the *Completions* frame when completion
   is finished.

(The first three are provided by `oneonone.el', the last by Icicles.)

I'm not suggesting that this should be the way to go for a general Emacs
solution (dunno).  I'm just mentioning that it is what I do - just one data
point to consider.  I've made it available and mentioned it to Emacs Dev for
many years now.  I've used it everyday in Emacs versions from 20 through 24, and
it works for me.

I think that Stefan also uses a standalone minibuffer frame and non-nil
`pop-up-frames'.  But I think he uses (weakly) dedicated windows pretty much
everywhere.  I generally use normal (not dedicated) windows.  I use (fully)
dedicated windows only for buffers with names `*...*'.  Stefan presumably never
changes the buffer shown in a given window; I do (e.g. `C-x f', `C-x C-v') - in
normal windows.

It would be interesting to see Stefan's solution to the problems/annoyances,
i.e., to see his personal setup.  But AFAIK he has never exposed his setup, let
alone proposed its frame-oriented solutions for Emacs.

Like you, Tassilo, I would like to see a workable-out-of-the-box solution for
non-nil `pop-up-frames' (or whatever the Emacs 24 equivalent will finally turn
out to be) - that is, for letting users use frames in a general way.  I have my
own solution, but I'm also interested in Emacs providing something out of the
box.

I've solved the *Completions* problem for myself, by following the logic of
completion and getting rid of the *Completions* frame when it is no longer
needed.  Completion is in effect a dialog, and when that dialog is finished
there is no longer any reason to show *Completions*.

But now and again (rarely) I run into a similar problem wrt other "temporary"
pop-up frames such as the list of flagged or marked files for Dired operations.
I make `*...*' buffers be "special-display", so they get their own dedicated
windows/frames, and their frames hang around after the "temporary" dialog is
finished (e.g. the Dired operation).

To me this is a (minor) hassle.  Emacs should IMHO treat such a dialog as what
it really is: a (non-modal) user _dialog_.

Displaying a list of files and asking if you really want to delete them is fine,
but that files display should then disappear (duh) after you've answered the
question, regardless of whether it is in a separate frame, dedicated window,
etc.  Emacs Dev handles the pop-up window case OK here, but not the pop-up frame
case - see, e.g., bug #7533.

To me, this kind of thing should be a no-brainer (in terms of need to fix, not
necessarily in terms of ease of implementation), but the "second-class
citizenship" of frames in Emacs effectively relegates it to the dust bin. ;-)

If more people become interested in making frames work then it's likely there
will be more attention to fixing such problems.

> Long story short: it would be nice if some people with non-standard
> window/frame settings could share and briefly explain their
> configuration.  I'm very interested.

Me too.  The more the merrier.  I'm very glad to see people take interest in the
problem.

No doubt this is due partly to Martin's recent changes to the display-buffer
code.  And no doubt those changes will affect how such problems should be
handled going forward.  No doubt I will need to update my own way of dealing
with these problems, since `pop-up-frames' is being deprecated.

If you are interested in my settings, which still work with Emacs 24 but which
also still use `pop-up-frames' so far, you can see a description (and code)
here:
http://www.emacswiki.org/emacs/OneOnOneEmacs

Add to that Icicles's auto-deletion of the *Completions* frame.  At various
points in the completion code I call a function that removes the *Completions*
window.  And in the case where that window is in its own dedicated frame, it
deletes the frame (it's actually a bit more complicated, but that's the idea).

That's about it.

> And maybe it's a good idea to ship emacs with some predefined setups
> users can easily try out and then extend to find one that suits them
> best, for example, the current default window oriented configuration, a
> more frame oriented configuration, and a frame oriented configuration
> with a dedicated minibuffer frame, too.

1+ !