bug#15133: 24.3.50; REGRESSION: `after-make-frame-functions' now run with wrong frame selected

[Drew Adams <drew.adams@oracle.com>]

>  > Sorry, I don't understand.  What "both" would you like me to try?  This
>  > needs to work as it did before the regression - both `pop-to-buffer'
>  > and `display-buffer'.
> 
> 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 difference.
>  > Why shouldn't functions on `after-make-frame-functions' always be passed
>  > 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.
> 
> 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 functions
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. 

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).