[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching t
From: |
Eli Zaretskii |
Subject: |
bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer |
Date: |
Sat, 03 Sep 2011 20:44:09 +0300 |
> Date: Sat, 03 Sep 2011 19:29:29 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 9419@debbugs.gnu.org
>
> >> (save-window-excursion
> >> (display-buffer "foo"))
> >>
> >> which doesn't DTRT when foo is displayed on a different frame.
> >
> > You mean, if display-buffer creates a new frame? Or that frame
> > already exists, and display-buffer just raises it and makes it the
> > selected frame?
> >
> > And what do you mean by "doesn't DTRT"? What is TRT in that case?
>
> In the idiom above, when a user has `pop-up-frames' nil, a new window
> showing the buffer gets created on the selected frame and gets deleted
> when the window excursion terminates. When a user has `pop-up-frames'
> non-nil and a new frame gets created that frame is not deleted. This
> fact has already caused some vivid discussions here. IMO TRT is to
> treat windows and frames the same.
Agreed.
> > Perhaps I'm missing something, but if we are talking about "long time
> > after", then which buffer causes frame deletion is immaterial: they
> > both will cause the same amount of surprise.
>
> Precisely this mechanism is inherent to help frames you quit with "q" in
> Emacs 23. Quitting any other buffer in such a frame would not cause its
> deletion.
That sucks, IMO.
> > This is actually how I bumped into this problem in the first place. I
> > have a frame where I switch between different *info*<n> buffers
> > showing various manuals, using the info-display-manual command.
> > Whenever the Emacs or ELisp manuals are rebuilt (because they are
> > updated on the trunk), I kill the corresponding buffer and re-read
> > that manual anew. When I started using Emacs 24, I was surprised to
> > find out that this sometimes, but not always, deleted the entire
> > frame. I now understand that this depends on which buffer I was
> > killing and in what order, but believe me: the surprise was complete,
> > and the apparently inconsistent behavior only added to it.
>
> You should have protested immediately.
Believe it or not, this bug report is my "immediate" protest ;-) It
took time for me to realize that the frame deletion was not due to
some cockpit error on my part, and then some more time to create a
simple recipe suitable for submission.
> > I can see 3 possible ways to have a consistent behavior:
> >
> > . Never delete a frame except by an explicit call to delete-frame. I
> > think this is what Emacs 23 did, so it is also backward-compatible.
>
> There are two exceptions in Emacs 23 to this rule - help frames and
> dedicated frames.
>
> > . A minor variation on the above: never delete a frame, except when
> > it was created by display-buffer, and never had more than one
> > buffer in its buffer list. IIUC the use case you were trying to
> > fix, this will fix it.
>
> Tracking the "never had more than one buffer" is tedious but could be
> done.
>
> > . Always delete a frame whenever the last buffer in its buffer list
> > is killed. This is a change in behavior wrt Emacs 23, so it should
> > probably be conditional on some option.
>
> It is: Setting `frame-auto-delete' to nil should inhibit implicit
> deletion of frames.
So I think the second alternative is the best, if it is doable.
> But it won't inhibit implicit deletion of windows, something hardly
> anyone has noticed (Juanma is the only one who suffers from it so
> far).
I did notice that. I just didn't yet make up my mind whether I like
it or not.
> I can do whatever people want. But consistency should also cover the
> window/frame dichotomy.
Agreed.
So how about this plan:
. Never delete a frame, except when it was created by
display-buffer, and never had more than one buffer in its buffer
list.
. Do the same with windows created by display-buffer: if the user
switched buffers in that window, don't delete the window when the
excursion ends.
. Introduce a window-auto-delete option, by default set the same as
frame-auto-delete, to control window deletion like
frame-auto-delete controls that of frames. Alternatively,
deprecate frame-auto-delete and introduce a new
frame-and-window-auto-delete with the old one its alias. Then
make this new option control both window and frame auto-deletion
alike.
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, Eli Zaretskii, 2011/09/01
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, martin rudalics, 2011/09/03
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, Eli Zaretskii, 2011/09/03
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, martin rudalics, 2011/09/03
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, Eli Zaretskii, 2011/09/03
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, martin rudalics, 2011/09/03
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer,
Eli Zaretskii <=
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, Eli Zaretskii, 2011/09/03
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, martin rudalics, 2011/09/04
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, Eli Zaretskii, 2011/09/04
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, Stefan Monnier, 2011/09/06
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, martin rudalics, 2011/09/08
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, Stefan Monnier, 2011/09/06
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, martin rudalics, 2011/09/08
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, martin rudalics, 2011/09/08
- bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer, Eli Zaretskii, 2011/09/09