23.0.50; DISPLAY env var bug on w32?

23.0.50; DISPLAY env var bug on w32?

[Lennart Borgman (gmail)]

I can not use emacsclient to open files unless I delete the 
environmental variable DISPLAY.

To reproduce the problem do

   emacs -Q
   M-x server-mode

Then from the command line try to open a file, for example

   emacsclient.exe COPYING

This fails with the message

   C:\emacs\u\080104\emacs\bin>emacsclient.exe COPYING
   Waiting for Emacs...
   *ERROR*: Don't know how to create a frame on window system x

I tried to remove "localhost" from the value, but that did not help:

   C:\emacs\u\080104\emacs\bin>set display
   DISPLAY=localhost:0.0

   C:\emacs\u\080104\emacs\bin>set display=:0.0

   C:\emacs\u\080104\emacs\bin>emacsclient.exe COPYING
   Waiting for Emacs...
   *ERROR*: Don't know how to create a frame on window system x

However deleting the environmental variable fixes the problem:

   C:\emacs\u\080104\emacs\bin>set display=

   C:\emacs\u\080104\emacs\bin>emacsclient.exe COPYING
   Waiting for Emacs...

PS: I do not know if DISPLAY is normally set on a w32 system (no other 
pc here to check with). The reason I have it might be due to that I am 
using a KVM switch.


In GNU Emacs 23.0.50.1 (i386-mingw-nt5.1.2600)
  of 2008-01-04 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include'

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: ENU
   locale-coding-system: cp1252
   default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
   server-mode: t
   tooltip-mode: t
   tool-bar-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   line-number-mode: t

Recent input:
M-x s e r v e r - m o d e <return> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <menu-bar> <help-menu>
<send-emacs-bug-report>

Recent messages:
Warning: no fonts matching `-*-dejavu sans 
mono-normal-r-normal-*-13-*-*-*-c-*-iso8859-1' available [2 times]
Warning: no fonts matching 
`-*-opensymbol-normal-r-normal-*-12-*-*-*-c-*-iso8859-1' available [2 times]
For information about GNU Emacs and the GNU system, type C-h C-a.
Server mode enabled
When done with a buffer, type C-x #

Re: 23.0.50; DISPLAY env var bug on w32?

[Dan Nicolaescu]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

  > I can not use emacsclient to open files unless I delete the
  > environmental variable DISPLAY.
  > 
  > To reproduce the problem do
  > 
  >   emacs -Q
  >   M-x server-mode
  > 
  > Then from the command line try to open a file, for example
  > 
  >   emacsclient.exe COPYING
  > 
  > This fails with the message
  > 
  >   C:\emacs\u\080104\emacs\bin>emacsclient.exe COPYING
  >   Waiting for Emacs...
  >   *ERROR*: Don't know how to create a frame on window system x

This is just a shot in the dark, but can you try to revert server.el to
version 1.136 and see if it works with that?

Re: 23.0.50; DISPLAY env var bug on w32?

[Lennart Borgman (gmail)]

Dan Nicolaescu wrote:
> This is just a shot in the dark, but can you try to revert server.el to
> version 1.136 and see if it works with that?

With a little help from Dan (thanks Dan!) I could confirm that it works 
with version 1.135.

But I doubt that reverting something is the right fix. At the moment I 
wonder if all that need to be fixed is perhaps emacsclient. Why should 
emacsclient send DISPLAY info to Emacs on w32?

There might be reasons that I am not aware of. (I do not remember 
anything about multiple displays on w32 right now.) If there are, then 
please see my previous messages about the frame parameters etc. Perhaps 
is the problem then that the first frame created after "emacs -Q" does 
not get its frame parameter 'display from the env var DISPLAY?

Re: 23.0.50; DISPLAY env var bug on w32?

[David De La Harpe Golden]

On 08/01/2008, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> But I doubt that reverting something is the right fix. At the moment I
> wonder if all that need to be fixed is perhaps emacsclient. Why should
> emacsclient send DISPLAY info to Emacs on w32?
>

Well, there are emacs that run on windows with _X11_ GUIs too: cygwin
and its X11 server and the cygwin build of emacs.   In that case, a
DISPLAY env var would be absolutely legit, and an emacsclient would be
expected to propagate it.

I don't really know anything about "multi-tty", so I wonder: is it
possible or planned to have a single emacs process that supports
_both_ w32 and X11 gui types?

Re: 23.0.50; DISPLAY env var bug on w32?

[Eli Zaretskii]

> Date: Tue, 08 Jan 2008 01:28:04 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> Cc: emacs-pretest-bug@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> But I doubt that reverting something is the right fix. At the moment I 
> wonder if all that need to be fixed is perhaps emacsclient. Why should 
> emacsclient send DISPLAY info to Emacs on w32?

It shouldn't.  I've fixed emacsclient to not notice $DISPLAY on
Windows; please try the latest CVS and see if your problem is gone.

Re: 23.0.50; DISPLAY env var bug on w32?

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Tue, 08 Jan 2008 01:28:04 +0100
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> Cc: emacs-pretest-bug@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
>>
>> But I doubt that reverting something is the right fix. At the moment I 
>> wonder if all that need to be fixed is perhaps emacsclient. Why should 
>> emacsclient send DISPLAY info to Emacs on w32?
> 
> It shouldn't.  I've fixed emacsclient to not notice $DISPLAY on
> Windows; please try the latest CVS and see if your problem is gone.

It is ok for me. (I have been using a similar patch since I sent that 
message.)

But what about multiple displays on w32?

Re: 23.0.50; DISPLAY env var bug on w32?

[Eli Zaretskii]

> Date: Sat, 12 Jan 2008 16:59:22 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: dann@ics.uci.edu, emacs-pretest-bug@gnu.org, 
>  monnier@iro.umontreal.ca
> 
> But what about multiple displays on w32?

What do you mean by ``multiple displays on w32''?  The -d DISPLAY
feature that is standard on X is not supported by Windows.

Re: 23.0.50; DISPLAY env var bug on w32?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 12 Jan 2008 16:59:22 +0100
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> CC: dann@ics.uci.edu, emacs-pretest-bug@gnu.org, 
>>  monnier@iro.umontreal.ca
>> 
>> But what about multiple displays on w32?
>
> What do you mean by ``multiple displays on w32''?  The -d DISPLAY
> feature that is standard on X is not supported by Windows.

What about people running an X server on Windows?  Like that from Cygwin
or Xceed or so?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: 23.0.50; DISPLAY env var bug on w32?

[Lennart Borgman (gmail)]

David Kastrup wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> Date: Sat, 12 Jan 2008 16:59:22 +0100
>>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>>> CC: dann@ics.uci.edu, emacs-pretest-bug@gnu.org, 
>>>  monnier@iro.umontreal.ca
>>>
>>> But what about multiple displays on w32?
>> What do you mean by ``multiple displays on w32''?  The -d DISPLAY
>> feature that is standard on X is not supported by Windows.
> 
> What about people running an X server on Windows?  Like that from Cygwin
> or Xceed or so?

Beside that you can have multiple monitors on w32 too, but I do not know 
anything about that.

Re: 23.0.50; DISPLAY env var bug on w32?

[Eli Zaretskii]

> Date: Sat, 12 Jan 2008 19:11:04 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: Eli Zaretskii <eliz@gnu.org>, emacs-pretest-bug@gnu.org, 
>  dann@ics.uci.edu, monnier@iro.umontreal.ca
> 
> David Kastrup wrote:
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> >>> Date: Sat, 12 Jan 2008 16:59:22 +0100
> >>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> >>> CC: dann@ics.uci.edu, emacs-pretest-bug@gnu.org, 
> >>>  monnier@iro.umontreal.ca
> >>>
> >>> But what about multiple displays on w32?
> >> What do you mean by ``multiple displays on w32''?  The -d DISPLAY
> >> feature that is standard on X is not supported by Windows.
> > 
> > What about people running an X server on Windows?  Like that from Cygwin
> > or Xceed or so?
> 
> Beside that you can have multiple monitors on w32 too, but I do not know 
> anything about that.

The -d DISPLAY option is not the right mechanism for supporting that,
unless someone teaches the Windows port of Emacs how to do that.
Right now, using -d DISPLAY on Windows causes nothing but trouble.

Re: 23.0.50; DISPLAY env var bug on w32?

[Juanma Barranquero]

On Jan 13, 2008 5:17 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Right now, using -d DISPLAY on Windows causes nothing but trouble.

-t / --tty is not specially useful either:

C:\emacs> emacsclient -t
emacsclient: could not get terminal name

             Juanma

Re: 23.0.50; DISPLAY env var bug on w32?

[Eli Zaretskii]

> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>         d=gmail.com; s=gamma;
>         h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
>         bh=VUlkbHWoV2nDELP47C4axYnVlY5G+iGkBjZkWd8B0xE=;
>         b=hnqUBf4PO38Ym0CT/Vid5HpjODLSp88KZDtH244Y8Bg+6sgsZu0u3Uir/26fFkDH+43AM+Nxsz5o9O5eSKycEryfFpPX/ocCTPAsrr4cNqdQZ4xXPwFR+Zsu1Fc7KLFU2Rt5G3KsXtcBm5oW0wPvImAHicCtAvswPsEu/g0mmFk=
> Date: Sun, 13 Jan 2008 05:30:19 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>, dann@ics.uci.edu, 
> 	emacs-pretest-bug@gnu.org, monnier@iro.umontreal.ca
> 
> On Jan 13, 2008 5:17 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Right now, using -d DISPLAY on Windows causes nothing but trouble.
> 
> -t / --tty is not specially useful either:
> 
> C:\emacs> emacsclient -t
> emacsclient: could not get terminal name

Feel free to ifdef away that one as well.

Re: 23.0.50; DISPLAY env var bug on w32?

[Stefan Monnier]

>> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>> d=gmail.com; s=gamma;
>> h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
>> bh=VUlkbHWoV2nDELP47C4axYnVlY5G+iGkBjZkWd8B0xE=;
>> b=hnqUBf4PO38Ym0CT/Vid5HpjODLSp88KZDtH244Y8Bg+6sgsZu0u3Uir/26fFkDH+43AM+Nxsz5o9O5eSKycEryfFpPX/ocCTPAsrr4cNqdQZ4xXPwFR+Zsu1Fc7KLFU2Rt5G3KsXtcBm5oW0wPvImAHicCtAvswPsEu/g0mmFk=
>> Date: Sun, 13 Jan 2008 05:30:19 +0100
>> From: "Juanma Barranquero" <lekktu@gmail.com>
>> Cc: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>, dann@ics.uci.edu, 
>> emacs-pretest-bug@gnu.org, monnier@iro.umontreal.ca
>> 
>> On Jan 13, 2008 5:17 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> > Right now, using -d DISPLAY on Windows causes nothing but trouble.
>> 
>> -t / --tty is not specially useful either:
>> 
>> C:\emacs> emacsclient -t
>> emacsclient: could not get terminal name

> Feel free to ifdef away that one as well.

Just like the -d option, I think it can stay.  These are options that
simply fail to work.  The original bug is that even without any option
the command failed because it eagerly tried to add a DISPLAY argument,
which was a lot more problematic.


        Stefan

Re: 23.0.50; DISPLAY env var bug on w32?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: "Juanma Barranquero" <lekktu@gmail.com>,  lennart.borgman@gmail.com,  dann@ics.uci.edu,  emacs-pretest-bug@gnu.org
> Date: Sun, 13 Jan 2008 16:41:31 -0500
> 
> >> > Right now, using -d DISPLAY on Windows causes nothing but trouble.
> >> 
> >> -t / --tty is not specially useful either:
> >> 
> >> C:\emacs> emacsclient -t
> >> emacsclient: could not get terminal name
> 
> > Feel free to ifdef away that one as well.
> 
> Just like the -d option, I think it can stay.

For what purpose?  I think it's wrong to advertise (by --help) options
that don't work or, worse, cause trouble.

> These are options that simply fail to work.

Right, so why have them?

Re: 23.0.50; DISPLAY env var bug on w32?

[Stefan Monnier]

>> >> > Right now, using -d DISPLAY on Windows causes nothing but trouble.
>> >> 
>> >> -t / --tty is not specially useful either:
>> >> 
>> >> C:\emacs> emacsclient -t
>> >> emacsclient: could not get terminal name
>> 
>> > Feel free to ifdef away that one as well.
>> 
>> Just like the -d option, I think it can stay.

> For what purpose?  I think it's wrong to advertise (by --help) options
> that don't work or, worse, cause trouble.

>> These are options that simply fail to work.

> Right, so why have them?

On the off chance that the w32 emacsclient manages to talk to a cygwin
emacsserver that does understand -d and -t.

In any case, I think that most of this work should be done on the
server.el side anyway.  I just don't have the time to code it up.


        Stefan

Re: 23.0.50; DISPLAY env var bug on w32?

[Jason Rumney]

Stefan Monnier wrote:
>>>>>> Right now, using -d DISPLAY on Windows causes nothing but trouble.
>>>>>>             
>>>>> -t / --tty is not specially useful either:
>>>>>
>>>>> C:\emacs> emacsclient -t
>>>>> emacsclient: could not get terminal name
>>>>>           
>>>> Feel free to ifdef away that one as well.
>>>>         
>>> Just like the -d option, I think it can stay.
>>>       
>
>   
>> For what purpose?  I think it's wrong to advertise (by --help) options
>> that don't work or, worse, cause trouble.
>>     
>
>   
>>> These are options that simply fail to work.
>>>       
>
>   
>> Right, so why have them?
>>     
>
> On the off chance that the w32 emacsclient manages to talk to a cygwin
> emacsserver that does understand -d and -t.
>   

Not just cygwin, emacsclient can be used to contact a remote server too, 
and a user may find that more convenient than using tramp in some 
circumstances.

Re: 23.0.50; DISPLAY env var bug on w32?

[Eli Zaretskii]

> Date: Mon, 14 Jan 2008 15:13:14 +0000
> From: Jason Rumney <jasonr@gnu.org>
> CC: Eli Zaretskii <eliz@gnu.org>, lekktu@gmail.com, dann@ics.uci.edu, 
>  lennart.borgman@gmail.com, emacs-pretest-bug@gnu.org
> 
> Not just cygwin, emacsclient can be used to contact a remote server too, 

How does one invoke the w32 emacsclient for this?

Re: 23.0.50; DISPLAY env var bug on w32?

[Jason Rumney]

Eli Zaretskii wrote:
> How does one invoke the w32 emacsclient for this?
>   

With an appropriate server-file pointing to the destination server.

Re: 23.0.50; DISPLAY env var bug on w32?

[Eli Zaretskii]

> Date: Mon, 14 Jan 2008 23:19:08 +0000
> From: Jason Rumney <jasonr@gnu.org>
> CC: monnier@iro.umontreal.ca, lekktu@gmail.com, dann@ics.uci.edu, 
>  lennart.borgman@gmail.com, emacs-pretest-bug@gnu.org
> 
> Eli Zaretskii wrote:
> > How does one invoke the w32 emacsclient for this?
> >   
> 
> With an appropriate server-file pointing to the destination server.

Example, please.  I'd like to modify the code so that in that case the
display spec is honored.

Re: 23.0.50; DISPLAY env var bug on w32?

[Jason Rumney]

Eli Zaretskii wrote:
> Example, please.  I'd like to modify the code so that in that case the
> display spec is honored.
>   

If the IP address in the server file is not 127.0.0.1, it is possible 
that the server is a non-Windows one. But even if it is 127.0.0.1, it 
could be a cygwin build of Emacs, so I think emacsclient should always 
honour the display spec, and any filtering out on Windows should be done 
in server.el.

Re: 23.0.50; DISPLAY env var bug on w32?

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: "Lennart Borgman \(gmail\)" <lennart.borgman@gmail.com>,  emacs-pretest-bug@gnu.org,  dann@ics.uci.edu,  monnier@iro.umontreal.ca
> Date: Sat, 12 Jan 2008 19:06:42 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Sat, 12 Jan 2008 16:59:22 +0100
> >> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> >> CC: dann@ics.uci.edu, emacs-pretest-bug@gnu.org, 
> >>  monnier@iro.umontreal.ca
> >> 
> >> But what about multiple displays on w32?
> >
> > What do you mean by ``multiple displays on w32''?  The -d DISPLAY
> > feature that is standard on X is not supported by Windows.
> 
> What about people running an X server on Windows?  Like that from Cygwin
> or Xceed or so?

Cygwin build of emacsclient will not get the change (it doesn't define
WINDOWSNT).  In the Xceed case, emacsclient would have been run on
Unix, so again it won't be affected by the change.

Re: 23.0.50; DISPLAY env var bug on w32?

[Robert J. Chassell]

Lennart Borgman wrote,

    To reproduce the problem do

       emacs -Q
       M-x server-mode

    Then from the command line try to open a file, for example

       emacsclient.exe COPYING

    This fails with the message

       C:\emacs\u\080104\emacs\bin>emacsclient.exe COPYING
       Waiting for Emacs...
       *ERROR*: Don't know how to create a frame on window system x

I see COPYING on a GNU/Linux Debian distribution with the CVS instance
updated this morning at 10:47 UTC when I do

       /usr/local/src/emacs/src/emacs -Q
       M-x server-mode

with the use of

    emacsclient /usr/local/src/emacs/etc/COPYING

The value of the DISPLAY variable is:

    echo $DISPLAY
    :0.0

Also, I can cause COPYING to appear in another frame with 

    emacsclient -c /usr/local/src/emacs/etc/COPYING

As far as I know, Microsoft uses backslashes rather than forward
slashes; if so and you are using Microsoft only operating system,
unless you do something else, your example would not know of the X
Windowing system.

I see

    Windowing system distributor `Microsoft Corp.', version 5.1.2600
    configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include'

Does that windowing system know about the X Windowing system?

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: 23.0.50; DISPLAY env var bug on w32?

[Eli Zaretskii]

> Date: Mon, 7 Jan 2008 21:13:29 +0000 (UTC)
> From: "Robert J. Chassell" <bob@rattlesnake.com>
> Cc: 
> 
>     emacsclient -c /usr/local/src/emacs/etc/COPYING
> 
> As far as I know, Microsoft uses backslashes rather than forward
> slashes

No, the MS file-name API accepts forward slashes as well as
backslashes.

>     Windowing system distributor `Microsoft Corp.', version 5.1.2600
>     configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include'
> 
> Does that windowing system know about the X Windowing system?

No, of course not.

Re: 23.0.50; DISPLAY env var bug on w32?

[Eli Zaretskii]

> Date: Mon, 07 Jan 2008 19:45:42 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> Cc: 
> 
> PS: I do not know if DISPLAY is normally set on a w32 system

It isn't.  DISPLAY is standard on X, but not on other windowing
systems.

Re: 23.0.50; DISPLAY env var bug on w32?

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Mon, 07 Jan 2008 19:45:42 +0100
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> Cc: 
>>
>> PS: I do not know if DISPLAY is normally set on a w32 system
> 
> It isn't.  DISPLAY is standard on X, but not on other windowing
> systems.

Thanks, Eli, I suspected that is why this/these bugs have not been 
discovered before.

I got some problems sending to Emacs bugs earlier today so I am 
resending what I tried to send then. (I sent it to devel but it seems 
better to have it all here.) In this message I looked through the code 
to try to understand what happens on w32.

-------- Original Message --------
Subject: Mail delivery failed: returning message to sender
Date: Mon, 07 Jan 2008 15:23:02 -0500
From: Mail Delivery System <Mailer-Daemon@gnu.org>

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

   emacs-pretest-bug@gnu.org
     SMTP error from remote mail server after RCPT 
TO:<emacs-pretest-bug@gnu.org>:
     host fencepost.gnu.org [140.186.70.10]: 550 unknown user

============================
Lennart Borgman (gmail) wrote:
 > I can not use emacsclient to open files unless I delete the 
environmental variable DISPLAY.
 >
 > To reproduce the problem do
 >
 >   emacs -Q
 >   M-x server-mode
 >
 > Then from the command line try to open a file, for example
 >
 >   emacsclient.exe COPYING
 >
 > This fails with the message
 >
 >   C:\emacs\u\080104\emacs\bin>emacsclient.exe COPYING
 >   Waiting for Emacs...
 >   *ERROR*: Don't know how to create a frame on window system x

It looks like several possible bugs to me. A call from emacsclient leads to

    server-process-filter

and since tty-name is nil this calls

    server-select-display

In this function there is a check

     (equal (frame-parameter (selected-frame) 'display) display))

This fails since (frame-parameter (selected-frame) 'display) returns "".
   I would expect it to return "localhost:0.0" in my case. The reason for
this is explained further below.

Now this leads to a call to

    make-frame-on-display

which finishes with a line at the bottom saying

    (make-frame `((window-system . x) (display . ,display) .
      ,parameters)))

The correct window-system seems to be 'w32 in my case, since that is
what works inf make-frame. The variable frame-creation-function-alist
used there is

    ((w32 . x-create-frame-with-faces)
     (nil . tty-create-frame-with-faces))

If I use this then the frame actually get the display property
"localhost:0.0" and that is why I believe that this is what it should
have from the beginning. So this is bug 1 here I believe.

But 2 is the hard coded value in the last line of make-frame-on-display.
It looks like window-system should be something different there.

When I try to find out what I see in server-process-filter some lines saying

          ;; -window-system:  Open a new X frame.
          ((equal "-window-system" arg)
                    (setq dontkill t)
                    (setq tty-name 'window-system))

Those are a bit surprising to me since I expect an analogous use of
something called "window-system" throughout the code. Obviously that is
not the case here.

And here I stop speculating because there might be some mistake in the
structure here. Someone who understands this code better than I do can
perhaps see more clearly what is needed.