pop-up-frames inconvenience

pop-up-frames inconvenience

[Sam Steingold]

GNU Emacs 22.0.50.4 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2006-06-05 on quant8

when pop-up-frames is customized to t, the frames proliferate without
end and have to be explicitly deleted.
e.g., C-x m (`compose-mail') now creates a new frame that does not go
away automatically when I hit C-c C-c (`message-send-and-exit').

worse than that, when I hit TAB in the minibuffer, the *Completions*
window is now popped in its own frame, which has keyboard focus (thus
further typing results in errors unless I switch the keyboard focus to
the original frame) and obscures the original frame, hiding what I have
already typed.

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://ffii.org http://thereligionofpeace.com http://camera.org
http://pmw.org.il http://mideasttruth.com http://jihadwatch.org
Vegetarians eat Vegetables, Humanitarians are scary.

RE: pop-up-frames inconvenience

[Drew Adams]

Hi Sam,

1. help-gnu-emacs@gnu.org is the proper list for this kind of question.
Followups there, please.

2. I've wrestled with trying to get Emacs to play well with a
one-frame-per-buffer (by default) behavior for a long time. Take a look at
my library oneonone.el. It might suit you, and, if not, it might give you
some ideas for your own customizations. See
http://www.emacswiki.org/cgi-bin/wiki/OneOnOneEmacs.

HTH.

--
    when pop-up-frames is customized to t, the frames proliferate without
    end and have to be explicitly deleted.
    e.g., C-x m (`compose-mail') now creates a new frame that does not go
    away automatically when I hit C-c C-c (`message-send-and-exit').

    worse than that, when I hit TAB in the minibuffer, the *Completions*
    window is now popped in its own frame, which has keyboard focus (thus
    further typing results in errors unless I switch the keyboard focus to
    the original frame) and obscures the original frame, hiding what I have
    already typed.
--
    I want buffers created by the emacs server to show up in their own
    frames, so I do

    (add-hook 'server-switch-hook 'new-frame)
    (custom-set-variables '(server-window 'pop-to-buffer))

    the result is that the server buffer is shown both in a new frame and a
    new window in an existing frame.
    neither *Help*, nor *info*, nor the source are helpful...

Re: pop-up-frames inconvenience

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 5 Jun 2006 08:26:55 -0700
> Cc: Emacs-Devel <emacs-devel@gnu.org>
> 
> 1. help-gnu-emacs@gnu.org is the proper list for this kind of question.

Not for the CVS version of Emacs, it isn't.

Sam, please keep this discussion on emacs-devel, thanks.

RE: pop-up-frames inconvenience

[Drew Adams]

    > 1. help-gnu-emacs@gnu.org is the proper list for this kind of
    > question.

    Not for the CVS version of Emacs, it isn't.
    Sam, please keep this discussion on emacs-devel, thanks.

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.

Anyway, discussing it here is great - thanks for allowing it. I'd be glad if
this sort of problem were treated as a CVS-Emacs bug - overjoyed even. Then
I could get rid of my (old) code that tries to fix this kind of thing (e.g.
redirect frame focus from *Completions* to a standalone minibuffer frame).

Re: pop-up-frames inconvenience

[Sam Steingold]

> * Drew Adams <qerj.nqnzf@benpyr.pbz> [2006-06-05 14:00:38 -0700]:
>
>     > 1. help-gnu-emacs@gnu.org is the proper list for this kind of
>     > question.
>
>     Not for the CVS version of Emacs, it isn't.
>     Sam, please keep this discussion on emacs-devel, thanks.
>
> 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.
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.

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?)

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://truepeace.org http://palestinefacts.org http://openvotingconsortium.org
http://jihadwatch.org http://thereligionofpeace.com http://memri.org
Perl: all stupidities of UNIX in one.

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.

Re: pop-up-frames inconvenience

[Richard Stallman]

I agree it would be nice to work on a better user-level way of
controlling frames in Emacs.  However, let's not discuss that here,
now; we should focus on the release.

Would those who are interested please set up another temporary mailing
list for that purpose?

Re: pop-up-frames inconvenience

[John S. Yates, Jr.]

On Tue, 06 Jun 2006 17:13:22 -0400, you wrote:

>I agree it would be nice to work on a better user-level way of
>controlling frames in Emacs.  However, let's not discuss that here,
>now; we should focus on the release.
>
>Would those who are interested please set up another temporary mailing
>list for that purpose?

How does one who is interested connect up with such a list?

/john

Re: pop-up-frames inconvenience

[Sam Steingold]

> * Sam Steingold <fqf@cbqiny.bet> [2006-06-05 11:08:50 -0400]:
>
> GNU Emacs 22.0.50.4 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>  of 2006-06-05 on quant8
>
> when pop-up-frames is customized to t, the frames proliferate without
> end and have to be explicitly deleted.
> e.g., C-x m (`compose-mail') now creates a new frame that does not go
> away automatically when I hit C-c C-c (`message-send-and-exit').

one way to handle this would be to make all frames created by
display-buffer (as opposed to an explicit C-x 5 2 `make-frame-command')
dedicated.

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://camera.org http://jihadwatch.org http://pmw.org.il http://memri.org
http://truepeace.org http://mideasttruth.com http://dhimmi.com http://ffii.org
Lisp: Serious empowerment.

Re: pop-up-frames inconvenience

[Stefan Monnier]

>> when pop-up-frames is customized to t, the frames proliferate without
>> end and have to be explicitly deleted.
>> e.g., C-x m (`compose-mail') now creates a new frame that does not go
>> away automatically when I hit C-c C-c (`message-send-and-exit').

> one way to handle this would be to make all frames created by
> display-buffer (as opposed to an explicit C-x 5 2 `make-frame-command')
> dedicated.

That's indeed what I've implemented here (and proposed, but only for
post-22), by making "dedicated" into a 3-valued variable (a window can be
softly-dedicated, which basically means "this window was created in order to
display the current buffer" but doesn't prevent switching to another
buffer).


        Stefan

Re: pop-up-frames inconvenience

[Richard Stallman]

    when pop-up-frames is customized to t, the frames proliferate without
    end and have to be explicitly deleted.
    e.g., C-x m (`compose-mail') now creates a new frame that does not go
    away automatically when I hit C-c C-c (`message-send-and-exit').

That is what pop-up-frames does.

Re: pop-up-frames inconvenience

[Sam Steingold]

> * Richard Stallman <ezf@tah.bet> [2006-06-05 22:06:18 -0400]:
>
>     when pop-up-frames is customized to t, the frames proliferate without
>     end and have to be explicitly deleted.
>     e.g., C-x m (`compose-mail') now creates a new frame that does not go
>     away automatically when I hit C-c C-c (`message-send-and-exit').
>
> That is what pop-up-frames does.

I know, and this is not what a user expects: if a task (C-x m or
completion or whatever) has created a frame, it should delete it when
done.
this is what happens when tasks create windows, this is what should
happen when they create frames.

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://honestreporting.com http://mideasttruth.com http://truepeace.org
http://iris.org.il http://memri.org http://camera.org http://dhimmi.com
Between grand theft and a legal fee, there only stands a law degree.