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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16768 in the body.
You can then email your comments to 16768 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; `quit-restore-window' with KILL=t replaces special-display
 buffer in its dedicated window
Date: Sat, 15 Feb 2014 14:44:31 -0800 (PST)

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 <at> 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'

Message #8 received at 16768 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 16768 <at> debbugs.gnu.org
Subject: Re: bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces
 special-display buffer in its dedicated window
Date: Sat, 15 Feb 2014 23:56:08 +0100

On Sat, Feb 15, 2014 at 11:44 PM, Drew Adams <drew.adams <at> 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

Message #11 received at 16768 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 16768 <at> debbugs.gnu.org
Subject: RE: bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces
 special-display buffer in its dedicated window
Date: Sat, 15 Feb 2014 18:41:32 -0800 (PST)

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

Message #14 received at 16768 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 16768 <at> debbugs.gnu.org
Subject: Re: bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces
 special-display buffer in its dedicated window
Date: Sun, 16 Feb 2014 05:33:25 +0100

On Sun, Feb 16, 2014 at 3:41 AM, Drew Adams <drew.adams <at> 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.

Message #17 received at 16768 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 16768 <at> debbugs.gnu.org
Subject: RE: bug#16768: 24.3.50; `quit-restore-window' with KILL=t replaces
 special-display buffer in its dedicated window
Date: Sat, 15 Feb 2014 22:37:36 -0800 (PST)

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

Message #20 received at 16768 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 16768 <at> debbugs.gnu.org
Subject: Re: bug#16768: 24.3.50;	`quit-restore-window' with KILL=t replaces
 special-display buffer in	its dedicated window
Date: Sun, 16 Feb 2014 11:33:20 +0100

> 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

Message #23 received at 16768 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 16768 <at> debbugs.gnu.org
Subject: RE: bug#16768: 24.3.50;	`quit-restore-window' with KILL=t replaces
 special-display buffer in	its dedicated window
Date: Sun, 16 Feb 2014 08:53:59 -0800 (PST)

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.