[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: |
martin rudalics |
Subject: |
bug#9419: 24.0.50; C-x k deletes the entire frame instead of switching to another buffer |
Date: |
Sun, 04 Sep 2011 12:34:59 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (Windows/20090302) |
>> 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.
It's around for almost four years by now and apparently nobody noticed
the problem so far.
>> > . 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.
You mean the "never had more than one buffer" one?
> . 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.
Detecting whether "the user switched buffers in that window" appears not
entirely trivial. Earlier, I planned to divide functions into two
groups: The `switch-to-buffer' group would have been entirely left to
the user, while the `pop-to-buffer' group would have been left to the
applications. In that case we could have made the `switch-to-buffer'
functions reset the quit-restore parameter. Maybe we could achieve
something similar by testing `called-interactively-p' now.
> . 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.
`frame-auto-delete' is just a more general version of
`view-remove-frame-by-deleting'. I'd use an option say
`window-auto-delete' with the values nil (for not deleting anything),
window (for deleting only a window and leaving a frame alone), frame
(for deleting only a frame and leaving a window alone), and t (for
deleting window and/or frame, whichever is applicable).
> On second though, if we are trying to fix the specific use case of
> save-window-excursion, why not solve it on the level of
> save-window-excursion? That is, let save-window-excursion keep track
> of the window/frame created by display-buffer, and then delete that
> window/frame when the excursion ends.
>
> If this will solve the original problem, we can leave the behavior of
> kill-buffer etc. as it was in Emacs 23.
What I tried was not to fix the use case of `save-window-excursion'
alone but handle that case just as if it were a special case of a help
window. Trying to handle the `save-window-excursion' case separately
won't remove the "That sucks, IMO" case you bemoaned above.
Anyway - let me shortly try to summarize the problem: Initially there
was a problem with help windows and view mode and the fact that it
wasn't possible to "exit" help windows cleanly. I tried to solve that
back in 2007 using the `with-help-window' macro and the problems
disappeared.
Then two things happened: Stefan wanted me to rewrite the macro because
it contained ugly code. And there were protests about `display-buffer'
not DTRT within `save-window-excursion'. I tried to meet both issues by
installing the quit-restore window parameter (I didn't clean up any of
the window excursions yet though).
Now there are at quite a number of ways to get rid of a buffer in a
window: `bury-buffer', `kill-buffer' (which calls
`replace-buffer-in-windows'), `quit-window', and `delete-windows-on'
(the latter is interesting only in the special case where one of these
windows is the only window on its frame). I tried to make them behave
in a consistent way which, however, might have been a bad idea in the
first place.
Note also that Stefan always favored a solution based on dedicated
windows: Such windows get automatically deleted and/or the frame
iconified. But dedicated windows cannot handle the case where a window
got reused for showing the buffer and present difficulties when a window
shall be reused for showing another buffer.
Some of these problems might stem from the fact that `display-buffer' is
now used for creating fairly permanent windows (like when you call it
via `find-file' or `switch-to-buffer') and for fairly temporary windows
(like when you call it via `with-output-to-temp-buffer'). The expected
exit behavior of such windows seems different.
martin
- 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, 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 <=
- 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