bug#1259: quit-window does not kill the window

bug#1259: quit-window does not kill the window

[Juanma Barranquero]

Martin, I'm afraid I missed this comment by you:

"`quit-window' looks fishy in a number of regards: The `delete-frame'
stuff needs other_visible_frames to work correctly but this is not
available in Elisp.  I plan to commit somthing like the version below.
Could people please test whether it breaks their favorite use of this?"

But yes, it breaks one of my favorite uses.

The docstring previously said:

"If WINDOW is non-nil, it specifies a window; we delete that window,
and the buffer that is killed or buried is the one in that window."

Now, it says:

"If WINDOW
is dedicated or a minibuffer window, delete it and, if it's the
only window on its frame, delete its frame as well provided there
are other frames left.  Otherwise, display some other buffer in
the window."

I was using the previously documented behavior. I have a function

(defun quit-buffer-and-window ()
   (interactive)
   (quit-window nil (selected-window)))

(I assign it to "q" in many modes). Now,

  C-x 2 C-x o M-x quit-buffer-and-window <ENTER>

leaves me with two windows.

  Juanma

bug#1259: quit-window does not kill the window

[martin rudalics]

 > But yes, it breaks one of my favorite uses.
 >
 > The docstring previously said:
 >
 > "If WINDOW is non-nil, it specifies a window; we delete that window,
 > and the buffer that is killed or buried is the one in that window."
 >
 > Now, it says:
 >
 > "If WINDOW
 > is dedicated or a minibuffer window, delete it and, if it's the
 > only window on its frame, delete its frame as well provided there
 > are other frames left.  Otherwise, display some other buffer in
 > the window."
 >
 > I was using the previously documented behavior. I have a function
 >
 > (defun quit-buffer-and-window ()
 >    (interactive)
 >    (quit-window nil (selected-window)))
 >
 > (I assign it to "q" in many modes). Now,
 >
 >   C-x 2 C-x o M-x quit-buffer-and-window <ENTER>
 >
 > leaves me with two windows.

Sorry.  I apparently fail to understand what that function is supposed
to do.  Please try the version below and tell me whether it does what
you want.  If it still doesn't, then please try to write a doc-string so
I can implement what that doc-string says.

Thank you, martin.


(defun quit-window (&optional kill window)
   "Delete WINDOW and bury its buffer.
WINDOW defaults to the selected window.  Optional argument KILL
non-nil means kill WINDOW's buffer instead of burying it.

Always delete WINDOW if its frame contains at least one other
window.  If WINDOW is dedicated or a minibuffer window, and is
the only window on its frame, try to delete its frame too.  In
any other case, display another buffer in WINDOW."
   (interactive "P")
   (let* ((window (or window (selected-window)))
	 (buffer (window-buffer window)))
     (if (eq window (frame-root-window (window-frame window)))
	;; WINDOW is the only window on its frame.  `delete-windows-on'
	;; knows how to handle that particular case.
	(delete-windows-on buffer (selected-frame))
       ;; There are other windows left, delete just this window.  But
       ;; don't throw an error if that fails for some reason; rather
       ;; switch to another buffer instead.
       (condition-case nil
	  (delete-window window)
	(error (with-selected-window window
		 (switch-to-buffer nil)))))

     ;; Deal with the buffer.
     (if kill
	(kill-buffer buffer)
       (bury-buffer buffer))))

bug#1259: quit-window does not kill the window

[Juanma Barranquero]

On Fri, Nov 14, 2008 at 09:06, martin rudalics <rudalics@gmx.at> wrote:

> Sorry.  I apparently fail to understand what that function is supposed
> to do.

Truth be told, the docstring in 22.X wasn't very clear. The function
is called quit-window, but it talked about burying/killing the buffer,
and only off-handedly said:

"If window is non-nil, it specifies a window; we delete that window,
and the buffer that is killed or buried is the one in that window."

(Incidentally, that's the reason I defined quit-buffer-and-window in
the first place; with your changes, my function would be just an alias
for quit-window).

> Please try the version below and tell me whether it does what
> you want.

Yes, it works as expected now.

Thanks,

  Juanma

bug#1259: quit-window does not kill the window

[Juanma Barranquero]

On Fri, Nov 14, 2008 at 10:19, Juanma Barranquero <lekktu@gmail.com> wrote:

> Yes, it works as expected now.

To add more information: the difference in behavior between your
committed patch (let's call it v1) and the one you just sent (v2) is
related to defaulting to the selected window. I mean, with the
following defun

(defun my-quit-window ()
   (interactive)
   (quit-window nil (selected-window)))

and testing with

 emacs -Q
 C-h N
 M-x occur <ENTER> emacs <ENTER>
 C-x o
 M-x quit-window <ENTER>  ;; or M-x my-quit-window <ENTER>

In 22.X:

  M-x quit-window    => buries the buffer, keeps the window
  M-x my-quit-window => buries the buffer, kills the window

In 23.X, v1

  M-x quit-window    => buries the buffer, keeps the window
  M-x my-quit-window => buries the buffer, keeps the window

In 23.X, v2

  M-x quit-window    => buries the buffer, kills the window
  M-x my-quit-window => buries the buffer, kills the window

So, basically the original `quit-window' had two different behaviors,
while your patches just have one.

Personally, I'm happy with the "kills the window" behavior, so v2
works for me. But perhaps other people expects quit-window to behave
as it did in 22.X.

  Juanma

bug#1259: quit-window does not kill the window

[martin rudalics]

 > In 22.X:
 >
 >   M-x quit-window    => buries the buffer, keeps the window
[...]
 > In 23.X, v1
 >
 >   M-x quit-window    => buries the buffer, keeps the window
[...]

Thanks for investigating this.  I was to silly to figure it out.

Deleting the window iff it's explicitly specified strikes me as
non-intuitive.  Anyway, the version below should do that.

Please give it another try.

And thanks again for the explanations, martin.


(defun quit-window (&optional kill window)
   "Quit WINDOW and bury or kill its buffer.
WINDOW defaults to the selected window.

If WINDOW is dedicated or a minibuffer window, delete WINDOW and,
if it's alone on its frame, its frame too.  Else, if WINDOW was
explicitly specified and not nil, delete it.  Otherwise, or if
deleting WINDOW fails in any of the preceding cases, display
another buffer in WINDOW using `switch-to-buffer'.

Optional argument KILL non-nil means kill WINDOW's buffer.
Otherwise, bury WINDOW's buffer, see `bury-buffer'."
   (interactive "P")
   ;; Don't let-bind WINDOW here; below we want to know whether the
   ;; WINDOW argument was explictly specified.
   (let* ((window-to-handle (or window (selected-window)))
	 (buffer (window-buffer window-to-handle)))
     (cond
      ((or (window-minibuffer-p window-to-handle)
	  (window-dedicated-p window-to-handle))
       ;; Minibuffer windows and dedicated windows are treated specially.
       (let ((frame (window-frame window-to-handle)))
	(if (eq window-to-handle (frame-root-window frame))
	    ;; The window to handle is alone on its frame.
	    ;; `delete-windows-on' knows what to do.
	    (delete-windows-on buffer frame)
	  ;; There are other windows on the frame, delete this one.
	  (delete-window window-to-handle))))
      ((not window)
       ;; No WINDOW was specified.  Switch to another buffer in the
       ;; selected window.
       (switch-to-buffer nil))
      (t
       ;; WINDOW was specified, try to delete it.  But don't throw an
       ;; error if that fails; rather switch to another buffer instead.
       (condition-case nil
	  (delete-window window-to-handle)
	(error (with-selected-window window-to-handle
		 (switch-to-buffer nil))))))

     ;; Deal with the buffer.
     (if kill
	(kill-buffer buffer)
       (bury-buffer buffer))))

bug#1259: quit-window does not kill the window

[Juanma Barranquero]

On Fri, Nov 14, 2008 at 14:41, martin rudalics <rudalics@gmx.at> wrote:

> Deleting the window iff it's explicitly specified strikes me as
> non-intuitive.

I think quit-window conflates two interfaces, one for humans that does
not kill the window, and another for elisp that allows killing it;
that second interface does not need to be "interactively intuitive",
but certainly is not illogical (the programmer is taking the pain to
explicitly pass a window instead of using the default, after all). I
just happened to be using interactively the second interface.

> Anyway, the version below should do that.
>
> Please give it another try.

It works as expected now for quit-window and my-quit-window.

I've only tested my common use of the function, though: single frame,
one window (plus the one killed by quit-window).

Thanks for fixing this,

  Juanma

bug#1259: quit-window does not kill the window

[Markus Triska]

martin rudalics <rudalics@gmx.at> writes:

> Optional argument KILL non-nil means kill WINDOW's buffer.
> Otherwise, bury WINDOW's buffer, see `bury-buffer'."

Could you please mention the meaning of a prefix argument in interactive
use again? Previously, the docstring included the now missing sentence:

   With a prefix argument, kill the buffer instead.

C-u q is a great feature in many modes (doc-view-mode, image-mode etc.),
because it does not ask for which buffer to kill (in contrast to C-x k),
so I hope it remains available and documented. Thank you in advance!

bug#1259: quit-window does not kill the window

[martin rudalics]

 > It works as expected now for quit-window and my-quit-window.

I checked in a simpler version.  Could you try once more?

martin

bug#1259: quit-window does not kill the window

[martin rudalics]

> Could you please mention the meaning of a prefix argument in interactive
> use again? Previously, the docstring included the now missing sentence:
> 
>    With a prefix argument, kill the buffer instead.

It's there again.

martin

bug#1259: quit-window does not kill the window

[Juanma Barranquero]

On Sat, Nov 15, 2008 at 11:00, martin rudalics <rudalics@gmx.at> wrote:

> I checked in a simpler version.  Could you try once more?

Yes, it works as expected.

Thanks,

             Juanma