[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacsclient's option decoding code

From: Evil Boris
Subject: Re: emacsclient's option decoding code
Date: Fri, 14 Nov 2008 21:58:37 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (windows-nt)

"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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]