Re: emacsclient's option decoding code

[Stefan Monnier]

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

>   . 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 -c was specified, try creating a GUI frame, and failing that,
>     try a tty frame;

That's what the "fallback to -t if $DISPLAY is empty" does.

>   . if --tty was specified, try make-frame-on-tty, if it fails, try
>     using the current tty or a GUI frame.

Again, the current tty (or any other current terminal/frame) may be
miles away from the user's eyes.

> We could try to use emacsclient's tty, and if that fails, fall back on
> the one where Emacs is running.

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.


        Stefan