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

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

[dhruva]

Hi,
 With recent (day old) changes to emacsclient and server.el, I am not
able to open a file in a running session of emacs.
When I run 'emacsclient some_file' I get the following error even
though I have a session of emacs running (in window mode)

emacsclient: connect: No connection could be made because the target
machine actively refused it.

emacsclient: No socket or alternate editor.  Please use:

        --server-file      (or environment variable EMACS_SERVER_FILE)
        --alternate-editor (or environment variable ALTERNATE_EDITOR)

The output of command 'list-processes' in emacs:
Proc   Status	Buffer Command
----   ------	------ -------
server listen	(none) (network stream server on 1118)

-dhruva

-- 
Contents reflect my personal views only!

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

[Juanma Barranquero]

On Fri, Oct 31, 2008 at 11:35, dhruva <dhruvakm@gmail.com> wrote:

> When I run 'emacsclient some_file' I get the following error even
> though I have a session of emacs running (in window mode)
>
> emacsclient: connect: No connection could be made because the target
> machine actively refused it.

Yes, this change:

http://cvs.savannah.gnu.org/viewvc/emacs/emacs/lib-src/emacsclient.c?r1=1.135&r2=1.136&pathrev=MAIN

is wrong, because on Windows, once inside the if(), tty_name is always
going to be NULL.

I wonder why the whole if isn't just #ifdef'd out. Are there
legitimate uses of tty == 1 on Windows?

The attached patch fixes the problem, but it's ugly as hell.

  Juanma


Index: lib-src/emacsclient.c
===================================================================
RCS file: /sources/emacs/emacs/lib-src/emacsclient.c,v
retrieving revision 1.136
diff -u -2 -r1.136 emacsclient.c
--- lib-src/emacsclient.c	30 Oct 2008 15:54:38 -0000	1.136
+++ lib-src/emacsclient.c	31 Oct 2008 11:00:45 -0000
@@ -1441,5 +1441,9 @@
      In daemon mode, Emacs may need to occupy this tty if no other
      frame is available.  */
-  if (tty || current_frame)
+  if (tty
+#ifndef WINDOWSNT
+      || current_frame
+#endif
+      )
     {
       char *type = egetenv ("TERM");

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

[Eli Zaretskii]

> Date: Fri, 31 Oct 2008 12:02:12 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> Yes, this change:
> 
> http://cvs.savannah.gnu.org/viewvc/emacs/emacs/lib-src/emacsclient.c?r1=1.135&r2=1.136&pathrev=MAIN
> 
> is wrong, because on Windows, once inside the if(), tty_name is always
> going to be NULL.

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 wonder why the whole if isn't just #ifdef'd out. Are there
> legitimate uses of tty == 1 on Windows?
> 
> The attached patch fixes the problem, but it's ugly as hell.

Agreed (to the ``ugly'' part).  I'd like to try to find a less ugly
fix.

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

[Juanma Barranquero]

On Fri, Oct 31, 2008 at 12:15, Eli Zaretskii <eliz@gnu.org> 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

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

[dhruva]

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 <lekktu@gmail.com> wrote:
> On Fri, Oct 31, 2008 at 12:15, Eli Zaretskii <eliz@gnu.org> 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!

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 <dhruvakm@gmail.com> 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 <lekktu@gmail.com> wrote:
>> On Fri, Oct 31, 2008 at 12:15, Eli Zaretskii <eliz@gnu.org> 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!

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

[Juanma Barranquero]

On Fri, Oct 31, 2008 at 13:46, dhruva <dhruvakm@gmail.com> wrote:

> The following patch fixes this issue since tty and TERM does not make
> sense on windows (a wild guess though) ...

Yes, I said as much.

That does not answer the question, why are you getting two different
messages, one for connect (presumably from set_tcp_socket) and the
other from fail via the main() code we're discussing.

Which arguments / env vars did you use when running that emacsclient?

  Juanma

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

[Juanma Barranquero]

On Fri, Oct 31, 2008 at 13:52, dhruva <dhruvakm@gmail.com> wrote:

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

What output do you get with your patch applied?

  Juanma

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

[dhruva]

Hi,

On Fri, Oct 31, 2008 at 6:23 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Fri, Oct 31, 2008 at 13:52, dhruva <dhruvakm@gmail.com> wrote:
>
>> That was premature, it does not work.. I apologise for that.
>
> What output do you get with your patch applied?

Well.... it did work! I was using the wrong binary in the PATH :(

-- 
Contents reflect my personal views only!

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

[dhruva]

The second failure is because I did not use '-a' option to emacsclient

On Fri, Oct 31, 2008 at 6:22 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Fri, Oct 31, 2008 at 13:46, dhruva <dhruvakm@gmail.com> wrote:
>
>> The following patch fixes this issue since tty and TERM does not make
>> sense on windows (a wild guess though) ...
>
> Yes, I said as much.
>
> That does not answer the question, why are you getting two different
> messages, one for connect (presumably from set_tcp_socket) and the
> other from fail via the main() code we're discussing.
>
> Which arguments / env vars did you use when running that emacsclient?
>
>  Juanma
>



-- 
Contents reflect my personal views only!

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

[Juanma Barranquero]

On Fri, Oct 31, 2008 at 13:58, dhruva <dhruvakm@gmail.com> wrote:

> The second failure is because I did not use '-a' option to emacsclient

You're right. I'm having a bad day, and it seems I'm not thinking straight.

Now the question is, you were getting a "connect" error. How is that
related to entering the if()? When I run emacsclient, the error I get
is "could not get terminal name", as expected.

  Juanma

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

[dhruva]

Hi,
 I figured it out... I guess. The port is same as pid of the process.
I guess I had 2 sessions of emacs running and one in which server was
not. The client finds the one without the server running and tries to
connect to a port with the pid of that emacs. Hence, it fails. I think
we should use some UDP based discovery of running emacs if it is not
too tough...

On Fri, Oct 31, 2008 at 6:40 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Fri, Oct 31, 2008 at 13:58, dhruva <dhruvakm@gmail.com> wrote:
>
>> The second failure is because I did not use '-a' option to emacsclient
>
> You're right. I'm having a bad day, and it seems I'm not thinking straight.
>
> Now the question is, you were getting a "connect" error. How is that
> related to entering the if()? When I run emacsclient, the error I get
> is "could not get terminal name", as expected.
>
>  Juanma
>



-- 
Contents reflect my personal views only!

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

[dhruva]

Recipe for reproducing the problem:

1. Start emacs with server
2. Use emacsclient to open a file (with -n option not to wait)
3. Start another emacs with server
4. Use emacsclient as in #2 (it will open in emacs on #3 for me)
5. Kill emacs started in #3
6. Use emacsclient and you get the error!

On Fri, Oct 31, 2008 at 7:08 PM, dhruva <dhruvakm@gmail.com> wrote:
> Hi,
>  I figured it out... I guess. The port is same as pid of the process.
> I guess I had 2 sessions of emacs running and one in which server was
> not. The client finds the one without the server running and tries to
> connect to a port with the pid of that emacs. Hence, it fails. I think
> we should use some UDP based discovery of running emacs if it is not
> too tough...
>
> On Fri, Oct 31, 2008 at 6:40 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>> On Fri, Oct 31, 2008 at 13:58, dhruva <dhruvakm@gmail.com> wrote:
>>
>>> The second failure is because I did not use '-a' option to emacsclient
>>
>> You're right. I'm having a bad day, and it seems I'm not thinking straight.
>>
>> Now the question is, you were getting a "connect" error. How is that
>> related to entering the if()? When I run emacsclient, the error I get
>> is "could not get terminal name", as expected.
>>
>>  Juanma
>>
>
>
>
> --
> Contents reflect my personal views only!
>



-- 
Contents reflect my personal views only!

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

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

>> I'd like to try to find a less ugly fix.
>
> It's Chong's patch, perhaps he can shed a bit of light.

This was for bug#1267.

The goal was to pass the tty to the Emacs server even if we're supposed
to use the current frame, because in daemon mode, if the "current frame"
is the fake daemon frame, we wan to be able to fall back on using that
tty.

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

[Juanma Barranquero]

On Fri, Oct 31, 2008 at 15:13, Chong Yidong <cyd@stupidchicken.com> wrote:

> This was for bug#1267.
>
> The goal was to pass the tty to the Emacs server even if we're supposed
> to use the current frame, because in daemon mode, if the "current frame"
> is the fake daemon frame, we wan to be able to fall back on using that
> tty.

Yes, but that should be conditional on Windows, where tty is (I think) not used.

   Juanma

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

[Juanma Barranquero]

On Fri, Oct 31, 2008 at 14:40, dhruva <dhruvakm@gmail.com> wrote:

> Recipe for reproducing the problem:
>
> 1. Start emacs with server
> 2. Use emacsclient to open a file (with -n option not to wait)
> 3. Start another emacs with server
> 4. Use emacsclient as in #2 (it will open in emacs on #3 for me)
> 5. Kill emacs started in #3
> 6. Use emacsclient and you get the error!

Using the trunk's emacsclient I cannot even do 2, because I get an error:

  emasclient: could not get terminal name

But other than that, your problem is not related to recent changes in
the trunk. You're overwriting the default TCP authentication file
~/.emacs.d/server/server. If you start several servers simultaneously,
you must give them different `server-name's.

> I think we should use some UDP based discovery of running emacs if it is not
> too tough...

You'll open the door to complexity and race conditions for little gain IMHO.

  Juanma

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

[Juanma Barranquero]

On Fri, Oct 31, 2008 at 15:22, Juanma Barranquero <lekktu@gmail.com> wrote:

> You'll open the door to complexity and race conditions for little gain IMHO.

That said, in my .emacs I have code in server-hook to check whether an
authentication file already exists, and if so, whether the PID stored
there is the same as the one for the Emacs instance that is doing the
check. So what I do is refusing to start a server if another one with
the same `server-name' is still running (more or less).

  Juanma

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

[dhruva]

Hi,

On Fri, Oct 31, 2008 at 7:57 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Fri, Oct 31, 2008 at 15:22, Juanma Barranquero <lekktu@gmail.com> wrote:
>
>> You'll open the door to complexity and race conditions for little gain IMHO.
>
> That said, in my .emacs I have code in server-hook to check whether an
> authentication file already exists, and if so, whether the PID stored
> there is the same as the one for the Emacs instance that is doing the
> check. So what I do is refusing to start a server if another one with
> the same `server-name' is still running (more or less).

IMO, that could be the default behavior of server with an option to
force the server start.

-dhruva

-- 
Contents reflect my personal views only!

Newsticker is jealous

[Paul R]

Hello,

I've been using newsticker 1.99 in treeview mode since I use emacs23.
Today I noticed a bug. It may be related to the retrieval method that
I changed recently, now I use wget external tool.

To reproduce, set the retrieval method to gnus, run newsticker in
treeview, then pop up scratch buffer and hit C-x 1. Now you can't see
any pane of newsticker, and he feels bad about that. Whenever he will
retreive some feeds, it will raise the error below :

-----------------------------------------

Debugger entered--Lisp error: (wrong-type-argument window-live-p #<window 6>)
  set-window-buffer(#<window 6> #<buffer *Newsticker List*>)
  (save-excursion (set-window-buffer (newsticker--treeview-list-window) (newsticker--treeview-list-buffer)) (set-buffer (newsticker--treeview-list-buffer)) (if clear-buffer (let ... ...)) (newsticker-treeview-list-mode) (newsticker--treeview-list-update-faces) (goto-char (point-min)))
  newsticker--treeview-list-update(t)
  newsticker-treeview-update()
  funcall(newsticker-treeview-update)
  (progn (funcall newsticker--sentinel-callback))
  (if newsticker--sentinel-callback (progn (funcall newsticker--sentinel-callback)))
  (when newsticker--sentinel-callback (funcall newsticker--sentinel-callback))
  newsticker--sentinel-work("finished\n" t "Planet GNOME" ("wget" "-q" "-O" "-" "http://planet.gnome.org/rss20.xml") #<killed buffer>)
  (let ((p-status ...) (exit-status ...) (name ...) (command ...) (buffer ...)) (newsticker--sentinel-work event (and ... ...) name command buffer))
  newsticker--sentinel(#<process Planet GNOME> "finished\n")

-----------------------------------------

Below are some infos on the build and the modes

In GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
 of 2008-10-30 on ubuT42
Windowing system distributor `The X.Org Foundation', version 11.0.10400090
configured using `configure  '--prefix=/home/paul/Software/local' '--program-suffix=.emacs-23.0.60' '--with-x-toolkit=gtk''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: fr_FR.UTF-8
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: en_US.UTF-8
  value of $LC_MONETARY: fr_FR.UTF-8
  value of $LC_NUMERIC: fr_FR.UTF-8
  value of $LC_TIME: fr_FR.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Debugger

Minor modes in effect:
  shell-dirtrack-mode: t
  csv-field-index-mode: t
  display-time-mode: t
  show-paren-mode: t
  icomplete-mode: t
  iswitchb-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

-- 
  Paul

Re: Newsticker is jealous

[Paul R]

Paul> Hello, I've been using newsticker 1.99 in treeview mode since
Paul> I use emacs23. Today I noticed a bug. It may be related to the
Paul> retrieval method that I changed recently, now I use wget external
Paul> tool.

please forget this post with wrong references, I messed up. I just sent
a duplicate in its own thread.

-- 
  Paul

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

[Eli Zaretskii]

> Date: Fri, 31 Oct 2008 15:14:42 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, emacs-devel@gnu.org
> 
> On Fri, Oct 31, 2008 at 15:13, Chong Yidong <cyd@stupidchicken.com> wrote:
> 
> > This was for bug#1267.
> >
> > The goal was to pass the tty to the Emacs server even if we're supposed
> > to use the current frame, because in daemon mode, if the "current frame"
> > is the fake daemon frame, we wan to be able to fall back on using that
> > tty.
> 
> Yes, but that should be conditional on Windows, where tty is (I think) not used.

What will happen if we provide an emulation of `ttyname' for Windows,
which would just return something like "CONOUT$"?  Since daemon mode
is not used on Windows, I think the tty name should never be used by
server.el on Windows.

Can you try this and see if it works?  If it does, then we can fix
this problem much cleaner, and even remove an existing ifndef.

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

[dhruva]

Even this works!

diff --git a/lib-src/emacsclient.c b/lib-src/emacsclient.c
index 0bbc385..6d2d2c4 100644
--- a/lib-src/emacsclient.c
+++ b/lib-src/emacsclient.c
@@ -1446,6 +1446,9 @@ main (argc, argv)
       char *tty_name = NULL;
 #ifndef WINDOWSNT
       tty_name = ttyname (fileno (stdout));
+#else
+      type = "CMD";
+      tty_name = "CON";
 #endif

       if (! tty_name)

On Fri, Oct 31, 2008 at 8:14 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 31 Oct 2008 15:14:42 +0100
>> From: "Juanma Barranquero" <lekktu@gmail.com>
>> Cc: "Eli Zaretskii" <eliz@gnu.org>, emacs-devel@gnu.org
>>
>> On Fri, Oct 31, 2008 at 15:13, Chong Yidong <cyd@stupidchicken.com> wrote:
>>
>> > This was for bug#1267.
>> >
>> > The goal was to pass the tty to the Emacs server even if we're supposed
>> > to use the current frame, because in daemon mode, if the "current frame"
>> > is the fake daemon frame, we wan to be able to fall back on using that
>> > tty.
>>
>> Yes, but that should be conditional on Windows, where tty is (I think) not used.
>
> What will happen if we provide an emulation of `ttyname' for Windows,
> which would just return something like "CONOUT$"?  Since daemon mode
> is not used on Windows, I think the tty name should never be used by
> server.el on Windows.
>
> Can you try this and see if it works?  If it does, then we can fix
> this problem much cleaner, and even remove an existing ifndef.
>
>
>



-- 
Contents reflect my personal views only!

Re: Newsticker is jealous

[Ulf Jasper]

Paul R <paul.r.ml@gmail.com> writes:
> Paul> Hello, I've been using newsticker 1.99 in treeview mode since
> Paul> I use emacs23. Today I noticed a bug. It may be related to the
> Paul> retrieval method that I changed recently, now I use wget external
> Paul> tool.

Newsticker is not jealous. It's stupid. It gets confused when the window
layout changes. (This does not depend on the retrieval method.)

I'll fix that.

ulf

-- 
Klicken Sie HIER und Sie erhalten vier Dosen umsonst

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

[Andreas Schwab]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Fri, Oct 31, 2008 at 15:13, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> This was for bug#1267.
>>
>> The goal was to pass the tty to the Emacs server even if we're supposed
>> to use the current frame, because in daemon mode, if the "current frame"
>> is the fake daemon frame, we wan to be able to fall back on using that
>> tty.
>
> Yes, but that should be conditional on Windows, where tty is (I think) not used.

On Unix the emacsclient process also might not have a tty, which now
causes it to fail silently.  This is especially bad if you want to run
"emacsclient --eval" from the desktop.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Eli Zaretskii]

> Date: Fri, 31 Oct 2008 20:51:33 +0530
> From: dhruva <dhruvakm@gmail.com>
> Cc: "Juanma Barranquero" <lekktu@gmail.com>, cyd@stupidchicken.com, 
> 	emacs-devel@gnu.org
> 
> Even this works!
> 
> diff --git a/lib-src/emacsclient.c b/lib-src/emacsclient.c
> index 0bbc385..6d2d2c4 100644
> --- a/lib-src/emacsclient.c
> +++ b/lib-src/emacsclient.c
> @@ -1446,6 +1446,9 @@ main (argc, argv)
>        char *tty_name = NULL;
>  #ifndef WINDOWSNT
>        tty_name = ttyname (fileno (stdout));
> +#else
> +      type = "CMD";
> +      tty_name = "CON";
>  #endif

Thanks.  I checked in a slightly different change, which eliminates
the need for this and one other ifdef.  Could you two please see if
the new version works for you?  Please be sure to try -t and -c
switches as well.

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

[Juanma Barranquero]

On Sat, Nov 1, 2008 at 14:53, Eli Zaretskii <eliz@gnu.org> wrote:

> Could you two please see if
> the new version works for you?  Please be sure to try -t and -c
> switches as well.

Running

   emacs -q --eval "(server-mode 1)"
   emacsclient -t   ;; or emacsclient -c

I get the attached assertion failure.

             Juanma



font.c:2602: Emacs fatal error: assertion failed: CONSP((val))

Breakpoint 1, w32_abort () at w32fns.c:7279
7279      button = MessageBox (NULL,
(gdb) bt
#0  w32_abort () at w32fns.c:7279
#1  0x0101d5eb in die (msg=0x147ccac "assertion failed: CONSP((val))",
file=0x147c300 "font.c", line=2602) at alloc.c:6216
#2  0x011a4192 in font_get_cache (f=<value optimized out>,
driver=<value optimized out>) at font.c:2602
#3  0x011b1524 in font_list_entities (frame=48517636, spec=48417092)
at font.c:2753
#4  0x011b2140 in font_find_for_lface (f=0x2e45200, attrs=0x82c8a4,
spec=48811652, c=-1) at font.c:3241
#5  0x011b492c in font_load_for_lface (f=0x2e45200, attrs=0x82c8a4,
spec=48811652) at font.c:3357c:5341
#6  0x011e9f06 in realize_face (cache=0x3260540, attrs=0x82c8a4,
former_face_id=<value optimized out>) at xfaces.c:588808865,
#7  0x011edf7a in realize_named_face (f=<value optimized out>,
symbol=47945569, id=2) at xfaces.c:5750
#8  0x011ee351 in realize_basic_faces (f=0x2e45200) at xfaces.c:5562
prev_event=47908865, used_mouse_menu=0x82fc24,
#9  0x011ef036 in recompute_basic_faces (f=0x2e45200) at xfaces.c:916
#10 0x0103aae9 in init_iterator (it=0x82ca54, w=0x2e45a00, charpos=-1,
bytepos=-1, row=0x0, base_face_id=DEFAULT_FACE_ID)
    at xdisp.c:2599ch_frame=1, fix_current_buffer=1) at keyboard.c:9344
#11 0x0103f4c5 in x_consider_frame_title (frame=<value optimized out>)
at xdisp.c:9435
#12 0x0103f918 in prepare_menu_bars () at xdisp.c:95195d4f
<command_loop_1>, handlers=47972617, hfun=0x108cf87 <cmd_error>)
#13 0x010481f0 in redisplay_internal (preserve_echo_area=<value
optimized out>) at xdisp.c:11426
#14 0x0104954c in echo_area_display (update_frame_p=1) at xdisp.c:9178
#15 0x01049870 in message3_nolog (m=49636387, nbytes=39, multibyte=0)
at xdisp.c:8039
#16 0x01049b2c in message3 (m=49636387, nbytes=39, multibyte=0) at xdisp.c:7974
#17 0x01170980 in Fmessage (nargs=2, args=0x82da34) at editfns.c:3382
#18 0x01019ddf in Ffuncall (nargs=3, args=0x82da30) at eval.c:3025s/gpl.html>
#19 0x01146b54 in Fbyte_code (bytestr=57379475, vector=63373956,
maxdepth=<value optimized out>) at bytecode.c:678
#20 0x0101be24 in Feval (form=62804325) at eval.c:2381 Type "show copying"
#21 0x0101cd03 in internal_lisp_condition_case (var=48397033,
bodyform=62804325, handlers=62797757) at eval.c:1456
#22 0x011473e5 in Fbyte_code (bytestr=57379603, vector=61339332,
maxdepth=<value optimized out>) at bytecode.c:868
#23 0x0101c486 in funcall_lambda (fun=61339204, nargs=7,
arg_vector=0x82dd04) at eval.c:3231
#24 0x01019bcc in Ffuncall (nargs=8, args=0x82dd00) at eval.c:3090t
from terminal]
#25 0x01146b54 in Fbyte_code (bytestr=57378499, vector=48807940,
maxdepth=<value optimized out>) at bytecode.c:678
#26 0x0101c486 in funcall_lambda (fun=61339748, nargs=8,
arg_vector=0x82de94) at eval.c:3231
#27 0x01019bcc in Ffuncall (nargs=9, args=0x82de90) at eval.c:3090
#28 0x0101b623 in Fapply (nargs=10, args=0x82de90) at eval.c:2473
#29 0x0101bf40 in Feval (form=62824997) at eval.c:2348
#30 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449e -Q --eval
"(server-mode 1)"
#31 0x0101c587 in funcall_lambda (fun=62825016, nargs=0,
arg_vector=0x82e014) at eval.c:3224
#32 0x01019c20 in Ffuncall (nargs=1, args=0x82e010) at eval.c:3101
#33 0x0101bf40 in Feval (form=62807405) at eval.c:2348
#34 0x0101cd03 in internal_lisp_condition_case (var=47908865,
bodyform=62807405, handlers=62805397) at eval.c:1456
#35 0x011473e5 in Fbyte_code (bytestr=57414835, vector=48954820,
maxdepth=<value optimized out>) at bytecode.c:868
#36 0x0101c486 in funcall_lambda (fun=61341124, nargs=1,
arg_vector=0x82e274) at eval.c:3231
#37 0x01019bcc in Ffuncall (nargs=2, args=0x82e270) at eval.c:3090
#38 0x01146b54 in Fbyte_code (bytestr=57414547, vector=50190340,
maxdepth=<value optimized out>) at bytecode.c:678
#39 0x0101be24 in Feval (form=62803637) at eval.c:2381
#40 0x0101cd03 in internal_lisp_condition_case (var=48397033,
bodyform=62803637, handlers=62796861) at eval.c:1456
#41 0x011473e5 in Fbyte_code (bytestr=57417491, vector=63374084,
maxdepth=<value optimized out>) at bytecode.c:868
#42 0x0101be24 in Feval (form=62805261) at eval.c:2381
#43 0x010193c0 in internal_catch (tag=48248505, func=0x101b7df
<Feval>, arg=62805261) at eval.c:1247
#44 0x0114742b in Fbyte_code (bytestr=57417571, vector=47957428,
maxdepth=<value optimized out>) at bytecode.c:853
#45 0x0101c486 in funcall_lambda (fun=61339556, nargs=2,
arg_vector=0x82e714) at eval.c:3231
#46 0x01019bcc in Ffuncall (nargs=3, args=0x82e710) at eval.c:3090
#47 0x0101b5cf in Fapply (nargs=2, args=0x82e770) at eval.c:2532
#48 0x0101b7c8 in apply1 (fn=48247857, arg=2009275280) at eval.c:2793
#49 0x010644c4 in read_process_output_call (fun_and_args=63019133) at
process.c:5152
#50 0x01019091 in internal_condition_case_1 (bfun=0x106447a
<read_process_output_call>, arg=63019133, handlers=47972617,
    hfun=0x1064526 <read_process_output_error_handler>) at eval.c:1559
#51 0x01064d1f in read_process_output (proc=50769412, channel=<value
optimized out>) at process.c:5341
#52 0x01068c2e in wait_reading_process_output (time_limit=0,
microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=47908865,
    wait_proc=0x0, just_wait_proc=0) at process.c:4994
#53 0x0108ee7b in read_char (commandflag=1, nmaps=2, maps=0x82fb60,
prev_event=47908865, used_mouse_menu=0x82fc24, end_time=0x0)
    at keyboard.c:4038
#54 0x01092e84 in read_key_sequence (keybuf=0x82fcc4, bufsize=30,
prompt=47908865, dont_downcase_last=0,
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9344
#55 0x01095fdd in command_loop_1 () at keyboard.c:1621
#56 0x01019316 in internal_condition_case (bfun=0x1095d4f
<command_loop_1>, handlers=47972617, hfun=0x108cf87 <cmd_error>)
    at eval.c:1511
#57 0x0108c41b in command_loop_2 () at keyboard.c:1338
#58 0x010193c0 in internal_catch (tag=47968689, func=0x108c3f8
<command_loop_2>, arg=47908865) at eval.c:1247
#59 0x0108cdd2 in command_loop () at keyboard.c:1317
#60 0x0108d120 in recursive_edit_1 () at keyboard.c:942
#61 0x0108d28b in Frecursive_edit () at keyboard.c:1004
#62 0x01002fb1 in main (argc=4, argv=0xa927b0) at emacs.c:1777

Lisp Backtrace:
"message" (0x82da34)
"byte-code" (0x82dad0)
"server-execute" (0x82dd04)
0x3a7f864 PVEC_COMPILED
"apply" (0x82de90)
0x3bea23d Lisp type 5
"funcall" (0x82e010)
"server-execute-continuation" (0x82e274)
"byte-code" (0x82e350)
"byte-code" (0x82e500)
"server-process-filter" (0x82e714)

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

[Eli Zaretskii]

> Date: Sat, 1 Nov 2008 15:55:36 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: dhruva <dhruvakm@gmail.com>, emacs-devel@gnu.org
> 
> On Sat, Nov 1, 2008 at 14:53, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Could you two please see if
> > the new version works for you?  Please be sure to try -t and -c
> > switches as well.
> 
> Running
> 
>    emacs -q --eval "(server-mode 1)"
>    emacsclient -t   ;; or emacsclient -c
> 
> I get the attached assertion failure.

Did this work before my changes?

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

[Eli Zaretskii]

> Date: Sat, 1 Nov 2008 15:55:36 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: dhruva <dhruvakm@gmail.com>, emacs-devel@gnu.org
> 
> On Sat, Nov 1, 2008 at 14:53, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Could you two please see if
> > the new version works for you?  Please be sure to try -t and -c
> > switches as well.
> 
> Running
> 
>    emacs -q --eval "(server-mode 1)"
>    emacsclient -t   ;; or emacsclient -c
> 
> I get the attached assertion failure.

Could you please force Emacs to load server.el, rather than
server.elc, before you invoke server-mode?  I'd like to see in what
xbacktrace prints whether server-create-window-system-frame is
involved when you invoke emacsclient with -c, and whether
server-create-tty-frame is involved when you invoke emacsclient with
the -t option.  I think both these functions need to be fixed for
Windows, not surprisingly.

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

[Eli Zaretskii]

> Date: Sat, 1 Nov 2008 15:55:36 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: dhruva <dhruvakm@gmail.com>, emacs-devel@gnu.org
> 
> On Sat, Nov 1, 2008 at 14:53, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Could you two please see if
> > the new version works for you?  Please be sure to try -t and -c
> > switches as well.
> 
> Running
> 
>    emacs -q --eval "(server-mode 1)"
>    emacsclient -t   ;; or emacsclient -c
> 
> I get the attached assertion failure.

One more question: does emacsclient work without -c or -t on Windows?

TIA

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

[dhruva]

On Sat, Nov 1, 2008 at 10:32 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 1 Nov 2008 15:55:36 +0100
>> From: "Juanma Barranquero" <lekktu@gmail.com>
>> Cc: dhruva <dhruvakm@gmail.com>, emacs-devel@gnu.org
>>
>> On Sat, Nov 1, 2008 at 14:53, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> > Could you two please see if
>> > the new version works for you?  Please be sure to try -t and -c
>> > switches as well.
>>
>> Running
>>
>>    emacs -q --eval "(server-mode 1)"
>>    emacsclient -t   ;; or emacsclient -c
>>
>> I get the attached assertion failure.
>
> One more question: does emacsclient work without -c or -t on Windows?

It works without the '-c/-t' option on windows. I am try to manually
bisect to find where it really broke. It appears that the problem
exists even with out your change. But, I can confirm that before I
flagged emacsclient has stopped working, it was working with the '-t'
option (as I share the .bashrc between UNIX and M$ and I use it on
UNIX).

-dhruva


-- 
Contents reflect my personal views only!

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

[Juanma Barranquero]

On Sat, Nov 1, 2008 at 18:01, Eli Zaretskii <eliz@gnu.org> wrote:

> Did this work before my changes?

AFAICS, before your changes emacsclient -t produced "emacsclient.exe:
could not get terminal name", and emacsclient -c produced "*ERROR*:
Invalid terminal device".

> Could you please force Emacs to load server.el, rather than
> server.elc, before you invoke server-mode?

See the attached backtrace (which is identical for emacsclient -c or -t).

> One more question: does emacsclient work without -c or -t on Windows?

Yes.  "emacsclient somefile" works as expected.

             Juanma


font.c:2602: Emacs fatal error: assertion failed: CONSP((val))

Breakpoint 1, w32_abort () at w32fns.c:7279
7279      button = MessageBox (NULL,
(gdb) bt
#0  w32_abort () at w32fns.c:7279
#1  0x0101d5eb in die (msg=0x147ccac "assertion failed: CONSP((val))",
file=0x147c300 "font.c", line=2602) at alloc.c:6216
#2  0x011a4192 in font_get_cache (f=<value optimized out>,
driver=<value optimized out>) at font.c:2602
#3  0x011b1524 in font_list_entities (frame=48517636, spec=48811652)
at font.c:2753
#4  0x011b2140 in font_find_for_lface (f=0x2e45200, attrs=0x82c144,
spec=48682372, c=-1) at font.c:3241
#5  0x011b492c in font_load_for_lface (f=0x2e45200, attrs=0x82c144,
spec=48682372) at font.c:3357
#6  0x011e9f06 in realize_face (cache=0x3260540, attrs=0x82c144,
former_face_id=<value optimized out>) at xfaces.c:5888
#7  0x011edf7a in realize_named_face (f=<value optimized out>,
symbol=47945569, id=2) at xfaces.c:5750
#8  0x011ee351 in realize_basic_faces (f=0x2e45200) at xfaces.c:5562
#9  0x011ef036 in recompute_basic_faces (f=0x2e45200) at xfaces.c:916
#10 0x0103aae9 in init_iterator (it=0x82c2f4, w=0x2e45a00, charpos=-1,
bytepos=-1, row=0x0, base_face_id=DEFAULT_FACE_ID)
    at xdisp.c:2599
#11 0x0103f4c5 in x_consider_frame_title (frame=<value optimized out>)
at xdisp.c:9435
#12 0x0103f918 in prepare_menu_bars () at xdisp.c:9519
#13 0x010481f0 in redisplay_internal (preserve_echo_area=<value
optimized out>) at xdisp.c:11426
#14 0x0104954c in echo_area_display (update_frame_p=1) at xdisp.c:9178
#15 0x01049870 in message3_nolog (m=57487363, nbytes=39, multibyte=0)
at xdisp.c:8039
#16 0x01049b2c in message3 (m=57487363, nbytes=39, multibyte=0) at xdisp.c:7974
#17 0x01170980 in Fmessage (nargs=2, args=0x82d270) at editfns.c:3382
#18 0x0101bf40 in Feval (form=63082285) at eval.c:2348
#19 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#20 0x0101bc5a in Feval (form=63082397) at eval.c:2322
#21 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#22 0x0101d0e1 in FletX (args=63087829) at eval.c:1033
#23 0x0101bc5a in Feval (form=63088197) at eval.c:2322
#24 0x0101cd03 in internal_lisp_condition_case (var=48397033,
bodyform=63088197, handlers=63081837) at eval.c:1456
#25 0x0101cd7f in Fcondition_case (args=63088189) at eval.c:1397
#26 0x0101bc5a in Feval (form=63088141) at eval.c:2322
#27 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#28 0x0101c587 in funcall_lambda (fun=63081816, nargs=7,
arg_vector=0x82d5f0) at eval.c:3224
#29 0x0101c70c in apply_lambda (fun=63081821, args=52006397,
eval_flag=1) at eval.c:3155
#30 0x0101ba3f in Feval (form=52006405) at eval.c:2435
#31 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#32 0x0101cf7d in Flet (args=52006421) at eval.c:1089
#33 0x0101bc5a in Feval (form=52006429) at eval.c:2322
#34 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#35 0x0116868a in Fsave_current_buffer (args=52006445) at editfns.c:1023
#36 0x0101bc5a in Feval (form=52006453) at eval.c:2322
#37 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#38 0x0101c587 in funcall_lambda (fun=52054816, nargs=8,
arg_vector=0x82d974) at eval.c:3224
#39 0x01019c20 in Ffuncall (nargs=9, args=0x82d970) at eval.c:3101
#40 0x0101b623 in Fapply (nargs=10, args=0x82d970) at eval.c:2473
#41 0x0101bf40 in Feval (form=52055229) at eval.c:2348
#42 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#43 0x0101c587 in funcall_lambda (fun=52055248, nargs=0,
arg_vector=0x82daf4) at eval.c:3224
#44 0x01019c20 in Ffuncall (nargs=1, args=0x82daf0) at eval.c:3101
#45 0x0101bf40 in Feval (form=62853405) at eval.c:2348
#46 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#47 0x0101bc5a in Feval (form=52054773) at eval.c:2322
#48 0x0101cd03 in internal_lisp_condition_case (var=47908865,
bodyform=52054773, handlers=19052181) at eval.c:1456
#49 0x0101cd7f in Fcondition_case (args=52054789) at eval.c:1397
#50 0x0101bc5a in Feval (form=52054797) at eval.c:2322
#51 0x0101bc29 in Feval (form=62853413) at eval.c:2433
#52 0x0101bc5a in Feval (form=62853429) at eval.c:2322
#53 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#54 0x0101cf7d in Flet (args=62853533) at eval.c:1089
#55 0x0101bc5a in Feval (form=62853781) at eval.c:2322
#56 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#57 0x0101c587 in funcall_lambda (fun=62853288, nargs=1,
arg_vector=0x82df90) at eval.c:3224
#58 0x0101c70c in apply_lambda (fun=62853293, args=62957125,
eval_flag=1) at eval.c:3155
#59 0x0101ba3f in Feval (form=62957141) at eval.c:2435
#60 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#61 0x0101cf7d in Flet (args=62848437) at eval.c:1089
#62 0x0101bc5a in Feval (form=62850621) at eval.c:2322
#63 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#64 0x0101bc5a in Feval (form=62851373) at eval.c:2322
#65 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#66 0x0101bc5a in Feval (form=62851429) at eval.c:2322
#67 0x0101cd03 in internal_lisp_condition_case (var=48397033,
bodyform=62851429, handlers=62956901) at eval.c:1456
#68 0x0101cd7f in Fcondition_case (args=62851445) at eval.c:1397
#69 0x0101bc5a in Feval (form=62851461) at eval.c:2322
#70 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#71 0x010193c0 in internal_catch (tag=51751297, func=0x101c2b9
<Fprogn>, arg=51793501) at eval.c:1247
#72 0x0101c181 in Fcatch (args=51793469) at eval.c:1215
#73 0x0101bc5a in Feval (form=51793461) at eval.c:2322
#74 0x0101bbdd in Feval (form=51793445) at eval.c:2360
#75 0x0101bc29 in Feval (form=63087925) at eval.c:2433
#76 0x0101c2e2 in Fprogn (args=2009275280) at eval.c:449
#77 0x0101c587 in funcall_lambda (fun=63087968, nargs=2,
arg_vector=0x82e6d4) at eval.c:3224
#78 0x01019c20 in Ffuncall (nargs=3, args=0x82e6d0) at eval.c:3101
#79 0x0101b5cf in Fapply (nargs=2, args=0x82e730) at eval.c:2532
#80 0x0101b7c8 in apply1 (fn=51568977, arg=2009275280) at eval.c:2793
#81 0x010644c4 in read_process_output_call (fun_and_args=51793533) at
process.c:5152
#82 0x01019091 in internal_condition_case_1 (bfun=0x106447a
<read_process_output_call>, arg=51793533, handlers=47972617,
    hfun=0x1064526 <read_process_output_error_handler>) at eval.c:1559
#83 0x01064d1f in read_process_output (proc=51374596, channel=<value
optimized out>) at process.c:5341
#84 0x01068c2e in wait_reading_process_output (time_limit=30,
microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=47908865,
    wait_proc=0x0, just_wait_proc=0) at process.c:4994
#85 0x01159ddf in sit_for (timeout=240, reading=1, do_display=1) at
dispnew.c:6637
#86 0x0108f296 in read_char (commandflag=1, nmaps=3, maps=0x82fb60,
prev_event=47908865, used_mouse_menu=0x82fc24, end_time=0x0)
    at keyboard.c:2892
#87 0x01092e84 in read_key_sequence (keybuf=0x82fcc4, bufsize=30,
prompt=47908865, dont_downcase_last=0,
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9344
#88 0x01095fdd in command_loop_1 () at keyboard.c:1621
#89 0x01019316 in internal_condition_case (bfun=0x1095d4f
<command_loop_1>, handlers=47972617, hfun=0x108cf87 <cmd_error>)
    at eval.c:1511
#90 0x0108c41b in command_loop_2 () at keyboard.c:1338
#91 0x010193c0 in internal_catch (tag=47968689, func=0x108c3f8
<command_loop_2>, arg=47908865) at eval.c:1247
#92 0x0108cdd2 in command_loop () at keyboard.c:1317
#93 0x0108d120 in recursive_edit_1 () at keyboard.c:942
#94 0x0108d28b in Frecursive_edit () at keyboard.c:1004
#95 0x01002fb1 in main (argc=2, argv=0xa92750) at emacs.c:1777

Lisp Backtrace:
"message" (0x82d270)
"cond" (0x82d364)
"let*" (0x82d424)
"condition-case" (0x82d574)
"server-execute" (0x82d5f0)
"let" (0x82d784)
"save-current-buffer" (0x82d834)
0x31a4b25 Lisp type 5
"apply" (0x82d970)
0x31a4cd5 Lisp type 5
"funcall" (0x82daf0)
"progn" (0x82dbe4)
"condition-case" (0x82dd34)
"ignore-errors" (0x82ddb4)
"if" (0x82de34)
"let" (0x82df14)
"server-execute-continuation" (0x82df90)
"let" (0x82e144)
"if" (0x82e1d4)
"progn" (0x82e264)
"condition-case" (0x82e3b4)
"catch" (0x82e4e4)
"cl-block-wrapper" (0x82e564)
"block" (0x82e5e4)
"server-process-filter" (0x82e6d4)

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

[Eli Zaretskii]

> Date: Sun, 2 Nov 2008 08:29:23 +0530
> From: dhruva <dhruvakm@gmail.com>
> Cc: "Juanma Barranquero" <lekktu@gmail.com>, emacs-devel@gnu.org
> 
> It works without the '-c/-t' option on windows. I am try to manually
> bisect to find where it really broke.

Thank you.

> It appears that the problem exists even with out your change.

That's what I'd expect.

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

[Eli Zaretskii]

> Date: Sun, 2 Nov 2008 05:03:33 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: dhruvakm@gmail.com, emacs-devel@gnu.org
> 
> On Sat, Nov 1, 2008 at 18:01, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Did this work before my changes?
> 
> AFAICS, before your changes emacsclient -t produced "emacsclient.exe:
> could not get terminal name", and emacsclient -c produced "*ERROR*:
> Invalid terminal device".

That's what I thought.  Supporting -c will take a bit more work.  I'll
look into it when I have a little time.  I think -t doesn't make sense
with the native Windows port of Emacs, but it needs to fail
gracefully, not by hitting an assertion.

> > Could you please force Emacs to load server.el, rather than
> > server.elc, before you invoke server-mode?
> 
> See the attached backtrace (which is identical for emacsclient -c or -t).

Thanks.