[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
Subject: Re: Does display-buffer display the buffer or not?
Date: Fri, 24 Dec 2010 10:31:58 +0100
User-agent: Thunderbird (Windows/20090302)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]