[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
Subject: bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist
Date: Tue, 07 Mar 2017 20:00:14 +0100

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]