RE: pop-up-frames inconvenience

[Drew Adams]

    > If I understand Sam's complaint, this behavior (with the
    > possible exception of message-send-and-exit) is not at all
    > new to CVS Emacs.

    indeed this might be wrong time (as Emacs is approaching a
    release) but this is definitely the right place to discuss
    _design_ issues related to multi-frame operations.

Yes.

    to put it bluntly, pop-up-frames does not work as one would
    expect it to, requiring plenty of hacks to make, e.g., separate
    minibuffer frame usable.

I couldn't agree more (except a standalone minibuffer presents no problem
that I've seen), and I have been saying so (also bluntly) for some time. Out
of the box, Emacs just does not play well with pop-up-frames=t.

People either give up using that option, or they end up customizing and
tweaking the hell out of Emacs to get it to behave reasonably. Most, I
suspect, take the former route: they play with p-u-f=t briefly, discover
that it is broken in different ways, and go back to using Emacs windows. The
last thing anyone wants is fifty million forgotten frames littering the
desktop, not to mention struggles with frame focus.

What Emacs does with windows should be available for frames also - the same
convenience and smart behavior, but adapted to a frames world. Emacs is
marvelously adroit with windows, and miserably maladroit with frames.

    two independent paths appear to be promising:

    1. make all frames that are not explicitly created by the user
       "dedicated" (then quit-window will delete them)

    2. some buffers are not "stand-alone" but tied to the current
       (minibuffer) operation (e.g., *Completions*).
       maybe they should be prevented from creating their own
       frames. maybe completion should be done via a non-buffer
       mechanism (like baloon help?)

I'm not crazy about either one, frankly. If we go after this problem, let's
approach it slowly and do it right. There are no doubt lots of "solutions",
as the problem itself is multiple: there are lots of tiny (and some maybe
not so tiny) problems with Emacs + pop-up-frames=t. I'm skeptical of a "y'a
qu'a" ("all you need to do is") solution here.

I'm not sure about #1. IIUC, it means reinterpreting (or, rather, imposing a
single behavioral interpretation on) what it means for a frame or window to
be "dedicated". Maybe I'm misunderstanding you (& Stefan), but I think the
current notion of special-display buffer is, on the contrary, open to any
interpretation/behavior a user wants to give it.

If #1 is about a new, separate (orthogonal) mechanism/feature, then that
approach might be OK, but if it means coupling the current notion of
dedicated window with p-u-f=t, then I think that's too restrictive. I use
one-buffer-per-frame, but I change the buffer in the frame quite often. Just
as with windows you can use C-x f (not just C-x 4f), so with frames you can
reuse a frame with a different buffer. I don't want to lose that.

I certainly agree that there should be a simple way (e.g. quit-window) to
delete a frame (I use a kill-buffer substitute that also deletes the
window/frame, in addition to quit-window).

I would prefer that we try to attack the individual problems that using
p-u-f=t poses in practice one by one. These might be solved individually,
without necessarily requiring any new mechanism or single remedy. I've
gotten by quite well with this approach so far. What I find (feel) is that
not enough testing is done with p-u-f=t, so here and there Emacs code just
doesn't DTRT wrt this "mode". Mr X implements a new feature, and doesn't
bother to make it friendly also to p-u-f=t. That's not a big deal usually;
it just needs to be corrected, over and over, here and there.

My guess is that if the main Emacs developers were forced to live with
p-u-f=t (only) for one week, within another two weeks all of the p-u-f=t
problems would be solved. It would drive them bananas, and they would find
ways to DTRT. I expect that fixing the isolated code problems so that Emacs
DTRT is probably sufficient. But I really have no horse in this race - I too
would just like to see the problems go away in vanilla Emacs.

WRT #2 - The problem is real, but I am opposed to that particular
"solution". I like one-buffer-per-frame (by default), and I like to use
frames for everything (almost, by default). That can and should be made to
work (for those who want it). I definitely want a separate frame for
*Completions* - in particular! However, it needs to have its focus in the
minibuffer. That's what I do in my code, and it works very well.

As for everything involving pop-up-frames, using a pop-up frame for
*Completions* also means, of course, that things like C-g (and other ways to
exit the minibuffer) need to delete the *Completions* frame. Again, what we
do correctly for Emacs windows, we need to also do correctly for frames. If
the code were simply tested with p-u-f=t, all of the problems would be fixed
(and they wouldn't have been created to begin with). That's the good news:
the "problem" is more a mixed collection of oversights than a fundamental
design flaw, IMO.

It's not because most people don't use p-u-f=t that it shouldn't work well
everywhere. It's not because the current code presents multiple difficulties
for p-u-f=t that we should aim for a partial solution. Some people will want
*Completions* to be a pop-up window, even if they otherwise use p-u-f=t.
Others, like me, will want *Completions* to be in its own frame. It should
be possible to satisfy both preferences (separately). There are other
"temporary" buffers, like *Help*, that also pose this or similar questions,
even when they don't share the focus problem that *Completions* has.

There are different ways to use p-u-f=t, and that's what should be kept in
mind if we try to make it work. Some people use a fixed set of frames of set
sizes. Others, like me, let each buffer have its own frame and resize the
frame automatically to fit the buffer.  A fix to the p-u-f=t problems should
be flexible in terms of a variety of p-u-f=t use cases.

In sum, it would be great for Emacs developers to take seriously the
impolite behavior of Emacs with pop-up-frames=t. I really welcome a
discussion. Let's simply not jump to a single, hasty "solution" that doesn't
allow flexibility for different users. Like anything else, people use
p-u-f=t differently. With a little foresight and attention to the problems,
there should be room for all.