From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics 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 19:24:33 +0200 Message-ID: <5213A651.9020502@gmx.at> 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> <6c66dc09-9091-4fcc-9183-1b77886b58ba@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1377019524 29208 80.91.229.3 (20 Aug 2013 17:25:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Aug 2013 17:25:24 +0000 (UTC) Cc: 15133@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 20 19:25:26 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 1VBpgK-0002lj-3b for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Aug 2013 19:25:24 +0200 Original-Received: from localhost ([::1]:49140 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBpgJ-0006Nk-Kt for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Aug 2013 13:25:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBpgA-0006MY-5J for bug-gnu-emacs@gnu.org; Tue, 20 Aug 2013 13:25:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBpfz-0005GC-FL for bug-gnu-emacs@gnu.org; Tue, 20 Aug 2013 13:25:14 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBpfz-0005Fu-Bh for bug-gnu-emacs@gnu.org; Tue, 20 Aug 2013 13:25:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VBpfy-0006yj-Ao for bug-gnu-emacs@gnu.org; Tue, 20 Aug 2013 13:25:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Aug 2013 17:25: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.137701949026800 (code B ref 15133); Tue, 20 Aug 2013 17:25:02 +0000 Original-Received: (at 15133) by debbugs.gnu.org; 20 Aug 2013 17:24:50 +0000 Original-Received: from localhost ([127.0.0.1]:42988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBpfk-0006y9-SV for submit@debbugs.gnu.org; Tue, 20 Aug 2013 13:24:49 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:64208) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VBpfi-0006xw-14 for 15133@debbugs.gnu.org; Tue, 20 Aug 2013 13:24:47 -0400 Original-Received: from [62.47.43.55] ([62.47.43.55]) by mail.gmx.com (mrgmx001) with ESMTPA (Nemesis) id 0LwJRe-1W9h9p0OAo-0180EB for <15133@debbugs.gnu.org>; Tue, 20 Aug 2013 19:24:43 +0200 In-Reply-To: <6c66dc09-9091-4fcc-9183-1b77886b58ba@default> X-Provags-ID: V03:K0:2TL5EjHgank9DWrnuIkc3i51slO196OHn581KEdkLLrZvBpw5rw eale09CNgUIySNsYUeBL6FJ+bYhjKrA4VbkJ7TjA0Qw21QPYVERh02oq6KLZJYotJg2Luxq AHBgvXSR9CzaYf9MQVTkG2mvJtJT/hL5bYpTYiUVVJGzVrs6M5ZLF/UtLBNilfIPZrDeKZ9 BG7ev1ufbak8pLCvblBbA== 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:77558 Archived-At: > Can you please tell me what to check, and how? It's not clear to me what > you are asking/suggesting; sorry. Whether with older versions your `fit-frame' function works with plain `display-buffer', that is, bypassing `pop-to-buffer'. Obviously, `special-display-popup-frame' is disallowed as well because it does (with-current-buffer buffer (make-frame (append args special-display-frame-alist)))) and `temp-buffer-window-show' is disallowed because it does (with-current-buffer buffer ... (setq window (display-buffer buffer action))) >> 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. It displayed it if and only if it was current at the time `make-frame' was called. Also, at the time `after-make-frame-functions' is called the buffer is not yet "displayed". `make-frame' simply sets a slot in the frame structure to reference that buffer. >> The _current_ buffer. > > The question is which buffer should be current for that frame at that point. It's up to the caller to determine that, `make-frame' wouldn't know. > 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. This is not what `make-frame' does. > The key part of that doc string, for me, is that it returns a new frame that > is already displayed. No. Otherwise with `display-buffer' you would first see one buffer and then another - or at least some kind of flicker. > No one ever _sees_ a newly created frame first display > the `current-buffer' and then switch to the actual buffer to be displayed in > the frame. Then put a `sit-for' in `display-buffer-pop-up-frame' before it calls `window--display-buffer'. > What you see is only the frame displayed (immediately) with the proper buffer. > And that displayed frame, with the buffer it displays, is what has always > been passed to the `after-make-frame-functions'. Not necessarily - only when the buffer current at that time was also the buffer finally displayed in that frame. > 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. I miss you here. For `display-buffer' the hook is called after the frame has been "created" but before it is ascertained that it displays the "right" buffer. > Anyway, here is my question, given this discrepancy. You want to make > the buffer be consistent. I want `display-buffer' DTRT. This means that it should call `make-frame' with the buffer to be displayed current. > 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? But that's what I do: I make the buffer "that will be displayed in the frame" current so `make-frame' assigns it immediately to the new frame's root window. And I have to do this in the buffer display code because I cannot pass a buffer to `make-frame' just as I cannot pass a buffer to `split-window'. > 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'? It's not passed. It's the current buffer at the time `after-make-frame-functions' is called. > 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? `make-frame' has been designed that way - display the current buffer in the new frame. Just as `split-window' displays the buffer shown in the window to be split in the new window too. > 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. Thanks, martin