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

[Tassilo Horn]

martin rudalics <address@hidden> writes:

Hi Martin,

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

Ok, I see.

> I never investigated whether this occurs in practice and what happens,
> for example, on non-graphic displays.

In ttys it also creates a new frame with that buffer.  You cannot see
that there is a new frame, except that you have to to C-x 5 0 twice to
return to the command line (when tty frame was created by emacsclient)
or to get the message that one cannot delete the only frame (with emacs
-nw -Q), and

  (frames-on-display-list)

returns 2 frames.

Hm, is it sensible to have multiple frames on one tty?  You can only see
one at a time anyway...

> It's just a fallback method and I'm not sure whether it's worth
> mentioning in the doc-string.

Yes, IMO, it is.  And the "nil if no such window is found" should be
removed.  The fallback ensures that a window will always be found,
right?

With the current spelling, I read the docs like "the function caller
should check that the return-value of display-buffer is nil, and if it
is, act appropriately by creating a new frame, for example."

Bye,
Tassilo