* emacsclient on WXP does not work (as it used to) @ 2008-10-31 10:35 dhruva 2008-10-31 11:02 ` Juanma Barranquero 0 siblings, 1 reply; 33+ messages in thread From: dhruva @ 2008-10-31 10:35 UTC (permalink / raw To: Emacs Devel 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! ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 10:35 emacsclient on WXP does not work (as it used to) dhruva @ 2008-10-31 11:02 ` Juanma Barranquero 2008-10-31 11:15 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Juanma Barranquero @ 2008-10-31 11:02 UTC (permalink / raw To: dhruva; +Cc: Emacs Devel 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"); ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 11:02 ` Juanma Barranquero @ 2008-10-31 11:15 ` Eli Zaretskii 2008-10-31 12:27 ` Juanma Barranquero 0 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2008-10-31 11:15 UTC (permalink / raw To: Juanma Barranquero; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 11:15 ` Eli Zaretskii @ 2008-10-31 12:27 ` Juanma Barranquero 2008-10-31 12:46 ` dhruva 2008-10-31 14:13 ` Chong Yidong 0 siblings, 2 replies; 33+ messages in thread From: Juanma Barranquero @ 2008-10-31 12:27 UTC (permalink / raw To: Eli Zaretskii; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 12:27 ` Juanma Barranquero @ 2008-10-31 12:46 ` dhruva 2008-10-31 12:52 ` dhruva 2008-10-31 12:52 ` Juanma Barranquero 2008-10-31 14:13 ` Chong Yidong 1 sibling, 2 replies; 33+ messages in thread From: dhruva @ 2008-10-31 12:46 UTC (permalink / raw To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel 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! ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 12:46 ` dhruva @ 2008-10-31 12:52 ` dhruva 2008-10-31 12:53 ` Juanma Barranquero 2008-10-31 12:52 ` Juanma Barranquero 1 sibling, 1 reply; 33+ messages in thread From: dhruva @ 2008-10-31 12:52 UTC (permalink / raw To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel 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! ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 12:52 ` dhruva @ 2008-10-31 12:53 ` Juanma Barranquero 2008-10-31 12:57 ` dhruva 0 siblings, 1 reply; 33+ messages in thread From: Juanma Barranquero @ 2008-10-31 12:53 UTC (permalink / raw To: dhruva; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 12:53 ` Juanma Barranquero @ 2008-10-31 12:57 ` dhruva 0 siblings, 0 replies; 33+ messages in thread From: dhruva @ 2008-10-31 12:57 UTC (permalink / raw To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel 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! ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 12:46 ` dhruva 2008-10-31 12:52 ` dhruva @ 2008-10-31 12:52 ` Juanma Barranquero 2008-10-31 12:58 ` dhruva 1 sibling, 1 reply; 33+ messages in thread From: Juanma Barranquero @ 2008-10-31 12:52 UTC (permalink / raw To: dhruva; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 12:52 ` Juanma Barranquero @ 2008-10-31 12:58 ` dhruva 2008-10-31 13:10 ` Juanma Barranquero 0 siblings, 1 reply; 33+ messages in thread From: dhruva @ 2008-10-31 12:58 UTC (permalink / raw To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel 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! ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 12:58 ` dhruva @ 2008-10-31 13:10 ` Juanma Barranquero 2008-10-31 13:38 ` dhruva 0 siblings, 1 reply; 33+ messages in thread From: Juanma Barranquero @ 2008-10-31 13:10 UTC (permalink / raw To: dhruva; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 13:10 ` Juanma Barranquero @ 2008-10-31 13:38 ` dhruva 2008-10-31 13:40 ` dhruva 0 siblings, 1 reply; 33+ messages in thread From: dhruva @ 2008-10-31 13:38 UTC (permalink / raw To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel 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! ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 13:38 ` dhruva @ 2008-10-31 13:40 ` dhruva 2008-10-31 14:22 ` Juanma Barranquero 0 siblings, 1 reply; 33+ messages in thread From: dhruva @ 2008-10-31 13:40 UTC (permalink / raw To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel 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! ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 13:40 ` dhruva @ 2008-10-31 14:22 ` Juanma Barranquero 2008-10-31 14:27 ` Juanma Barranquero 0 siblings, 1 reply; 33+ messages in thread From: Juanma Barranquero @ 2008-10-31 14:22 UTC (permalink / raw To: dhruva; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 14:22 ` Juanma Barranquero @ 2008-10-31 14:27 ` Juanma Barranquero 2008-10-31 14:29 ` dhruva 0 siblings, 1 reply; 33+ messages in thread From: Juanma Barranquero @ 2008-10-31 14:27 UTC (permalink / raw To: dhruva; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 14:27 ` Juanma Barranquero @ 2008-10-31 14:29 ` dhruva 0 siblings, 0 replies; 33+ messages in thread From: dhruva @ 2008-10-31 14:29 UTC (permalink / raw To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel 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! ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 12:27 ` Juanma Barranquero 2008-10-31 12:46 ` dhruva @ 2008-10-31 14:13 ` Chong Yidong 2008-10-31 14:14 ` Juanma Barranquero 2008-10-31 14:31 ` Newsticker is jealous Paul R 1 sibling, 2 replies; 33+ messages in thread From: Chong Yidong @ 2008-10-31 14:13 UTC (permalink / raw To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel "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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 14:13 ` Chong Yidong @ 2008-10-31 14:14 ` Juanma Barranquero 2008-10-31 14:44 ` Eli Zaretskii 2008-10-31 21:58 ` Andreas Schwab 2008-10-31 14:31 ` Newsticker is jealous Paul R 1 sibling, 2 replies; 33+ messages in thread From: Juanma Barranquero @ 2008-10-31 14:14 UTC (permalink / raw To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 14:14 ` Juanma Barranquero @ 2008-10-31 14:44 ` Eli Zaretskii 2008-10-31 15:21 ` dhruva 2008-10-31 21:58 ` Andreas Schwab 1 sibling, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2008-10-31 14:44 UTC (permalink / raw To: Juanma Barranquero; +Cc: cyd, emacs-devel > 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 14:44 ` Eli Zaretskii @ 2008-10-31 15:21 ` dhruva 2008-11-01 13:53 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: dhruva @ 2008-10-31 15:21 UTC (permalink / raw To: Eli Zaretskii; +Cc: Juanma Barranquero, cyd, emacs-devel 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! ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 15:21 ` dhruva @ 2008-11-01 13:53 ` Eli Zaretskii 2008-11-01 14:55 ` Juanma Barranquero 0 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2008-11-01 13:53 UTC (permalink / raw To: lekktu, dhruva; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-11-01 13:53 ` Eli Zaretskii @ 2008-11-01 14:55 ` Juanma Barranquero 2008-11-01 16:41 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 33+ messages in thread From: Juanma Barranquero @ 2008-11-01 14:55 UTC (permalink / raw To: Eli Zaretskii; +Cc: emacs-devel 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) ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-11-01 14:55 ` Juanma Barranquero @ 2008-11-01 16:41 ` Eli Zaretskii 2008-11-01 17:01 ` Eli Zaretskii 2008-11-01 17:02 ` Eli Zaretskii 2 siblings, 0 replies; 33+ messages in thread From: Eli Zaretskii @ 2008-11-01 16:41 UTC (permalink / raw To: Juanma Barranquero; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-11-01 14:55 ` Juanma Barranquero 2008-11-01 16:41 ` Eli Zaretskii @ 2008-11-01 17:01 ` Eli Zaretskii 2008-11-02 4:03 ` Juanma Barranquero 2008-11-01 17:02 ` Eli Zaretskii 2 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2008-11-01 17:01 UTC (permalink / raw To: Juanma Barranquero; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-11-01 17:01 ` Eli Zaretskii @ 2008-11-02 4:03 ` Juanma Barranquero 2008-11-02 4:19 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: Juanma Barranquero @ 2008-11-02 4:03 UTC (permalink / raw To: Eli Zaretskii; +Cc: emacs-devel 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) ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-11-02 4:03 ` Juanma Barranquero @ 2008-11-02 4:19 ` Eli Zaretskii 0 siblings, 0 replies; 33+ messages in thread From: Eli Zaretskii @ 2008-11-02 4:19 UTC (permalink / raw To: Juanma Barranquero; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-11-01 14:55 ` Juanma Barranquero 2008-11-01 16:41 ` Eli Zaretskii 2008-11-01 17:01 ` Eli Zaretskii @ 2008-11-01 17:02 ` Eli Zaretskii 2008-11-02 2:59 ` dhruva 2 siblings, 1 reply; 33+ messages in thread From: Eli Zaretskii @ 2008-11-01 17:02 UTC (permalink / raw To: Juanma Barranquero; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-11-01 17:02 ` Eli Zaretskii @ 2008-11-02 2:59 ` dhruva 2008-11-02 4:17 ` Eli Zaretskii 0 siblings, 1 reply; 33+ messages in thread From: dhruva @ 2008-11-02 2:59 UTC (permalink / raw To: Eli Zaretskii; +Cc: Juanma Barranquero, emacs-devel 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! ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-11-02 2:59 ` dhruva @ 2008-11-02 4:17 ` Eli Zaretskii 0 siblings, 0 replies; 33+ messages in thread From: Eli Zaretskii @ 2008-11-02 4:17 UTC (permalink / raw To: dhruva; +Cc: lekktu, emacs-devel > 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: emacsclient on WXP does not work (as it used to) 2008-10-31 14:14 ` Juanma Barranquero 2008-10-31 14:44 ` Eli Zaretskii @ 2008-10-31 21:58 ` Andreas Schwab 1 sibling, 0 replies; 33+ messages in thread From: Andreas Schwab @ 2008-10-31 21:58 UTC (permalink / raw To: Juanma Barranquero; +Cc: Chong Yidong, Eli Zaretskii, emacs-devel "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." ^ permalink raw reply [flat|nested] 33+ messages in thread
* Newsticker is jealous 2008-10-31 14:13 ` Chong Yidong 2008-10-31 14:14 ` Juanma Barranquero @ 2008-10-31 14:31 ` Paul R 2008-10-31 14:43 ` Paul R 1 sibling, 1 reply; 33+ messages in thread From: Paul R @ 2008-10-31 14:31 UTC (permalink / raw To: emacs-devel; +Cc: ulf.jasper 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Newsticker is jealous 2008-10-31 14:31 ` Newsticker is jealous Paul R @ 2008-10-31 14:43 ` Paul R 2008-10-31 17:21 ` Ulf Jasper 0 siblings, 1 reply; 33+ messages in thread From: Paul R @ 2008-10-31 14:43 UTC (permalink / raw To: emacs-devel; +Cc: ulf.jasper 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Newsticker is jealous 2008-10-31 14:43 ` Paul R @ 2008-10-31 17:21 ` Ulf Jasper 0 siblings, 0 replies; 33+ messages in thread From: Ulf Jasper @ 2008-10-31 17:21 UTC (permalink / raw To: Paul R; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2008-11-02 4:19 UTC | newest] Thread overview: 33+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-10-31 10:35 emacsclient on WXP does not work (as it used to) dhruva 2008-10-31 11:02 ` Juanma Barranquero 2008-10-31 11:15 ` Eli Zaretskii 2008-10-31 12:27 ` Juanma Barranquero 2008-10-31 12:46 ` dhruva 2008-10-31 12:52 ` dhruva 2008-10-31 12:53 ` Juanma Barranquero 2008-10-31 12:57 ` dhruva 2008-10-31 12:52 ` Juanma Barranquero 2008-10-31 12:58 ` dhruva 2008-10-31 13:10 ` Juanma Barranquero 2008-10-31 13:38 ` dhruva 2008-10-31 13:40 ` dhruva 2008-10-31 14:22 ` Juanma Barranquero 2008-10-31 14:27 ` Juanma Barranquero 2008-10-31 14:29 ` dhruva 2008-10-31 14:13 ` Chong Yidong 2008-10-31 14:14 ` Juanma Barranquero 2008-10-31 14:44 ` Eli Zaretskii 2008-10-31 15:21 ` dhruva 2008-11-01 13:53 ` Eli Zaretskii 2008-11-01 14:55 ` Juanma Barranquero 2008-11-01 16:41 ` Eli Zaretskii 2008-11-01 17:01 ` Eli Zaretskii 2008-11-02 4:03 ` Juanma Barranquero 2008-11-02 4:19 ` Eli Zaretskii 2008-11-01 17:02 ` Eli Zaretskii 2008-11-02 2:59 ` dhruva 2008-11-02 4:17 ` Eli Zaretskii 2008-10-31 21:58 ` Andreas Schwab 2008-10-31 14:31 ` Newsticker is jealous Paul R 2008-10-31 14:43 ` Paul R 2008-10-31 17:21 ` Ulf Jasper
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.