Re: emacsclient's option decoding code

[Eli Zaretskii]

> Date: Tue, 11 Nov 2008 10:39:28 +0100
> From: "Juanma Barranquero" <address@hidden>
> Cc: address@hidden, address@hidden
> 
> On Tue, Nov 11, 2008 at 05:09, Eli Zaretskii <address@hidden> wrote:
> 
> >>  - emacsclient -c causes the same error, because emacsclient thinks
> >> that "-c" + null DISPLAY => "-t"; I proposed the attached patch (1),
> >> because even if -t is supported on Windows, the assumption that an
> >> empty DISPLAY implies a tty frame is false.
> >
> > Then why is the patch Windows-specific?  If the above assumption is
> > false, it shouldn't be made on Posix platforms as well.
> >
> > Can someone explain why this assumption is in the code?
> 
> 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.  Why not ask the user to specify whether she wants a GUI frame
or a tty frame?

> I think the behavior I propose is more consistent. Also, if we someday
> implement X support on the Windows port, my patch would naturally
> work, while the current one would have to be fixed.

I'm okay with your patch, FWIW, but I don't like the #ifndef WINDOWSNT
part in emacsclient.c.  I 'd like the behavior to be the same on all
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.

Can we do that?

> IMHO the desire to fix the -c/-t problem on Windows has muddled the
> waters a bit. As I said in a previous message, if we want
> `make-frame-on-display' to allow `nil' to default to the current
> frame, that seems sensible. But making an exception for Windows and
> allowing "", or in fact any other value, string or otherwise, is ugly
> and just a consequence of the fact that (frame-parameter nil 'display)
> returns "" on Windows.

Would it be better to return "0.0" instead of nil or ""?