Re: emacsclient's option decoding code

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: Juanma Barranquero <address@hidden>,  address@hidden,  address@hidden
> Date: Tue, 11 Nov 2008 21:31:59 -0500
> 
> >> Chong has already explained the assumption. And IMO that assumption is
> >> correct for POSIX
> 
> > I can't say I see why such an assumption should be made for Posix,
> > either.
> 
> Because it mimicks the behavior of Emacs itself (if you start it with
> a $DISPLAY, it defaults to using an X11 frame and if there's no
> $DISPLAY it uses the tty).

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.  For example, the server could have
been built with no X11 support, or the "current terminal" specified by
the --tty option could be unavailable.  Or you could be talking to a
remote Emacs, in which case there's no reason to believe the client
will know anything about $DISPLAY on the remote machine.

IOW, unlike with launching Emacs itself, where we always know what we
can or cannot do (since it's the same single program), when
emacsclient is invoked, it currently tries to second-guess
capabilities of another program, and there just aren't any good means
to do that reliably.

The upshot is, or so it seems, that there's no reliable way of making
sure the client's request will be served as well as possible.

So I propose a different strategy: given a specific request from a
client, let's have the server try to serve the request in the best
possible way it can.  For example:

  . if --display=DISPLAY was specified, try the given DISPLAY, if that
    fails, try ":0.0", if that fails, try using a tty;

  . if -c was specified, try creating a GUI frame, and failing that,
    try a tty frame;

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

This could be implemented simply by catching errors thrown by
make-frame-on-tty etc. and falling back on safer methods as outlined
above.

The advantages are that (1) it will work more reliably (basically, if
some kind of frame is possible, it will be used); (2) server.el does
not need to be littered by ugly system-dependent conditions, it could
assume Posix semantics and let less-capable platforms use the first
supported fallback; and (3) emacsclient's code that parses the
command-line options can be much simpler, since it needs not guess
what Emacs can or cannot do.

> > platforms, as much as possible.  In this case, "as much as possible"
> > means that emacsclient should be able on Windows to create a GUI frame
> > if a GUI Emacs is running and a tty frame if a tty Emacs is running.
> 
> That could make sense for -c indeed, altough it's not what happens under
> X11: under X11 a "-c" with no $DISPLAY is equivalent to -t, i.e. it
> uses the tty from where "emacsclient" is run, rather than using the tty
> where the Emacs server is currently running.

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

> > Would it be better to return "0.0" instead of nil or ""?
> 
> I don't like using nil for "the w32 window system", indeed.  I think the
> "" we currently use is better.  Can't we just make make-frame-on-display
> accept an argument "" to mean "the w32 window system"?

With my suggestion, none of this trickery is needed.