From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist Date: Tue, 07 Mar 2017 17:51:22 +0100 Message-ID: <87r32958tx.fsf@rosalinde> References: <877f46d6go.fsf@wi.uni-muenster.de> <58B947A2.5040001@gmx.at> <87zih2bp98.fsf@wi.uni-muenster.de> <58B97CAF.6060600@gmx.at> <87varqe7pd.fsf@wi.uni-muenster.de> <58B9B496.2020100@gmx.at> <58BAFBFF.6060706@gmx.at> <58BBE9B9.80202@gmx.at> <87pohwhsjq.fsf@rosalinde> <58BC1289.30800@gmx.at> <878tojfjru.fsf@drachen> <87efyaail6.fsf@rosalinde> <8737eqoiz4.fsf@wi.uni-muenster.de> <8737eqacjc.fsf@rosalinde> <58BDA080.5010109@gmx.at> <87h93686kk.fsf@rosalinde> <58BE8134.6000907@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1488905600 22102 195.159.176.226 (7 Mar 2017 16:53:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Mar 2017 16:53:20 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: Jens Lechtenboerger , Michael Heerdegen , 25946@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 07 17:53:15 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clIMC-00046O-9W for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Mar 2017 17:53:04 +0100 Original-Received: from localhost ([::1]:51659 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clIMI-0001rX-9O for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Mar 2017 11:53:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clILF-0001IN-I9 for bug-gnu-emacs@gnu.org; Tue, 07 Mar 2017 11:52:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clILC-0003Hb-Er for bug-gnu-emacs@gnu.org; Tue, 07 Mar 2017 11:52:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46628) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1clILC-0003HJ-BJ for bug-gnu-emacs@gnu.org; Tue, 07 Mar 2017 11:52:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1clILC-0005qM-1I for bug-gnu-emacs@gnu.org; Tue, 07 Mar 2017 11:52:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Mar 2017 16:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25946 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25946-submit@debbugs.gnu.org id=B25946.148890549422427 (code B ref 25946); Tue, 07 Mar 2017 16:52:01 +0000 Original-Received: (at 25946) by debbugs.gnu.org; 7 Mar 2017 16:51:34 +0000 Original-Received: from localhost ([127.0.0.1]:44827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clIKk-0005pe-3O for submit@debbugs.gnu.org; Tue, 07 Mar 2017 11:51:34 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:51802) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clIKh-0005pP-VX for 25946@debbugs.gnu.org; Tue, 07 Mar 2017 11:51:32 -0500 Original-Received: from rosalinde ([83.135.17.126]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MQ33z-1cgddX0v0l-005GLg; Tue, 07 Mar 2017 17:51:24 +0100 In-Reply-To: <58BE8134.6000907@gmx.at> (martin rudalics's message of "Tue, 07 Mar 2017 10:45:24 +0100") X-Provags-ID: V03:K0:4YMbi5Omdzo08TaTTit6RgBB/ZQu+7VFhsOs0Xs8IwVKXaVflYg m+EKB+voHX3kX7OP9gA2dw0MPJKrKElRrkj8jfpek+uWeg7H5dzJ+bX8Dye3bbHzKKPDBTC pJEEqn9CfOLUuRNcyaUGEidv/VE5HM1sGJrR4H9rQJloTN5Jx11MqgkgpDiFDmmgerqD8LM UAM1TQ6dVLeo8RIm+u3tg== X-UI-Out-Filterresults: notjunk:1;V01:K0:lDOO4oYuXWY=:bbfEVuGEEboJ+x6IQFDVXM LxwvDSKMUd/XrvKdkkE+k2mSJ4zD7RMPvO6R4r98+OCxwi4Lfgz/HRhSnoKA/0DUTmAYjifuG cQwjkS1iYEO4zGLAU1WWUYNNzp9KtQmInAGbp9KeeZOv8TThh/XIyfaPaa8VRdC4xIr84LDYn MuWRsUc83QM+4M4Z6rwxlrOjXhlGUu2iwt87061cc3pE5+m9d1wsLB6m9GKGa5Oxe2Vc4X1L8 BcUWYcYNARbhJBsK9f5aX6SGL6IUErrlqBM3Lh5C+D6B8o/VXeDu/Iplb/HNGtW5b9BesV1XT k5p1fejfIM0Y1nqarh9P7WDk4wpSCyUUx1LddasCfZfEdv9KxdGwImeqMj648v37YOZIQ9OuT Aav5vdOW09A2WmX+GokahIsHdMZvIGn5Jwpe1putLz8H+gVrjaPWYVQ4HaSFyM3FiPmND7Uw2 dWJfkqJeGn0OZQ3StJswpWcDSt0qe7qEcmlhPsUZ2p/N4zMt8G8xg5b9hM9tqrydDLpR1cm0U hmpJWejeEZCW7W9B/SmWGJ7+axyzYE2upGUcjV9dZGpJpMMMMCKvsyJNHeFadq0dF33fehROk rpNqloi6Pe2XWJU3n4JRfs/EMaRR0Fs/ug+QsmlUhaT28Qva+4MPBSPTH96e0WmLsQNotedHD dFIUk7pDzhg44tb17dTRrgH3RhuJjEnT9PftCopvhIbZufXqyFVZjJ8H0LgKxTbBEiKj2P9vD R200HSFiCPvgb2DXLRcAVSuGuRvWXnUeRZHBn3AEFFVm+0EJYOc3dk+OIRRwTSq7i2h3xPJC X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:130318 Archived-At: On Tue, 07 Mar 2017 10:45:24 +0100 martin rudalics wrote: >> (TeX-pop-to-buffer old-buffer nil t)) ; <=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> (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 > =E2=80=98special-display-frame-alist=E2=80=99. So Jens probably needs so= mething 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 =E2=80=98display-buffer=E2=80=99 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 > 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