bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[martin rudalics <rudalics@gmx.at>]

 >     	  (TeX-pop-to-buffer old-buffer nil t))    ; <=================
 >           (message "No process for this document."))))
 >
 > The second invocation of TeX-pop-to-buffer displays the source buffer;
 > commenting this out appears to give the result the OP wants.(*)  So to
 > satisfying both this use case and the one foreseen for this function,
 > the second invocation could be conditioned on a user option.

This indeed confers to the behavior described by Jens.  Does the second
argument "nil" mean to stay on the selected frame?

In any case, this order of invocations is asking for trouble when the
output buffer should appear on a separate frame.  The old code worked
around this problem because of the (unsplittable . t) default entry in
‘special-display-frame-alist’.  So Jens probably needs something like

(customize-set-variable
  'display-buffer-alist
  '(("\\*text\\*"
     (display-buffer-reuse-window display-buffer-pop-up-frame)
     (reusable-frames . t))))

(setq display-buffer-mark-dedicated t)
(setq pop-up-frame-alist (cons '(unsplittable . t) pop-up-frame-alist))

(pop-to-buffer (get-buffer-create "*text*") t)

and we are back in the strong grip of global variables, something the
"new" implementation of ‘display-buffer’ was supposed to avoid.  We
can't escape our past.

 > (*) I should note that on some tests I made with the second invocation
 > commented out I got strange results: once or twice, the frame in which
 > the LaTeX output is displayed did split, showing the *Messages* buffer
 > below (but with a reduced height); and several times, after killing the
 > output buffer (and hence its frame), keyboard input was totally blocked,
 > though mouse input was possible.  I have not been able to reliably
 > reproduce these effects.

This is probably due to

commit 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7
Author: Noam Postavsky <npostavs@gmail.com>
Date:   Fri Jan 13 19:47:22 2017 -0500

     Don't wait for frame to become visible

Can you try to selectively revert that commit and see whether the
problem persists?

martin