bug#8876: 24.0.50; making `menu-bar-update-buffers' use another frame

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

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