bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window

bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window

[Drew Adams]

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'

bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window

[Juanma Barranquero]

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

bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window

[Drew Adams]

> > 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.

bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window

[Juanma Barranquero]

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.

bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window

[Drew Adams]

> 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.

bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window

[martin rudalics]

 > 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

bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces special-display buffer in its dedicated window

[Drew Adams]

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.