quit-window

quit-window

[Christoph Scholtes]

quit-window bound to `q' in a keymap provides a nice, consistent UI for
getting rid of the window and killing/burying its buffer.

However, some modes are inhibiting consistency by wrapping quit-window
in a function, which in most cases performs some kind of cleanup. This
creates inconsistency in the interface since, for example, `C-u q' to
kill the buffer is not available anymore unless the wrapper passes on
the argument to quit-window.

Take for example `info-emacs-manual', which provides `Info-exit' bound
to `q' in its map. `q' will quit the window and bury the buffer, but
`C-u q' will *not* kill the buffer.

I have identified at least 18 modes that do something similar. Maybe
some special case even needs to, but most of the time it could be
cleaned up, IMO.

Also, some of these exit wrappers explicitely restore a previous
window configuration. Doesn't quit-window handle that already?

Finally, if there is mode-specific cleanup to be done, could we provide
a quit-window-hook to connect to so we can eliminate the need for
wrappers?

This would allow a more consistent behavior between the modes. Maybe
it's just me, but often I am surprised as a user by the difference in
behavior of certain commands, especially when it comes to window
manipulation (quit, kill, bury etc.).

Christoph

Re: quit-window

[Chong Yidong]

Christoph Scholtes <cschol2112@googlemail.com> writes:

> some modes are inhibiting consistency by wrapping quit-window in a
> function, which in most cases performs some kind of cleanup. This
> creates inconsistency in the interface since, for example, `C-u q' to
> kill the buffer is not available anymore unless the wrapper passes on
> the argument to quit-window.
>
> Finally, if there is mode-specific cleanup to be done, could we provide
> a quit-window-hook to connect to so we can eliminate the need for
> wrappers?

Yes, good idea.  I don't think it's that urgent, though; it can wait for
post 24.1.

Re: quit-window

[Christoph Scholtes]

Chong Yidong <cyd@stupidchicken.com> writes:

>> Finally, if there is mode-specific cleanup to be done, could we provide
>> a quit-window-hook to connect to so we can eliminate the need for
>> wrappers?
>
> Yes, good idea.  I don't think it's that urgent, though; it can wait for
> post 24.1.

OK. Should I add an item to the TODO or is there another place to
capture items like this, i.e. a tracker item?

Re: quit-window

[Chong Yidong]

Christoph Scholtes <cschol2112@googlemail.com> writes:

> OK. Should I add an item to the TODO or is there another place to
> capture items like this, i.e. a tracker item?

Use the bug tracker.

Re: quit-window

[Richard Stallman]

"Quitting" a window just means returning to a different window or
buffer configuration, after a change that is thought of as temporary.
As far as buffers are concerned, it is no different from any other
change in selection.  That's not supposed to change anything about
any buffer.

Thus, if a mode tries to do something nontrivial to the buffer on the
occasion of quitting, that makes me worry.  Should that be done at
all?

    I have identified at least 18 modes that do something similar. Maybe
    some special case even needs to, but most of the time it could be
    cleaned up, IMO.

I think we need to study carefully what things they do, and whether there
is a good reason for them.

I looked at Info-exit and it seems ok, because it is only doing
something special in the case of stand-alone Info.

(Is stand-alone Info obsolete?  We have a separate program, in C, to
do that.)

Maybe others are similarly superfluous and can be replaced with
quit-window.

Maybe others do things that aren't necessary, creating inconsistency
we would be better off without.

Maybe some others do special things for good reason -- if so, what are
those things?  Would some narrow and specific features be good
solutions for them?

We don't want to install these changes now, but there's no need to
delay the studying.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: quit-window

[Eli Zaretskii]

> Date: Mon, 24 Oct 2011 12:39:22 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> (Is stand-alone Info obsolete?  We have a separate program, in C, to
> do that.)

This sounds like by "stand-alone Info" you mean something other than
the stand-alone Info reader, a C program that is part of the Texinfo
package?  That one is not obsolete (I think; Karl should know for
sure).

I'm not aware of any "stand-alone Info" except that C program.

Re: quit-window

[martin rudalics]

 > This sounds like by "stand-alone Info" you mean something other than
 > the stand-alone Info reader, a C program that is part of the Texinfo
 > package?  That one is not obsolete (I think; Karl should know for
 > sure).
 >
 > I'm not aware of any "stand-alone Info" except that C program.

C-h f info-standalone

martin

Re: quit-window

[Richard Stallman]

    This sounds like by "stand-alone Info" you mean something other than
    the stand-alone Info reader, a C program that is part of the Texinfo
    package?

I mean stand-alone Info based on Emacs.  Look at the
definition of Info-exit, and you'll see what I mean.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: quit-window

[Christoph Scholtes]

Richard Stallman <rms@gnu.org> writes:

> As far as buffers are concerned, it is no different from any other
> change in selection.  That's not supposed to change anything about
> any buffer.

Except for the buffer associated with the temporary window, right? If the
content of the window is of temprary nature (in most cases) I would want
to kill the associated buffer when the window is quit.

> Thus, if a mode tries to do something nontrivial to the buffer on the
> occasion of quitting, that makes me worry.  Should that be done at
> all?

That would have to be decided on a case by case basis, I think. 

>     I have identified at least 18 modes that do something similar. Maybe
>     some special case even needs to, but most of the time it could be
>     cleaned up, IMO.
>
> I think we need to study carefully what things they do, and whether there
> is a good reason for them.

I agree. I basically just looked for cases where the keymap bound `q',
but did not bind it to quit-window, but some other function,
e.g. ibuffer-quit.

Take this:

(defun ibuffer-quit ()
  "Quit this `ibuffer' session.
Try to restore the previous window configuration if
`ibuffer-restore-window-config-on-quit' is non-nil."
  (interactive)
  (if ibuffer-restore-window-config-on-quit
      (progn
	(bury-buffer)
	(unless (= (count-windows) 1)
	  (set-window-configuration ibuffer-prev-window-config)))
    (bury-buffer)))

Here I am wondering if the same couldn't be achieved by a call to
(the new and improved) `quit-window'.

> I looked at Info-exit and it seems ok, because it is only doing
> something special in the case of stand-alone Info.

It wraps `quit-window' in a way that I cannot use `C-u q' to quit the
window and *kill* the buffer, though. 

Something like

(defun Info-exit (kill)
  "Exit Info by selecting some other buffer."
  (interactive "P")
  (if Info-standalone
      (save-buffers-kill-emacs)
    (quit-window kill)))

would allow that and be consistent with other cases where `q' binds
`quit-window' directly. The next step would then be the previously
discussed `quit-window-hook' to move the additional functionality to (if
applicable).

> We don't want to install these changes now, but there's no need to
> delay the studying.

I will create a list of the occurrences I found and look at if (and what)
functionality would get lost if the function used `quit-window'. This is
obviously only for cases where the additional functionality deals with
window management.

Christoph

Re: quit-window

[martin rudalics]

 > Take this:
 >
 > (defun ibuffer-quit ()
 >   "Quit this `ibuffer' session.
 > Try to restore the previous window configuration if
 > `ibuffer-restore-window-config-on-quit' is non-nil."
 >   (interactive)
 >   (if ibuffer-restore-window-config-on-quit
 >       (progn
 > 	(bury-buffer)
 > 	(unless (= (count-windows) 1)
 > 	  (set-window-configuration ibuffer-prev-window-config)))
 >     (bury-buffer)))

The problem is already in `ibuffer' itself:

   (setq ibuffer-prev-window-config (current-window-configuration))
   (let ((buf (get-buffer-create (or name "*Ibuffer*"))))
     (if other-window-p
	(funcall (if noselect (lambda (buf) (display-buffer buf t)) #'pop-to-buffer) buf)
       (funcall (if noselect #'display-buffer #'switch-to-buffer) buf))

Saving the window configuration doesn't make sense if one of the
funcalls makes a new frame.

 > Here I am wondering if the same couldn't be achieved by a call to
 > (the new and improved) `quit-window'.

I hope it does.  But this is something users of ibuffer should try
first.

 > Something like
 >
 > (defun Info-exit (kill)

KILL should be optional here.

martin

Re: quit-window

[Richard Stallman]

    > As far as buffers are concerned, it is no different from any other
    > change in selection.  That's not supposed to change anything about
    > any buffer.

    Except for the buffer associated with the temporary window, right? If the
    content of the window is of temprary nature (in most cases) I would want
    to kill the associated buffer when the window is quit.

Yes, it sometimes does kill the buffer.  But that should work like
killing the same buffer through any other command.

    > Thus, if a mode tries to do something nontrivial to the buffer on the
    > occasion of quitting, that makes me worry.  Should that be done at
    > all?

    That would have to be decided on a case by case basis, I think. 

We need to start by deciding them case by case.  But if we see enough
cases, we might be able to adduce some general rules about how to
handle them.

    > I looked at Info-exit and it seems ok, because it is only doing
    > something special in the case of stand-alone Info.

    It wraps `quit-window' in a way that I cannot use `C-u q' to quit the
    window and *kill* the buffer, though. 

You're right that it has a bug.  My point is that the basic idea of
using a special `Info-exit' command is reasonable.  There is no reason
why `quit-window' should try to handle any special needs of
stand-alone Info in Emacs.

However, if stand-alone Info in Emacs is obsolete, we can just delete
`Info-exit' and use `quit-window' directly.

    but did not bind it to quit-window, but some other function,
    e.g. ibuffer-quit.

    Here I am wondering if the same couldn't be achieved by a call to
    (the new and improved) `quit-window'.

It could be so.  Anyway, what we see here is special manipulation of
the window configuration.  That's the sort of thing that makes sense
for `quit-window' to do.  So if it doesn't already do everything
that's most useful for ibuffer, maybe we should extend `quit-window'
to do whatever it is.

    I will create a list of the occurrences I found and look at if (and what)
    functionality would get lost if the function used `quit-window'. This is
    obviously only for cases where the additional functionality deals with
    window management.

That seems like a very useful thing to do.



-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: quit-window

[martin rudalics]

 > quit-window bound to `q' in a keymap provides a nice, consistent UI for
 > getting rid of the window and killing/burying its buffer.

But only when you are viewing a buffer.

 > However, some modes are inhibiting consistency by wrapping quit-window
 > in a function, which in most cases performs some kind of cleanup. This
 > creates inconsistency in the interface since, for example, `C-u q' to
 > kill the buffer is not available anymore unless the wrapper passes on
 > the argument to quit-window.
 >
 > Take for example `info-emacs-manual', which provides `Info-exit' bound
 > to `q' in its map. `q' will quit the window and bury the buffer, but
 > `C-u q' will *not* kill the buffer.

I think this could be fixed by changing `Info-exit' appropriately.  The
prefix argument should be passed on to `quit-window'.  (We can't run
`quit-window' directly in Info-mode since we have to deal with the
Info-standalone case.)

 > I have identified at least 18 modes that do something similar. Maybe
 > some special case even needs to, but most of the time it could be
 > cleaned up, IMO.

These were written before I rewrote `quit-window'.  Indeed I shall have
to look into these.

 > Also, some of these exit wrappers explicitely restore a previous
 > window configuration. Doesn't quit-window handle that already?

It should do better, because `quit-window' is able to quit a window
shown on another frame too.  So all this configuration stuff should be
eliminated eventually.

 > Finally, if there is mode-specific cleanup to be done, could we provide
 > a quit-window-hook to connect to so we can eliminate the need for
 > wrappers?
 >
 > This would allow a more consistent behavior between the modes. Maybe
 > it's just me, but often I am surprised as a user by the difference in
 > behavior of certain commands, especially when it comes to window
 > manipulation (quit, kill, bury etc.).

You mean that `kill-buffer-hook' is not sufficient for you?  One problem
with a simple quit-window-hook is that it could falsely create the
impression that after `quit-window' the associated buffer is no more
displayed at all.  This might be wrong.  Basically, what you need is
provided by `window-configuration-change-hook'.  The problem with the
latter is that application programmers don't know how to use it because
they can't know _what_ precisely has changed.  That information would
have to be provided somewhere, somehow.  Suggestions welcome.

martin

Re: quit-window

[Juri Linkov]

>> quit-window bound to `q' in a keymap provides a nice, consistent UI for
>> getting rid of the window and killing/burying its buffer.
>
> But only when you are viewing a buffer.

BTW, what do you think about adding to window.el something like:

  (defun quit-window-kill-buffer ()
    "Quit WINDOW and kill its buffer."
    (interactive)
    (quit-window t))

The problem is that for some modes it's desirable to kill buffers as well
when quitting.  Then it would be easier to put in .emacs:

  (define-key dired-mode-map "q" 'quit-window-kill-buffer)

Or even better to add a new customizable variable with a list of modes
where `q' kills the buffer, e.g. `quit-window-kill-buffer-modes'
that could be customized to add modes like `dired-mode'.

Re: quit-window

[Christoph Scholtes]

Juri Linkov <juri@jurta.org> writes:

> BTW, what do you think about adding to window.el something like:
>
>   (defun quit-window-kill-buffer ()
>     "Quit WINDOW and kill its buffer."
>     (interactive)
>     (quit-window t))
>
> The problem is that for some modes it's desirable to kill buffers as well
> when quitting.

`C-u q' will kill the buffer instead of burying it.

I actually prefer to kill the buffer by default so I have this in my
.emacs:

;; Advise quit-window to kill buffer instead of burying it
(defadvice quit-window (before advise-quit-window activate)
  (ad-set-arg 0 (not (ad-get-arg 0))))

Christoph

Re: quit-window

[martin rudalics]

 > BTW, what do you think about adding to window.el something like:
 >
 >   (defun quit-window-kill-buffer ()
 >     "Quit WINDOW and kill its buffer."
 >     (interactive)
 >     (quit-window t))
 >
 > The problem is that for some modes it's desirable to kill buffers as well
 > when quitting.  Then it would be easier to put in .emacs:
 >
 >   (define-key dired-mode-map "q" 'quit-window-kill-buffer)
 >
 > Or even better to add a new customizable variable with a list of modes
 > where `q' kills the buffer, e.g. `quit-window-kill-buffer-modes'
 > that could be customized to add modes like `dired-mode'.

Is there any reason why one should not use C-x k here?

martin

Re: quit-window

[Juri Linkov]

>>   (define-key dired-mode-map "q" 'quit-window-kill-buffer)
>>
>> Or even better to add a new customizable variable with a list of modes
>> where `q' kills the buffer, e.g. `quit-window-kill-buffer-modes'
>> that could be customized to add modes like `dired-mode'.
>
> Is there any reason why one should not use C-x k here?

Actually both are necessary: `quit-window-kill-buffer' and
`kill-this-buffer' (I consider it instead of `kill-buffer'
because it's easier to use in .emacs and it doesn't require
confirmation from the user to kill the current buffer).

There are use cases where one of them is more suitable:

`quit-window-kill-buffer' is useful when you need to return to the
initial window from which this buffer was displayed and also to delete
the window when the current buffer is last in its window history.

Sometimes this behavior is dangerous, e.g. when wanting to
kill all buffers visited in the selected window one by one,
I start typing a key bound to `quit-window-kill-buffer'
repeatedly, and sometimes it jumps to another window, and
not noticing this jump, the next keypress kills the wrong buffer.
`kill-this-buffer' doesn't jump to another window, so it's safer
to use it to kill all previously visited buffers in the selected window.

Re: quit-window

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> `quit-window-kill-buffer' is useful when you need to return to the
> initial window from which this buffer was displayed and also to delete
> the window when the current buffer is last in its window history.
>
> Sometimes this behavior is dangerous, e.g. when wanting to kill all
> buffers visited in the selected window one by one,

I don't think it's necessary to introduce a separate command for this.
If we introduce a quit-window-hook, you can add a hook function that
conditionally kills the buffer based on its major mode.

Re: quit-window

[Juri Linkov]

> I don't think it's necessary to introduce a separate command for this.
> If we introduce a quit-window-hook, you can add a hook function that
> conditionally kills the buffer based on its major mode.

Or better `quit-window-alist' as a counterpart to `display-buffer-alist'.

Ah, now I recall that I already proposed that, and Stefan said that
the behavior of quit-window can be specified when displaying the buffer
and/or creating the window.

So perhaps `quit-window-hook' is not necessary too, and such specific
window-quitting as e.g. checking for `Info-standalone' could be specified
when creating a window with the *Info* buffer.

Re: quit-window

[Christoph Scholtes]

martin rudalics <rudalics@gmx.at> writes:

>> quit-window bound to `q' in a keymap provides a nice, consistent UI for
>> getting rid of the window and killing/burying its buffer.
>
> But only when you are viewing a buffer.

Yes. I was referring to viewing buffers in `special-mode'.

> I think this could be fixed by changing `Info-exit' appropriately.  The
> prefix argument should be passed on to `quit-window'.  (We can't run
> `quit-window' directly in Info-mode since we have to deal with the
> Info-standalone case.)

Yes. You could do that as a short-term solution, but long term that a
kludge. There are so many of these `exit-wrappers' that could be
eliminated with a more consistent interface.

>> I have identified at least 18 modes that do something similar. Maybe
>> some special case even needs to, but most of the time it could be
>> cleaned up, IMO.
>
> These were written before I rewrote `quit-window'.  Indeed I shall have
> to look into these.

I will provide a list of the ones I have found.

>> Also, some of these exit wrappers explicitely restore a previous
>> window configuration. Doesn't quit-window handle that already?
>
> It should do better, because `quit-window' is able to quit a window
> shown on another frame too.  So all this configuration stuff should be
> eliminated eventually.

Excellent, that's what I thought. 

> You mean that `kill-buffer-hook' is not sufficient for you?  One problem
> with a simple quit-window-hook is that it could falsely create the
> impression that after `quit-window' the associated buffer is no more
> displayed at all.  This might be wrong.  Basically, what you need is
> provided by `window-configuration-change-hook'.  The problem with the
> latter is that application programmers don't know how to use it because
> they can't know _what_ precisely has changed.  That information would
> have to be provided somewhere, somehow.  Suggestions welcome.

No, `kill-buffer-hook' is too general, IMO. What if the buffer is buried
and not killed? `quit-window-hook' would be a hook that is mainly used
internally by modes to do their mode-specific cleanup before calling
`quit-window'. `window-configuration-change-hook' also seems to be too
general.

We have to distinguish between two cases when calling the
`quit-window-hook':

1. quit-window, buffer killed, clean up
2. quit-window, buffer buried, maybe do nothing?

All of this decision making could be moved to the `quit-window-hook' so
only modes that care implement it.

Christoph

Re: quit-window

[martin rudalics]

 >> I think this could be fixed by changing `Info-exit' appropriately.  The
 >> prefix argument should be passed on to `quit-window'.  (We can't run
 >> `quit-window' directly in Info-mode since we have to deal with the
 >> Info-standalone case.)
 >
 > Yes. You could do that as a short-term solution, but long term that a
 > kludge. There are so many of these `exit-wrappers' that could be
 > eliminated with a more consistent interface.

W'de have to handle this test

   (if Info-standalone
       (save-buffers-kill-emacs)
     (quit-window)))

somehow without creating surprises for people using the standalone
version.

 >>> I have identified at least 18 modes that do something similar. Maybe
 >>> some special case even needs to, but most of the time it could be
 >>> cleaned up, IMO.
 >> These were written before I rewrote `quit-window'.  Indeed I shall have
 >> to look into these.
 >
 > I will provide a list of the ones I have found.

You might also try patching (some of) them right away so we know whether
there are any pitfalls ;-)

 > No, `kill-buffer-hook' is too general, IMO. What if the buffer is buried
 > and not killed? `quit-window-hook' would be a hook that is mainly used
 > internally by modes to do their mode-specific cleanup before calling
 > `quit-window'. `window-configuration-change-hook' also seems to be too
 > general.
 >
 > We have to distinguish between two cases when calling the
 > `quit-window-hook':
 >
 > 1. quit-window, buffer killed, clean up
 > 2. quit-window, buffer buried, maybe do nothing?
 >
 > All of this decision making could be moved to the `quit-window-hook' so
 > only modes that care implement it.

The problem is that the more hooks we have in one call, the more the
order in which these hooks are executed does matter.  For example, I
believe that when I run `kill-buffer', `kill-buffer-hook' is called
before `window-configuration-change-hook'.  When I run `quit-window'
with the first argument t, the order seems
`window-configuration-change-hook', `kill-buffer-hook', and possibly
another `window-configuration-change-hook' if the buffer was displayed
in a second window.  This is already very confusing for me in current
Emacs.

martin

Re: quit-window

[Christoph Scholtes]

martin rudalics <rudalics@gmx.at> writes:

> W'de have to handle this test
>
>   (if Info-standalone
>       (save-buffers-kill-emacs)
>     (quit-window)))
>
> somehow without creating surprises for people using the standalone
> version.

What surprises are you thinking of?

> You might also try patching (some of) them right away so we know whether
> there are any pitfalls ;-)

Yes, for short term the most annoying instancse can be fixed without a hook.

> The problem is that the more hooks we have in one call, the more the
> order in which these hooks are executed does matter.  For example, I
> believe that when I run `kill-buffer', `kill-buffer-hook' is called
> before `window-configuration-change-hook'.  When I run `quit-window'
> with the first argument t, the order seems
> `window-configuration-change-hook', `kill-buffer-hook', and possibly
> another `window-configuration-change-hook' if the buffer was displayed
> in a second window.  This is already very confusing for me in current
> Emacs.

That does seem confusing. I wonder why there are differences.

Re: quit-window

[martin rudalics]

 >> W'de have to handle this test
 >>
 >>   (if Info-standalone
 >>       (save-buffers-kill-emacs)
 >>     (quit-window)))
 >>
 >> somehow without creating surprises for people using the standalone
 >> version.
 >
 > What surprises are you thinking of?

If, in info.el we replace

     (define-key map "q" 'Info-exit)

by

     (define-key map "q" 'quit-window)

anyone who reads Info with the standalone reader won't have his emacs
killed when she types "q".  This would be surprising.

 >> The problem is that the more hooks we have in one call, the more the
 >> order in which these hooks are executed does matter.  For example, I
 >> believe that when I run `kill-buffer', `kill-buffer-hook' is called
 >> before `window-configuration-change-hook'.  When I run `quit-window'
 >> with the first argument t, the order seems
 >> `window-configuration-change-hook', `kill-buffer-hook', and possibly
 >> another `window-configuration-change-hook' if the buffer was displayed
 >> in a second window.  This is already very confusing for me in current
 >> Emacs.
 >
 > That does seem confusing. I wonder why there are differences.

It makes sense to run `kill-buffer-hook' immediately after running the
`kill-buffer-query-functions' with the buffer to be killed current.
Only after that emacs decides that the buffer shall be removed from
display.  That `quit-window' first removes the window and then decides
whether to kill the buffer wouldn't be easy to change (mostly because
people don't like that `kill-buffer' calls `quit-window').

martin

quit-window

[martin rudalics]

The doc-string of `quit-window' says

(defun quit-window (&optional kill window)
   "Quit the current buffer.  Bury it, and maybe delete the selected frame.
\(The frame is deleted if it contains a dedicated window for the buffer.)
With a prefix argument, kill the buffer instead.

Noninteractively, if KILL is non-nil, then kill the current buffer,
otherwise bury it.

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

The following parts seem dubious:

- "Quit the current buffer."

   The function is called `quit-window' its doc-string says "quit the
   current buffer".  Since the current buffer is not necessarily the
   buffer displayed in the selected window this sentence is both
   misleading and wrong.

- "Bury it, and maybe delete the selected frame."

   KILL non-nil will kill the buffer, not bury it.  WINDOW non-nil will
   affect WINDOW's frame, not the selected frame.

- "\(The frame is deleted if it contains a dedicated window for the buffer.)"

   Only if there are no other windows on that frame.

- "Noninteractively, if KILL is non-nil, then kill the current buffer,
   otherwise bury it."

   "current buffer" and "bury" are misleading again.

Could someone with a good sense of what's going on in this function
improve that?  Also

       (and (or (window-minibuffer-p) (window-dedicated-p window))

should probably become

       (and (or (window-minibuffer-p window) (window-dedicated-p window))