From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#8876: 24.0.50; making `menu-bar-update-buffers' use another frame Date: Mon, 17 Jun 2013 09:26:33 -0700 (PDT) Message-ID: <9e1f230a-090d-4aa1-854e-226a12ea5077@default> References: > > <88e3bec9-73e5-49d9-8afe-64b237c09f60@default> <878v28rb8d.fsf@web.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1371486432 3911 80.91.229.3 (17 Jun 2013 16:27:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Jun 2013 16:27:12 +0000 (UTC) Cc: 8876-done@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 17 18:27:11 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UocGs-000181-Vv for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Jun 2013 18:27:11 +0200 Original-Received: from localhost ([::1]:46081 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UocGs-0002Mk-Bd for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Jun 2013 12:27:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UocGm-0002M3-KZ for bug-gnu-emacs@gnu.org; Mon, 17 Jun 2013 12:27:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UocGl-00031R-JM for bug-gnu-emacs@gnu.org; Mon, 17 Jun 2013 12:27:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56654) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UocGl-00031I-Gb for bug-gnu-emacs@gnu.org; Mon, 17 Jun 2013 12:27:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1UocGk-0006iZ-7a for bug-gnu-emacs@gnu.org; Mon, 17 Jun 2013 12:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 17 Jun 2013 16:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8876 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8876-done@debbugs.gnu.org id=D8876.137148640725782 (code D ref 8876); Mon, 17 Jun 2013 16:27:02 +0000 Original-Received: (at 8876-done) by debbugs.gnu.org; 17 Jun 2013 16:26:47 +0000 Original-Received: from localhost ([127.0.0.1]:50970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UocGT-0006hg-Gw for submit@debbugs.gnu.org; Mon, 17 Jun 2013 12:26:46 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:43656) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UocGQ-0006hD-JF for 8876-done@debbugs.gnu.org; Mon, 17 Jun 2013 12:26:43 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5HGQWPt026989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 16:26:33 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5HGQYgj024388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 16:26:35 GMT Original-Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5HGQYeS024384; Mon, 17 Jun 2013 16:26:34 GMT In-Reply-To: <878v28rb8d.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:75258 Archived-At: > > But that is not compatible with the latest `pop-to-buffer'. > > And when I look at the doc for `pop-to-buffer' I keel over. > > > > It tells me I can use an ACTION argument (as Martin did here, > > with value `other-frame'). But it sends me off to the doc for > > `display-buffer', whose description of parameter ACTION is > > incomprehensible to me. WAY too complicated. >=20 > I made the same experience. Thanks for confirming I am not alone. I doubt that we two are alone. > Now, a good and detailed description is given in the manual > under (elisp) Display Action Functions. IMHO it's > understandable. Yes, it helps, but this is all still way too complicated, AFAICT. That node should be xref'd from the `display-buffer' doc string, or the same info should be added to the doc string. Without such info, you really haven't a clue what the ACTION parameter is all about. And it should be made clear in that node that the action functions described there correspond to the car of the ACTION parameter for `display-buffer" (and `pop-to-buffer'). This connection is currently not being made. The node title says that these are action functions for `display-buffer', but it should be pointed out that they are used in the car of the ACTION parameter. Anyway, I guess the answer to my question is more or less this: (pop-to-buffer my-buffer '(display-buffer-pop-up-frame)) Ah, alas, no. That creates a new frame instead of reusing an existing frame. And that is true regardless of the value of `pop-up-frames'. And that's a lot less handy than just (pop-to-buffer 'other-frame). And it is even less succinct than this (which still works, thank goodness): (let ((pop-up-frames t)) (pop-to-buffer mybuf)) And the latter has the advantage that it does reuse an existing frame, rather than creating a duplicate one. `pop-to-buffer' has previously preferred an existing frame/window. Now it eagerly creates new ones? Still not clear to me. Still seems WAY overengineered, to me. I do appreciate the goal of providing more fine-grained control over buffer display. But the result, at least for my use case (separate frames a lot of the time) seems to be imposed extra complication. The fine-grained control should be available, but should not be in your face. You should not be required to twiddle fine-tuning knobs to get simple behavior, especially simple behavior that has been availablein the past in a simple way. IOW, it seems that we have thrown out the baby with the bathwater.