Re: Help with windows and 'quit-restore

[martin rudalics]

> I found the root of the behavior that was making me think I was crazy.
> Basically I'm trying to replicate the behavior of this call:
>
> (display-buffer "some buffer" '(display-buffer-pop-up-window))

The signature of ‘display-buffer’ is

  (display-buffer BUFFER-OR-NAME &optional ACTION FRAME)

while

> But in a way that I can reliably select which window gets split to show
> the pop up. (I'd still rather just be using `display-buffer', but that's
> a different subject.)
>
> This should be the lower-level equivalent:
>
> (let ((buf "*scratch*")
>       (new-window
>        (split-window (selected-window))))
>   (set-window-buffer new-window buf)
>   (display-buffer-record-window 'window new-window buf)
>   (set-window-prev-buffers new-window nil))

that of ‘display-buffer-record-window’ is

(display-buffer-record-window TYPE WINDOW BUFFER)

So the latter has no optional arguments (which is some sort of reminder
that the function is more strict in the interpretation of its arguments)
and uses BUFFER instead of BUFFER-OR-NAME (which means that it does not
allow a buffer name as argument).  This distinction is valuable when
coding with ‘eldoc-mode’: Whenever you see BUFFER-OR-NAME in the
argument list you know you are at the "user" level where more things are
allowed and more things are checked.  When you see plain BUFFER you know
you are at a "coder" level where less things are allowed and less things
are checked.

> But it doesn't kill the window after calling `quit-window'. This is
> apparently because `quit-restore-window' decides whether or not to kill
> the window by checking (window.el:4766):
>
> (eq (nth 3 quit-restore) buffer)
>
> There's no call to `get-buffer' anywhere down the line, so (nth 3
> quit-restore) is a buffer string name, while buffer is a buffer object.
> Ergo, no kill window. If I'd started with a `get-buffer' in the let form
> above, all would have been well. `display-buffer' calls `get-buffer'
> first thing, so you don't see it there.

Right.  ‘display-buffer’ is "user" level while
‘display-buffer-record-window’ is "coder" level.  What you do is
"coding" and you are supposed to know what you do.

> I don't know if this is a bug -- I'm the one insisting on doing it
> manually, after all -- but it also wouldn't hurt to put a `get-buffer'
> in `display-buffer-record-window' and ensure that it's always a buffer
> object that gets recorded in the quit-restore parameter.

I have tried to use BUFFER-OR-NAME and BUFFER in a consistent manner
throughout the window.el code base.  If you compare the current code
with earlier versions you will notice that this required some work.  See
the ‘window-normalize-buffer’ function which interprets nil as meaning
the current buffer and does not allow a string to name a non-existent
buffer.  All these checks are meant for catching user errors and are
redundant at lower levels.  So I'd rather not change that.

> Or maybe, because the buffer might get deleted at any time, allow a
> string and improve the check in `quit-restore-window'?

Why?  When calling ‘quit-restore-window’

(buffer (window-buffer window))

will get me a valid buffer while

(nth 3 quit-restore)

will get me a killed buffer so

(eq (nth 3 quit-restore) buffer)

should be

> Either way, I vote adding some sort of safety.

safe enough.  Don't you agree?

> I'm still up for doc suggestions, once I'm confident I actually
> understand what's happening.

We should move our discussion to emcs-devel, also because I'm not
subscribed to help-gnu-emacs.  There you will also find a patch for
bug#25946 which incorporates your earlier proposal to clear the list of
previous buffers in ‘display-buffer-record-window’.

martin