Re: emacsclient's option decoding code

["Juanma Barranquero" <lekktu@gmail.com>]

On Wed, Nov 12, 2008 at 16:56, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> You might be right.  I tend to think of `display' as something similar
> to `terminal', but they're not the same.  To tell you the truth, I'm not
> sure what `display' is meant for exactly.

Same here. I find weird (though perhaps understandable) that Emacs has
a clear separation between tty and graphics frames, but not such
between X and w32 (and ns, etc.) frames. By that I mean that there is
code which calls x-functions when compiled on GNU/Linux, and their
w32-* counterparts when compiled on Windows. That will be a problem if
someday we have a multi-GUI Emacs.

> E.g., let's imagine a w32 version of Emacs which has been hacked to be
> able to use X11 as well.  And let's additionally say that it can even
> also use GNUstep, so it can have w32, x11, and ns frames, all displayed
> on the same screen.  Both ns and x11 frames will have a `display' set to
> the same value (typically ":0.0" or something along these lines),
> whereas the w32 frames's display will be "" (or nil, or ...).
> This discrepency doesn't seem good.
>
> So maybe we should just make w32 use display=":0.0".

Fine by me. Someday, if multi-GUI materializes, we'll have to add a
frame parameter or another way for lisp code to query the GUI
associated with a given frame.

> The current display should be obtained via (frame-parameter nil 'display).

Yes. My doubt was whether "current display" makes as much sense for
Windows frames as it does for X ones.

But I don't want to insist; I'd be happy just by fixing some of the
issues, one way or another.

So, please answer these:

 - Should the "-c + no DISPLAY" => "-t" implication of emacsclient be
removed only for Windows (because it does in fact make sense on
POSIX), or be removed for good (Eli's view, I think)?

 - Do I change term/w32-win.el to use ":0.0" as argument to `x-open-connection'?

 - If yes, do we leave `make-frame-on-display' as it stands now, i.e.
accepting any DISPLAY string as valid when called from Windows, or do
we change it to accept just ":0.0" for the time being? (I favor the
second, which is simpler and cleaner: it's just removing the recent
three-line patch by Chong.)

 - Do we want `make-frame-on-display' to accept a null DISPLAY (on
every platform) to mean "create a frame on the current display"?

  Juanma