Re: Does display-buffer display the buffer or not?

[martin rudalics]

> My first idea was that when you say NOT-THIS-WINDOW (t) and the current
> FRAME (nil), but the current frame has only one window and is only of
> minimal size, so no split can be done, then it must return nil and do
> nothing.  Unfortunately, testing that situation with
>
>   (display-buffer "*info*" t nil)
>
> pops up a completely new frame showing *info*.  Reading the docs a bit
> further, there is
>
> ,----[ C-h f display-buffer RET ]
> | [...]
> |
> | nil - consider windows on the selected frame (actually the
> | last non-minibuffer frame) only.  If, however, either
> | `display-buffer-reuse-frames' or `pop-up-frames' is non-nil
> | (non-nil and not graphic-only on a text-only terminal),
> | consider all visible or iconified frames.
> `----
>
> Unfortunately, both `display-buffer-reuse-frames' and `pop-up-frames'
> are nil, here.
>
> I do think that creating a new frame is appropriate in the situation
> above, but the docs should make that clear.  Currently, they don't match
> the implemented behavior.

The Elisp manual says

      If all options described above fail to produce a suitable window,
   `display-buffer' tries to reuse an existing window.  As a last resort,
   it will try to display BUFFER-OR-NAME on a separate frame.  In that
   case, the value of `pop-up-frames' is disregarded.

I never investigated whether this occurs in practice and what happens,
for example, on non-graphic displays.  It's just a fallback method and
I'm not sure whether it's worth mentioning in the doc-string.

martin