* bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window
@ 2014-02-15 22:44 Drew Adams
2014-02-15 22:56 ` Juanma Barranquero
2014-02-16 10:33 ` martin rudalics
0 siblings, 2 replies; 7+ messages in thread
From: Drew Adams @ 2014-02-15 22:44 UTC (permalink / raw)
To: 16768
This part of the `quit-restore-window' causes a special-display buffer,
whose window is dedicated to it, to be replaced in that window by
another buffer:
(t
;; Show some other buffer in WINDOW and reset the quit-restore
;; parameter.
(set-window-parameter window 'quit-restore nil)
;; Make sure that WINDOW is no more dedicated.
(set-window-dedicated-p window nil)
(switch-to-prev-buffer window bury-or-kill))
If BURY-OR-KILL is `kill' then the window/frame should simply be
deleted. A window dedicated to a particular buffer should not be reused
for another buffer.
Consider, for example, a `special-display-frame-alist' that specifies
certain frame attributes - e.g., a particular background color. You do
not want to reuse such a frame for another buffer, especially for a non
special-display buffer. The frame should be deleted when its buffer
is killed.
In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
of 2014-02-11 on ODIEONE
Bzr revision: 116410 lekktu@gmail.com-20140211204823-l9l2s6tktfitq266
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
CPPFLAGS=-Ic:/Devel/emacs/include'
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window
2014-02-15 22:44 bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window Drew Adams
@ 2014-02-15 22:56 ` Juanma Barranquero
2014-02-16 2:41 ` Drew Adams
2014-02-16 10:33 ` martin rudalics
1 sibling, 1 reply; 7+ messages in thread
From: Juanma Barranquero @ 2014-02-15 22:56 UTC (permalink / raw)
To: Drew Adams; +Cc: 16768
On Sat, Feb 15, 2014 at 11:44 PM, Drew Adams <drew.adams@oracle.com> wrote:
> This part of the `quit-restore-window' causes a special-display buffer,
> whose window is dedicated to it, to be replaced in that window by
> another buffer:
Martin will surely remember, but I think that was done because of a bug report.
> You do
> not want to reuse such a frame for another buffer, especially for a non
> special-display buffer. The frame should be deleted when its buffer
> is killed.
What if you have just one frame, and it's dedicated and you kill the buffer?
J
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window
2014-02-15 22:56 ` Juanma Barranquero
@ 2014-02-16 2:41 ` Drew Adams
2014-02-16 4:33 ` Juanma Barranquero
0 siblings, 1 reply; 7+ messages in thread
From: Drew Adams @ 2014-02-16 2:41 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 16768
> > You do not want to reuse such a frame for another buffer,
> > especially for a non special-display buffer. The frame
> > should be deleted when its buffer is killed.
>
> What if you have just one frame, and it's dedicated and you
> kill the buffer?
I figured someone might immediately focus on that. It's a
corner case. Choose something appropriate. Not worth
arguing about at the outset.
One possibility: Kill the buffer, then call `delete-frame'.
The latter attempt raises an error, and you end up, at worst,
in the situation that arises today: another buffer in the
special-display frame. Not appropriate, but a more minor
bug than doing that systematically.
Another possibility: Make killing the buffer and deleting
the frame transactional, i.e., acting together like an atomic
action. Raise an error before killing the buffer if deleting
the frame afterward would raise an error.
Another possibility: Do like we do for `buffer-quit-function'
or `frame-auto-hide-function': provide an option to let the
user decide.
Propose another possibility, if you like. And another.
But this should be the last thing to worry about. Debate it
at the end if there is interest. It should not sidetrack
fixing the bug, taking it down a rabbit hole to never-never
land.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window
2014-02-16 2:41 ` Drew Adams
@ 2014-02-16 4:33 ` Juanma Barranquero
2014-02-16 6:37 ` Drew Adams
0 siblings, 1 reply; 7+ messages in thread
From: Juanma Barranquero @ 2014-02-16 4:33 UTC (permalink / raw)
To: Drew Adams; +Cc: 16768
On Sun, Feb 16, 2014 at 3:41 AM, Drew Adams <drew.adams@oracle.com> wrote:
> I figured someone might immediately focus on that. It's a
> corner case. Choose something appropriate. Not worth
> arguing about at the outset.
It's not a corner case. Having just one frame, with one dedicated
window, and killing the buffer has happened to me, and the result
(Emacs iconifying the frame) was the wrongest of wrong choices, though
killing it would've been even worse.
> But this should be the last thing to worry about. Debate it
> at the end if there is interest. It should not sidetrack
> fixing the bug, taking it down a rabbit hole to never-never
> land.
Sorry, I just don't believe it's a bug. I don't think killing a frame
because a buffer was deleted and its window was dedicated is the right
thing to do. At least, as a default behavior.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window
2014-02-16 4:33 ` Juanma Barranquero
@ 2014-02-16 6:37 ` Drew Adams
0 siblings, 0 replies; 7+ messages in thread
From: Drew Adams @ 2014-02-16 6:37 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 16768
> I just don't believe it's a bug.
A dedicated window is dedicated to a single buffer. Placing a
different buffer in a dedicated window is a bug. You need not
agree, of course.
> I don't think killing a frame because a buffer was deleted and
> its window was dedicated is the right thing to do. At least,
> as a default behavior.
Let the user pick the behavior.
With choices that include that behavior you don't like: delete
the dedicated window (and frame if alone in the frame) if the
buffer the window is dedicated to is killed.
And hopefully with the other user choices also fixing the bug,
one way or another: not allowing a different buffer to be shown
in a dedicated window.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window
2014-02-15 22:44 bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window Drew Adams
2014-02-15 22:56 ` Juanma Barranquero
@ 2014-02-16 10:33 ` martin rudalics
2014-02-16 16:53 ` Drew Adams
1 sibling, 1 reply; 7+ messages in thread
From: martin rudalics @ 2014-02-16 10:33 UTC (permalink / raw)
To: Drew Adams; +Cc: 16768
> This part of the `quit-restore-window' causes a special-display buffer,
> whose window is dedicated to it, to be replaced in that window by
> another buffer:
>
> (t
> ;; Show some other buffer in WINDOW and reset the quit-restore
> ;; parameter.
> (set-window-parameter window 'quit-restore nil)
> ;; Make sure that WINDOW is no more dedicated.
> (set-window-dedicated-p window nil)
> (switch-to-prev-buffer window bury-or-kill))
>
> If BURY-OR-KILL is `kill' then the window/frame should simply be
> deleted. A window dedicated to a particular buffer should not be reused
> for another buffer.
Optional second argument BURY-OR-KILL tells how to proceed with
the buffer of WINDOW.
so this is not related to whether the window or frame should be deleted.
> Consider, for example, a `special-display-frame-alist' that specifies
> certain frame attributes - e.g., a particular background color. You do
> not want to reuse such a frame for another buffer, especially for a non
> special-display buffer. The frame should be deleted when its buffer
> is killed.
IIUC a dedicated window is not deleted only if it was used before by
another buffer or it's the last window on the last frame. Can you give
a scenario with emacs -Q where such a window is not deleted?
martin
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window
2014-02-16 10:33 ` martin rudalics
@ 2014-02-16 16:53 ` Drew Adams
0 siblings, 0 replies; 7+ messages in thread
From: Drew Adams @ 2014-02-16 16:53 UTC (permalink / raw)
To: martin rudalics; +Cc: 16768
I debugged this more and found that the problem came from my
version of `special-display-popup-frame', whose only difference
from the vanilla version should be that it calls `fit-frame'
with the buffer's window selected and it inhibits calling
`fit-frame' (e.g. from hooks) before then.
My version had not been updated to reflect the latest vanilla
version, which correctly (a) calls `display-buffer-record-window'
first, and then calls `set-window-buffer' only if BUFFER is not
the buffer of `frame-selected-window'.
With that update, the bug is fixed. The problem was that
the Dired buffer was getting recorded as being used for the
new frame that pops up with the list of marked files.
I've closed this bug. Thx.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-02-16 16:53 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-15 22:44 bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window Drew Adams
2014-02-15 22:56 ` Juanma Barranquero
2014-02-16 2:41 ` Drew Adams
2014-02-16 4:33 ` Juanma Barranquero
2014-02-16 6:37 ` Drew Adams
2014-02-16 10:33 ` martin rudalics
2014-02-16 16:53 ` Drew Adams
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).