Re: emacsclient's option decoding code

[Evil Boris]

"Juanma Barranquero" <address@hidden> writes:
> IMO making a frame in the current display and making a frame in a
> remote display are different operations and the point of call should
> know about it. We don't usually conflate making tty and X frames,
> either.

I have been watching the arguments fly by and want to point out that, at
least on X, IMHO, one cannot tell which X frames are local and which are
not, for example, due to X tunnelling.  So I am not convinced that
either the client or the server can determine what to do if the precise
recipe requested by the user fails/is unavaible.  If the commands are
used interactively, I would lean towards having them fail with an error,
rather than try a default behavior that may or may not make sense.  My
concern however is that sometimes emacsclient is invoked as the editor in
mail client, or in reverse search in a TeX previewer, or as an editor
for log msgs in SVN etc.  It is unclear to me what the right behavior is
there---opening a frame in an inaccessible place seems like potential
trouble. 

--Boris