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

[Stephen Berman]

On Mon, 06 Mar 2017 18:46:40 +0100 martin rudalics <rudalics@gmx.at> wrote:

>>>> Same here (I couldn't test till just now).
>
> Thanks once more for installing and testing.
>
>> I think this window-splitting is because TeX-recenter-output-buffer
>> (bound to `C-c C-l') calls `(TeX-pop-to-buffer buffer t t)', which calls
>> pop-to-buffer with the ACTION argument set to t, which according to
>> pop-to-buffer's doc string " means to pop to a window other than the
>> selected one even if the buffer is already displayed in the selected
>> window".  Maybe AUCTeX should have a user option that can be passed as
>> the ACTION argument to pop-to-buffer.
>
> But if I do
>
> (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)
>
> (pop-to-buffer (get-buffer-create "*text*") t)
>
> everything works as expected.  IIUC something else must interfere here.
> How come the TeX source buffer gets "also" displayed on that new frame?

Oh, shame on me, I didn't look closely enough before; this is how:

   (defun TeX-recenter-output-buffer (line)
     "Redisplay buffer of TeX job output so that most recent output can be seen.
   The last line of the buffer is displayed on line LINE of the window, or
   at bottom if LINE is nil."
     (interactive "P")
     (let ((buffer (TeX-active-buffer)))
       (if buffer
        (let ((old-buffer (current-buffer)))
          (TeX-pop-to-buffer buffer t t)
          (bury-buffer buffer)
          (goto-char (point-max))
          (recenter (if line
                        (prefix-numeric-value line)
                      (/ (window-height) 2)))
          (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.

(*) 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.

Steve Berman