From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics 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 10:45:24 +0100 Message-ID: <58BE8134.6000907@gmx.at> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1488879979 15739 195.159.176.226 (7 Mar 2017 09:46:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Mar 2017 09:46:19 +0000 (UTC) Cc: Jens Lechtenboerger , Michael Heerdegen , 25946@debbugs.gnu.org To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 07 10:46: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 1clBh6-0003Zc-9j for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Mar 2017 10:46:12 +0100 Original-Received: from localhost ([::1]:48464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clBhC-0000tW-DS for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Mar 2017 04:46:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48930) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clBh0-0000ry-V9 for bug-gnu-emacs@gnu.org; Tue, 07 Mar 2017 04:46:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clBgx-000562-3q for bug-gnu-emacs@gnu.org; Tue, 07 Mar 2017 04:46:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45401) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1clBgw-00055J-TI for bug-gnu-emacs@gnu.org; Tue, 07 Mar 2017 04:46:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1clBgw-0001ZE-Ff for bug-gnu-emacs@gnu.org; Tue, 07 Mar 2017 04:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Mar 2017 09:46:02 +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.14888799415972 (code B ref 25946); Tue, 07 Mar 2017 09:46:02 +0000 Original-Received: (at 25946) by debbugs.gnu.org; 7 Mar 2017 09:45:41 +0000 Original-Received: from localhost ([127.0.0.1]:43596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clBgb-0001YG-2x for submit@debbugs.gnu.org; Tue, 07 Mar 2017 04:45:41 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:57592) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clBgZ-0001Y0-Qs for 25946@debbugs.gnu.org; Tue, 07 Mar 2017 04:45:40 -0500 Original-Received: from [192.168.1.100] ([213.162.68.17]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LpcBS-1c5pJi0vFG-00fRTj; Tue, 07 Mar 2017 10:45:32 +0100 In-Reply-To: <87h93686kk.fsf@rosalinde> X-Provags-ID: V03:K0:AAB4UlUJJPa9qWlEELFO6Gz/kQGziCxjSznRPJAEdKan3CSvwHP 5ug8EtPUxGP9eBPyBOHsqQdvGcfljAEhtn63ikfBHJqUG9Mk/QwvxagtVChoy24jhPJ9wd8 QnxhnuQgkde59O/NI78wQkPrQyB7Jgjv8jooncl7/HsBqrtuR58dNtQ6ot7cmCrsoocmS+5 ngma5W9mQ4m3k4DRe+UhA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Hg1LUYjDihs=:+ScI2D7GDsAI/aVSo7U4Bl OsMOawXQjr6ku84k35ZRYtQj8lD1YOQZrZmz4GfyLc16j5N0ppq1HYJMk0D1FF9lQ1JjEf3hZ cEn0AbvDti1iHdT4ZEEDvQj/Q6LG22se1lzTAvrfLQQ+V7L6v5Aw2MMyvyWa24WnfseGFpk99 iyymStigZSiih3qnqm78YwvZJHjEyStnRr9w8pbDKcrTzVv75cl3CzXYYHp/XG8vF5rL+FRfa iSn4L4U0YVdIJxqnoEh0qi/aWDL/96v8Z7gf1IVf5iIhvg1cssilhuyenSMQ1VgXaN7QhYY+0 vksHTRwk43wFRe009jCE5n7O8rm3+WaG2uTeNZ6yGJOpwEOAyRz0EERG5tbHaKQTgF/LIH74h usUG5dfLH4sxpZpCKlJsK20PnW+fc2n7iHQMpJPNSXfV0GZ7wZMmUKrwPuLU3pKsNDs9wyMxY RVT0fQ6QcNSOycqBtnw4V6QQ2eWwy7zeAd+zB88mr6ySxOhreZmQ4WUUPTQH24ONfmwEYV/F3 N2sXMSmBnAHKule8PAtY+0JUVOVsdihALEZ8dpsN2gnD2iMCznqvlc3zoia9Ao7QWNfpTlaR5 butu4mRFTJl6pCtmf5B/iLWzcGMRNFTMbkQ3JZ/3QR62sy4ZS+ppCgL4w1I1bDvi49JGH/Szb sE7cAlUKuchK2IRuuBoo45SCUYMULyxcEdvRGtFnnny5lOQugLmMXqzArRa/WmP/6LAIyxA6Z z4pwzuzvonfsi0REKOjtSHZrlbGxSScnmIx5USBiqiZxPy41QnfHA3dromxWpxkNwgZCxSdI 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:130299 Archived-At: > (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? 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. > (*) 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 th= e > output buffer (and hence its frame), keyboard input was totally blocke= d, > 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? martin