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

[Stephen Berman]

On Tue, 07 Mar 2017 20:00:14 +0100 martin rudalics <rudalics@gmx.at> wrote:

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

Normally, TeX-recenter-output-buffer is called (by `C-c C-l') from a
LaTeX source file, which is visited in old-buffer; though if you switch
to another buffer and invoke `M-x TeX-recenter-output-buffer' and the
output buffer exists, it will be displayed together with (by in the same
window and underneath) whatever the current buffer is.

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

That's in the exisiting definition; I don't know why, and don't see any
difference when I invoke this command with that line commented out.

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

This is to get the current standard behavior described above, i.e. in
the same frame with source buffer above and output buffer below.

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

I'm also not really familiar with the AUCTeX code, so I don't know if
this would cause problems elsewhere.

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

Will do.

Steve Berman