Re: emacsclient's option decoding code

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: lekktu@gmail.com,  cyd@stupidchicken.com,  emacs-devel@gnu.org
> Date: Wed, 12 Nov 2008 15:56:25 -0500
> 
> > But this is guesswork at best, and cannot possibly DTRT in every
> > possible use-case, because emacsclient have no way of knowing what the
> > Emacs server can or cannot do.
> 
> Some of the decisions could benefit from being moved to/from the client
> from/to the server, indeed.
> But returning an error if the user requests something that can't be done
> is often better than trying to be clever.

I don't see why erroring out is better.

> >   . if --display=DISPLAY was specified, try the given DISPLAY, if that
> >     fails, try ":0.0", if that fails, try using a tty;
> 
> :0.0 may be miles away from the user's eyes, so if $DISPLAY fails,
> better signal an error and let the user manually switch to :0.0 if
> that's what he wants to do.

If :0.0 is miles away, there's no difference between an error and
display miles away: in both cases, the user needs to fix something and
reinvoke.  What I suggest is better because if :0.0 is NOT miles away,
it does TRT, while erroring does not.

> It might be OK to provide an option to do that, but silently doing so
> without the user's constent may be worse than signalling an error and
> letting *her* switch to the appropriate tty.

We do it today already, with the kind of guesswork we have in
emacsclient.