bug#7368: Testcase

[martin rudalics]

> In principle, in this very awkward situation display-buffer has 3 options:
>
> 1) To display buffer in selected window -- but not-in-this-window=t.
>
> 2) To display buffer in a new frame -- but pop-up-frames says we
> *never* make a separate frame.
>
> 3) To display buffer in place of completions window -- but that window
> is "dedicated".
>
> To me option 3 seems the least unexpected.

Anything can happen here.  If `display-buffer' doesn't find a better
window "the normal way", it may use the selected or the dedicated window
as well.

> Anyway, something needs to be fixed, as current documentation for
> pop-up-frames is wrong.

Most `display-buffer' related doc-strings are "wrong" in this regard.
They are based on behaviors where at least one approach gets through
"the normal way".  Note that `display-buffer' is supposed to _always_
return a window although you can easily set up options in a way that do
not allow to do that (as in your example).

We would have to introduce some sort of priority telling Emacs which
option is allowed to violate which restriction in which order, document
that, and confuse people even more.

BTW, you might want to have a look at my window-pub branch where all
`display-buffer' related options are combined in two almost identic
options called `display-buffer-names' and `display-buffer-regexps'.  The
doc-string of the former and its documentation are formulated in less
stringent terms.

>> BTW, the snippet
>>
>> (progn
>>  (delete-other-windows)
>>  (display-buffer (other-buffer) t))
>>
>> should be sufficient for exhibiting the behavior you observe.
>
> No, the completions buffer plays important role.

Make your frame small enough and you can see the problem here too.

martin