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

[Stephen Berman <stephen.berman@gmx.net>]

On Tue, 07 Mar 2017 10:45:24 +0100 martin rudalics <rudalics@gmx.at> wrote:

>>     	  (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?

It's actually passed to pop-to-buffer's ACTION argument, which is hence
nil here.  TeX-pop-to-buffer's signature calls it OTHER-WINDOW, which
was pop-to-buffer's second parameter before it was replaced by ACTION
(TeX-pop-to-buffer is just a wrapper around pop-to-buffer for
compatibility with XEmacs.)

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

TeX-recenter-output-buffer could be redefined as follows to get the same
result (according to my tests) without resorting to pop-up-frame-alist:

   (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))
   	       (frame1 (window-frame (get-buffer-window old-buffer)))
   	       frame2)
   	  (TeX-pop-to-buffer buffer t t)
   	  (setq frame2 (window-frame (get-buffer-window buffer)))
   	  (bury-buffer buffer)
   	  (goto-char (point-max))
   	  (recenter (if line
   			(prefix-numeric-value line)
   		      (/ (window-height) 2)))
   	  (if (eq frame1 frame2)
   	      (TeX-pop-to-buffer old-buffer nil t)
   	    (select-frame-set-input-focus frame1)))
         (message "No process for this document."))))

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

I suppose I could try to revert, but since I can't reliably reproduce
the problems, not seeing them after reverting may not be conclusive.
(For example, so far testing the above redefinition of TeX-pop-to-buffer
has not shown the problems.)

Steve Berman