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#15133: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected Date: Mon, 19 Aug 2013 14:46:31 -0700 (PDT) Message-ID: References: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> <52124432.9010707@gmx.at> <391c84ad-a338-41df-96ed-287508f86d66@default> <52127AEE.8010101@gmx.at> 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 1376948844 8379 80.91.229.3 (19 Aug 2013 21:47:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Aug 2013 21:47:24 +0000 (UTC) Cc: 15133@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 19 23:47:25 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 1VBXIL-0007Cz-3d for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Aug 2013 23:47:25 +0200 Original-Received: from localhost ([::1]:45007 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBXIK-00021O-Bf for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Aug 2013 17:47:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBXI7-000206-Kf for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2013 17:47:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBXHy-0002LD-Tv for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2013 17:47:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46836) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBXHy-0002L3-Py for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2013 17:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VBXHy-0002xR-7D for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2013 17:47: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, 19 Aug 2013 21:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15133 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15133-submit@debbugs.gnu.org id=B15133.137694879611333 (code B ref 15133); Mon, 19 Aug 2013 21:47:02 +0000 Original-Received: (at 15133) by debbugs.gnu.org; 19 Aug 2013 21:46:36 +0000 Original-Received: from localhost ([127.0.0.1]:41152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBXHX-0002wi-Bj for submit@debbugs.gnu.org; Mon, 19 Aug 2013 17:46:35 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:39012) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBXHV-0002wa-51 for 15133@debbugs.gnu.org; Mon, 19 Aug 2013 17:46:33 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7JLkU8w004582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Aug 2013 21:46:31 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JLkTrQ011044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 21:46:30 GMT Original-Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7JLkTOC015847; Mon, 19 Aug 2013 21:46:29 GMT In-Reply-To: <52127AEE.8010101@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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:77524 Archived-At: > > Sorry, I don't understand. What "both" would you like me to try? Thi= s > > needs to work as it did before the regression - both `pop-to-buffer' > > and `display-buffer'. >=20 > Did `display-buffer' work correctly? Not sure what you mean. I haven't seen a problem until this build. Hence the report of this being a regression. > > But first, I don't understand either why there should be any differenc= e. > > Why shouldn't functions on `after-make-frame-functions' always be pass= ed > > the new frame as argument, as has been the case in the past? There is= a > > `before-make-frame-functions' hook for passing the originally selected > > frame. >=20 > The problem is that the new frame doesn't yet show the buffer you want > to display when `after-make-frame-functions' is called. I see. So you are saying that the new frame object is passed to the hook functions, but that new frame has not yet been displayed. If so, that is presumably the cause of the regression. What's the point of passing the newly created frame object to hook function= s intended to act on it, if that frame has not yet been displayed so they can do so? Perhaps you are allowing for hook functions that do not assume the frame is displayed. Is that the point of this change? Should I change the hook function here to, say, (lambda (fr) (raise-frame fr) (fit-frame fr))? Or perhaps `make-frame-visible' instead of `raise-frame'? I just tried those, and they does not work either. If I want to apply a function such as `fit-frame' to the new frame, and it is not yet displayed, what do I need to call in the hook function to display it first? The doc string of `make-frame' suggests, BTW, that it should both (a) make a frame object and (b) display it, as I have always thought it did do and should do. It says: "Return a newly created frame displaying the current buffer." You will perhaps say that the PARAMETERS argument could include `invisible' or `iconified' or some such that has the effect of creating a frame that is not visible (displayed). If that is the idea behind this change then I might not have anything against it, provided the frame is in fact displayed when PARAMETERS does not do something to make it invisible etc. IOW, in the use cases I have, an ordinary frame is created displayed, and after that happens I want to fit the frame. `after-make-frame-functions' has always been the right place to do that, in the past. Seems like this is being redefined now.=20 Please advise. This should be simple. And it's still not clear to me why it should not be as it was before (i.e., since forever).