Re: address@hidden: emacsclient won't open new frame on remote display]

[Chong Yidong]

> This suggested change causes Emacs to create a new frame displaying some
> random buffer.  If server.el subsequently uses switch-to-buffer or something
> like that, it's probably OK, but if it instead uses something like
> pop-to-buffer because you want to display emacsclient buffers in their own
> window or frame, then you end up with 2 windows (or frames) one of which
> displays some random buffer.

As the original bug report indicates, the current default behavior is
that the buffer is not displayed at all, which is clearly broken.  My
thinking is that it makes more sense to create the new frame, to
ensure that the default behavior (with no customizations) works.  If
the user customizes the emacsserver behavior, like changing it to use
pop-to-buffer, those personal customizations can be adapted to work
with extra displays.  But the default behavior must definitely work.

What do you think?