Re: emacsclient on WXP does not work (as it used to)

[dhruva]

That was premature, it does not work.. I apologise for that.

On Fri, Oct 31, 2008 at 6:16 PM, dhruva <address@hidden> wrote:
> The following patch fixes this issue since tty and TERM does not make
> sense on windows (a wild guess though) ...
>
> diff --git a/lib-src/emacsclient.c b/lib-src/emacsclient.c
> index 0bbc385..0452cb3 100644
> --- a/lib-src/emacsclient.c
> +++ b/lib-src/emacsclient.c
> @@ -1446,7 +1446,6 @@ main (argc, argv)
>       char *tty_name = NULL;
>  #ifndef WINDOWSNT
>       tty_name = ttyname (fileno (stdout));
> -#endif
>
>       if (! tty_name)
>         {
> @@ -1468,15 +1467,19 @@ main (argc, argv)
>                    " is not supported\n", progname);
>           fail ();
>         }
> +#endif
> +
>  #if !defined (NO_SOCKETS_IN_FILE_SYSTEM)
>       init_signals ();
>  #endif
>
> +#ifndef WINDOWSNT
>       send_to_emacs (emacs_socket, "-tty ");
>       quote_argument (emacs_socket, tty_name);
>       send_to_emacs (emacs_socket, " ");
>       quote_argument (emacs_socket, type);
>       send_to_emacs (emacs_socket, " ");
> +#endif
>     }
>
>   if (window_system)
>
> On Fri, Oct 31, 2008 at 5:57 PM, Juanma Barranquero <address@hidden> wrote:
>> On Fri, Oct 31, 2008 at 12:15, Eli Zaretskii <address@hidden> wrote:
>>
>>> Can you please explain why is this a problem on Windows?  I understand
>>> that the addition of current_frame to the `if' clause causes it to be
>>> entered on Windows, whereas it wasn't before, but how does that, and
>>> the fact that tty_name is NULL, cause emacsclient failure reported by
>>> dhruva?
>>
>> I don't know why dhruva got the "connect" error message. My guess is
>> that they are two different problems:
>>
>>  1.- emacsclient opened the socket (so no INVALID_SOCKET), but couldn't 
>> connect
>>  2.- emacsclient couldn't get the terminal name, and it didn't have
>> alternate-editor
>>
>> though I don't know how or why 2) would happen, unless there were two
>> different emacsclients involved, called through alternate-editor (and
>> even so, it doesn't make much sense).
>>
>> But anyway, my point was just that the very next code after the if() is
>>
>>      char *type = egetenv ("TERM");
>>      char *tty_name = NULL;
>> #ifndef WINDOWSNT
>>      tty_name = ttyname (fileno (stdout));
>> #endif
>>
>>      if (! tty_name)
>>        {
>>          message (TRUE, "%s: could not get terminal name\n", progname);
>>          fail ();
>>        }
>>
>> so entering the if() is *always* going to fail(). I'm unable to see
>> how that be useful on Windows.
>>
>>> Agreed (to the ``ugly'' part).
>>
>> Glad we agree on this :)
>>
>> Have you any comment about the other part? ("Are there legitimate uses
>> of tty == 1 on Windows?")
>>
>>> I'd like to try to find a less ugly fix.
>>
>> It's Chong's patch, perhaps he can shed a bit of light.
>>
>>  Juanma
>>
>
>
>
> --
> Contents reflect my personal views only!
>



-- 
Contents reflect my personal views only!