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: Tue, 20 Aug 2013 08:16:12 -0700 (PDT) Message-ID: <6c66dc09-9091-4fcc-9183-1b77886b58ba@default> References: <6bb534ef-d80b-4c35-9538-2ee383d95610@default> <52124432.9010707@gmx.at> <391c84ad-a338-41df-96ed-287508f86d66@default> <52127AEE.8010101@gmx.at> <52131543.8030909@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 1377011845 7640 80.91.229.3 (20 Aug 2013 15:17:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Aug 2013 15:17:25 +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 Tue Aug 20 17:17:24 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 1VBngR-0004sC-MO for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Aug 2013 17:17:23 +0200 Original-Received: from localhost ([::1]:48422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBngR-0001Sz-1X for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Aug 2013 11:17:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBngF-0001RQ-CX for bug-gnu-emacs@gnu.org; Tue, 20 Aug 2013 11:17:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBng6-0007BS-NM for bug-gnu-emacs@gnu.org; Tue, 20 Aug 2013 11:17:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBng6-0007BO-K6 for bug-gnu-emacs@gnu.org; Tue, 20 Aug 2013 11:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VBng6-0000qE-4s for bug-gnu-emacs@gnu.org; Tue, 20 Aug 2013 11:17: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: Tue, 20 Aug 2013 15:17:01 +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.13770117793161 (code B ref 15133); Tue, 20 Aug 2013 15:17:01 +0000 Original-Received: (at 15133) by debbugs.gnu.org; 20 Aug 2013 15:16:19 +0000 Original-Received: from localhost ([127.0.0.1]:42753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBnfO-0000ou-8e for submit@debbugs.gnu.org; Tue, 20 Aug 2013 11:16:18 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:32709) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBnfM-0000oj-CQ for 15133@debbugs.gnu.org; Tue, 20 Aug 2013 11:16:17 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7KFGExw013149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Aug 2013 15:16:15 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7KFGDtB025371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 15:16:14 GMT Original-Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7KFGDZt027873; Tue, 20 Aug 2013 15:16:13 GMT In-Reply-To: <52131543.8030909@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: ucsinet22.oracle.com [156.151.31.94] 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:77549 Archived-At: Replied in order, as I read. If you want to cut to the chase, see the end. > >> 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. >=20 > So you didn't check? Can you please tell me what to check, and how? It's not clear to me what you are asking/suggesting; sorry. > >> The problem is that the new frame doesn't yet show the buffer you wan= t > >> to display when `after-make-frame-functions' is called. > > > > I see. So you are saying that the new frame object is passed to the h= ook > > functions, but that new frame has not yet been displayed. If so, that= is > > presumably the cause of the regression. >=20 > No. I am saying that at the time `after-make-frame-functions' is > called, the new frame does not yet show the buffer you want to display > in it via plain `display-buffer'. >=20 > > What's the point of passing the newly created frame object to hook > > functions intended to act on it, if that frame has not yet been displa= yed > > so they can do so? > > > > Perhaps you are allowing for hook functions that do not assume the fra= me > > 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 f= irst? >=20 > You want to apply `fit-frame' to the buffer you eventually want to > display on the new frame. Right? I want to apply it to the frame (not to a buffer) _after_ it has been displayed. Previously, creating the frame (`make-frame') also displayed it= , and it did so before hook `after-create-frame-functions' was invoked. > > 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 di= d > > do and should do. It says: "Return a newly created frame displaying t= he > > current buffer." >=20 > The _current_ buffer. The question is which buffer should be current for that frame at that point= . I'm not sure the doc string should really have said "current buffer", as in `current-buffer'. Seems like what was intended - what makes sense in terms of the hook, and what I have always thought has been the behavior until now= - is the buffer the frame was created to display (which is harder to say than "current buffer"). IOW, the buffer that ends up displayed in the frame. The key part of that doc string, for me, is that it returns a new frame tha= t is already displayed. No one ever _sees_ a newly created frame first displ= ay the `current-buffer' and then switch to the actual buffer to be displayed i= n the frame. What you see is only the frame displayed (immediately) with the proper buff= er. And that displayed frame, with the buffer it displays, is what has always been passed to the `after-make-frame-functions'. And previously that frame was always displayed before `after-make-frame-*' was invoked. So in a hook function you could do this, for example: (save-window-excursion (select-frame frame) (setq specbuf-p (and empty-buf-p (special-display-p (buffer-name (window-buffer)))))) And the `window-buffer' was the buffer that the frame displayed, which was already the buffer that the frame was created to display. > Because the "since forever" behavior is inconsistent. Consider the > following forms: >=20 > (defun mess (frame) > (message "selected: %s ... frame: %s ... buffer: %s" > =09 (selected-frame) frame > =09 (window-buffer (frame-root-window frame)))) >=20 > (let ((pop-up-frames t)) > (add-hook 'after-make-frame-functions 'mess) > (display-buffer "*Messages*") > (remove-hook 'after-make-frame-functions 'mess)) >=20 > (let ((pop-up-frames t)) > (add-hook 'after-make-frame-functions 'mess) > (pop-to-buffer "*Messages*") > (remove-hook 'after-make-frame-functions 'mess)) >=20 > With emacs -Q evaluate the first and and then try the other two with > some older version and the current trunk. You should notice that the > FRAME argument of `mess' is always different from the selected frame. > But the buffer FRAME displays is different. With the older versions the > buffer is *scratch* for plain `display-buffer' and *Messages* for > `pop-to-buffer'. With current trunk it is *scratch* for both. >=20 > So I suppose that since forever your `fit-frame' function works on the > "wrong" buffer when you call plain `display-buffer' and the buffer you > want to display is not current at that time. I see. Yes, I see the behavior you describe, from emacs -Q. However, I have never noticed a problem in this regard with my code - dunno why. For a moment I wondered if this is perhaps because on MS Windows a new frame gets a certain kind of focus (not sure how to characterize that behavior). But I also use my code on GNU/Linux with Emacs 21.3, and there too I have never see `fit-frame' fit a new frame to the wrong buffer (the previously current one) etc. Mystery. It is true that I also make other calls to `fit-frame', including on `temp-buffer-show-hook' for one-window frames. Perhaps one of those other calls has been compensating for the discrepency in Emacs -Q that you point out. Dunno. Anyway, here is my question, given this discrepancy. You want to make the buffer be consistent. OK, But you have so far chosen the `current-buffer' as the buffer to use, perhaps from a reading of the doc string. Why not instead choose the buffer that will be displayed in the frame, consistently? IOW, for your test above, always have the buffer be *Messages*, since that is the buffer displayed in the frame that is passed to `after-make-frame-functions'? What is the use case for passing the frame, which will display (or is already displaying?) the *Messages* buffer, have as its root-window buffer some other buffer (*scratch*) that is not even displayed in that frame and perhaps never will be? > What I propose is to use the following as substitute for the old > `display-buffer-pop-up-frame': > (defun display-buffer-pop-up-frame (buffer alist)... >=20 > With this the buffer printed by `mess' should be *Messages* for both, > the plain `display-buffer' case and `pop-to-buffer'. Sounds like you are suggesting the same thing I suggested immediately above, and you are providing code that implements that. And yes, a quick trial indicates that that does seem to work, so far. I will load that code at startup and let you know if I notice any problems. Thx.