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

[martin rudalics]

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

I see.

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

Are you sure old-buffer is displayed in a window here?  Otherwise frame1
is just the frame of the selected window.

>                   frame2)
>              (TeX-pop-to-buffer buffer t t)
>              (setq frame2 (window-frame (get-buffer-window buffer)))
>              (bury-buffer buffer)

Why bury it?  To remove it from the selected window?  It might be in
another window.

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

Why this?

>                (select-frame-set-input-focus frame1)))
>           (message "No process for this document."))))

It might make sense to redefine that function but I have no idea what it
is supposed to do so I can't really comment on it.

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

Problems related to that commit might pop up any time with GTK now.  So
if you experience phenomenas similar to the ones you described earlier
please complain immediately.

Thanks, martin