Re: emacsclient's option decoding code

[Stefan Monnier]

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

   framep is a built-in function in `C source code'.
   
   (framep object)
   
   Return non-nil if object is a frame.
   Value is t for a termcap frame (a character-only terminal),
   `x' for an Emacs frame that is really an X window,
   `w32' for an Emacs frame that is a window on MS-Windows display,
   `ns' for an Emacs frame on a GNUstep or Macintosh Cocoa display,
   `pc' for a direct-write MS-DOS frame.
   See also `frame-live-p'.

>  - 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)?

It's there for Unix where it makes sense.  We can remove it for Windows
until we know how to implement -t there.

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

I'd leave it as "" for now.

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

Yes, we should change it to only accept "", tho I'm not sure if it will
re-introduce the bug that was fixed by Chong's patch.

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

I don't see any reason why we'd want that since
(frame-parameter nil 'display) already works just fine for that purpose
and says clearly what it is doing.


        Stefan