* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready @ 2008-09-30 13:43 SRS0+wOMF+22+gmail.com=trentbuck 2008-10-01 16:51 ` Dan Nicolaescu 0 siblings, 1 reply; 37+ messages in thread From: SRS0+wOMF+22+gmail.com=trentbuck @ 2008-09-30 13:43 UTC (permalink / raw To: emacs-pretest-bug; +Cc: trentbuck, rfrancoise From this transcript, you can see that after starting 'emacs --daemon', it takes five seconds before the socket is actually available for emacsclient to talk to it. $ emacs --daemon; while ! ls /tmp/emacs1187/; do sleep 1; done emacs: no process killed ls: cannot access /tmp/emacs1187/: No such file or directory ls: cannot access /tmp/emacs1187/: No such file or directory ls: cannot access /tmp/emacs1187/: No such file or directory ls: cannot access /tmp/emacs1187/: No such file or directory server This is evil; it means that making $ALTERNATE_EDITOR a script that just does emacs --daemon && emacsclient results in a loop, because the socket isn't ready when emacsclient starts -- so emacsclient runs the above script again. For --daemon to be useful to me, it really must not exit until the socket is ready. A filthy workaround might look something like this. #!/bin/bash -e emacs --daemon while ! test -e /tmp/emacs$EUID/server do sleep 1 done emacsclient In GNU Emacs 23.0.60.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) of 2008-09-28 on elegiac, modified by Debian (emacs-snapshot package, version 1:20080928-1) configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.60/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.60/site-lisp:/usr/share/emacs/site-lisp' '--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed' 'CPPFLAGS='' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: C value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_AU.utf8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-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 line-number-mode: t transient-mark-mode: t Recent input: ESC x r e p o r t SPC e m a c s SPC b u TAB RET Recent messages: ("emacs" "-Q") For information about GNU Emacs and the GNU system, type C-h C-a. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-09-30 13:43 bug#1058: 23.0.60; emacs --daemon should not return until socket is ready SRS0+wOMF+22+gmail.com=trentbuck @ 2008-10-01 16:51 ` Dan Nicolaescu 2008-10-01 19:39 ` Romain Francoise 2008-10-02 0:43 ` Trent W. Buck 0 siblings, 2 replies; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-01 16:51 UTC (permalink / raw To: SRS0+wOMF+22+gmail.com=trentbuck; +Cc: trentbuck, 1058, rfrancoise SRS0+wOMF+22+gmail.com=trentbuck@internode.on.net writes: > From this transcript, you can see that after starting 'emacs > --daemon', it takes five seconds before the socket is actually > available for emacsclient to talk to it. > > $ emacs --daemon; while ! ls /tmp/emacs1187/; do sleep 1; done Just curious, what do you get if you do: emacs -Q --daemon; while ! ls /tmp/emacs1187/; do sleep 1; done > emacs: no process killed > ls: cannot access /tmp/emacs1187/: No such file or directory > ls: cannot access /tmp/emacs1187/: No such file or directory > ls: cannot access /tmp/emacs1187/: No such file or directory > ls: cannot access /tmp/emacs1187/: No such file or directory > server > > This is evil; it means that making $ALTERNATE_EDITOR a script that > just does > > emacs --daemon && emacsclient > > results in a loop, because the socket isn't ready when emacsclient > starts -- so emacsclient runs the above script again. For --daemon to > be useful to me, it really must not exit until the socket is ready. Unfortunately ATM I don't see an easy way to do that. Ideas/patches are certainly welcome. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-01 16:51 ` Dan Nicolaescu @ 2008-10-01 19:39 ` Romain Francoise 2008-10-01 20:19 ` Andreas Schwab ` (2 more replies) 2008-10-02 0:43 ` Trent W. Buck 1 sibling, 3 replies; 37+ messages in thread From: Romain Francoise @ 2008-10-01 19:39 UTC (permalink / raw To: Dan Nicolaescu; +Cc: trentbuck, 1058 Hi Dan, Trent, Dan Nicolaescu <dann@ics.uci.edu> writes: > Just curious, what do you get if you do: > emacs -Q --daemon; while ! ls /tmp/emacs1187/; do sleep 1; done Yes, the delay is caused by my change to load the init file before starting the server. > Unfortunately ATM I don't see an easy way to do that. > Ideas/patches are certainly welcome. It's easy to do, but not very clean. WDYT? diff --git a/lisp/startup.el b/lisp/startup.el index 5bd73f9..d9e37be 100644 --- a/lisp/startup.el +++ b/lisp/startup.el @@ -1224,7 +1224,8 @@ opening the first frame (e.g. open a connection to an X server).") ;; processing all command line arguments to allow e.g. `server-name' ;; to be changed before the server starts. (when (daemonp) - (server-start)) + (server-start) + (daemon-detach-parent)) ;; Run emacs-session-restore (session management) if started by ;; the session manager and we have a session manager connection. diff --git a/src/emacs.c b/src/emacs.c index f94d2d3..a2842d4 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -235,6 +235,10 @@ int noninteractive1; /* Nonzero means Emacs was started as a daemon. */ int is_daemon = 0; +/* Pipe used to send exit notification to the daemon parent at + startup. */ +int daemon_pipe[2]; + /* Save argv and argc. */ char **initial_argv; int initial_argc; @@ -1074,16 +1078,31 @@ main (int argc, char **argv) if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args)) { #ifndef DOS_NT + if (pipe (daemon_pipe) == -1) + { + fprintf (stderr, "Cannot pipe!\n"); + exit (1); + } pid_t f = fork (); int nfd; if (f > 0) - exit (0); + { + char buf[2]; + close (daemon_pipe[1]); + /* Wait for the child to close its end of the pipe before + exiting. */ + while (read (daemon_pipe[0], &buf, 1) < 0) + sleep (0.1); + close (daemon_pipe[0]); + exit (0); + } if (f < 0) { fprintf (stderr, "Cannot fork!\n"); exit (1); } + close (daemon_pipe[0]); nfd = open ("/dev/null", O_RDWR); dup2 (nfd, 0); dup2 (nfd, 1); @@ -2389,6 +2408,16 @@ DEFUN ("daemonp", Fdaemonp, Sdaemonp, 0, 0, 0, return is_daemon ? Qt : Qnil; } +DEFUN ("daemon-detach-parent", Fdaemon_detach_parent, Sdaemon_detach_parent, + 0, 0, 0, + doc: /* Detach Emacs from its invocation parent if it was started as a daemon. */) + () +{ + if (is_daemon) + close (daemon_pipe[1]); + return Qt; +} + void syms_of_emacs () { @@ -2408,6 +2437,7 @@ syms_of_emacs () defsubr (&Sinvocation_name); defsubr (&Sinvocation_directory); defsubr (&Sdaemonp); + defsubr (&Sdaemon_detach_parent); DEFVAR_LISP ("command-line-args", &Vcommand_line_args, doc: /* Args passed by shell to Emacs, as a list of strings. ^ permalink raw reply related [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-01 19:39 ` Romain Francoise @ 2008-10-01 20:19 ` Andreas Schwab 2008-10-02 6:05 ` Romain Francoise 2008-10-01 23:32 ` Dan Nicolaescu 2008-10-02 0:50 ` Trent W. Buck 2 siblings, 1 reply; 37+ messages in thread From: Andreas Schwab @ 2008-10-01 20:19 UTC (permalink / raw To: Romain Francoise; +Cc: trentbuck, 1058, Dan Nicolaescu Romain Francoise <romain@orebokech.com> writes: > + while (read (daemon_pipe[0], &buf, 1) < 0) > + sleep (0.1); sleep takes an integer, not a float. 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] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-01 20:19 ` Andreas Schwab @ 2008-10-02 6:05 ` Romain Francoise 0 siblings, 0 replies; 37+ messages in thread From: Romain Francoise @ 2008-10-02 6:05 UTC (permalink / raw To: Andreas Schwab; +Cc: trentbuck, 1058, Dan Nicolaescu Andreas Schwab <schwab@suse.de> writes: > sleep takes an integer, not a float. Hrm, yeah. And the detach function should be guarded otherwise it would close random fds on each call, which is probably not what we want. And the while-sleep loop should be done differently. But anyway, this was just a quick proof of concept, it happened to compile and work on the first try, so... ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-01 19:39 ` Romain Francoise 2008-10-01 20:19 ` Andreas Schwab @ 2008-10-01 23:32 ` Dan Nicolaescu 2008-10-02 6:07 ` Romain Francoise 2008-10-02 0:50 ` Trent W. Buck 2 siblings, 1 reply; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-01 23:32 UTC (permalink / raw To: Romain Francoise; +Cc: trentbuck, 1058 Romain Francoise <romain@orebokech.com> writes: > Hi Dan, Trent, > > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > Just curious, what do you get if you do: > > emacs -Q --daemon; while ! ls /tmp/emacs1187/; do sleep 1; done > > Yes, the delay is caused by my change to load the init file before > starting the server. > > > Unfortunately ATM I don't see an easy way to do that. > > Ideas/patches are certainly welcome. > > It's easy to do, but not very clean. WDYT? It would be much better if this could be done without a state changing function callable from elisp. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-01 23:32 ` Dan Nicolaescu @ 2008-10-02 6:07 ` Romain Francoise 2008-10-02 8:14 ` Dan Nicolaescu 0 siblings, 1 reply; 37+ messages in thread From: Romain Francoise @ 2008-10-02 6:07 UTC (permalink / raw To: Dan Nicolaescu; +Cc: trentbuck, 1058 Dan Nicolaescu <dann@ics.uci.edu> writes: > It would be much better if this could be done without a state > changing function callable from elisp. I agree, but given that control passes to Lisp pretty early, I don't see how it can be done. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-02 6:07 ` Romain Francoise @ 2008-10-02 8:14 ` Dan Nicolaescu 2008-10-02 12:38 ` Stefan Monnier 2008-10-02 17:54 ` Romain Francoise 0 siblings, 2 replies; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-02 8:14 UTC (permalink / raw To: Romain Francoise; +Cc: trentbuck, 1058 Romain Francoise <romain@orebokech.com> writes: > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > It would be much better if this could be done without a state > > changing function callable from elisp. > > I agree, but given that control passes to Lisp pretty early, I don't > see how it can be done. That's exactly the reason for my initial reply... Anyway, your patch probably needs an approval from a maintainer. And a better name and docstring for daemon-detach-parent would be needed. Also daemon-detach-parent should throw an error if called in the non-daemon case, and when called more than once. More comments explaining what's going on would also be nic. Maybe use select instead of read+sleep? Or signals? Should also do something in case the child dies before it calls daemon-detach-parent. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-02 8:14 ` Dan Nicolaescu @ 2008-10-02 12:38 ` Stefan Monnier 2008-10-02 17:26 ` Dan Nicolaescu 2008-10-02 17:54 ` Romain Francoise 1 sibling, 1 reply; 37+ messages in thread From: Stefan Monnier @ 2008-10-02 12:38 UTC (permalink / raw To: Dan Nicolaescu; +Cc: trentbuck, 1058, Romain Francoise >> > It would be much better if this could be done without a state >> > changing function callable from elisp. >> I agree, but given that control passes to Lisp pretty early, I don't >> see how it can be done. > That's exactly the reason for my initial reply... > Anyway, your patch probably needs an approval from a maintainer. I could accept a similar patch, maybe, but first I need to understand why/where we currently "detach" so early. Stefan ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-02 12:38 ` Stefan Monnier @ 2008-10-02 17:26 ` Dan Nicolaescu 2008-10-02 21:32 ` Stefan Monnier 0 siblings, 1 reply; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-02 17:26 UTC (permalink / raw To: Stefan Monnier; +Cc: trentbuck, 1058, Romain Francoise Stefan Monnier <monnier@iro.umontreal.ca> writes: > >> > It would be much better if this could be done without a state > >> > changing function callable from elisp. > >> I agree, but given that control passes to Lisp pretty early, I don't > >> see how it can be done. > > That's exactly the reason for my initial reply... > > Anyway, your patch probably needs an approval from a maintainer. > > I could accept a similar patch, maybe, but first I need to understand > why/where we currently "detach" so early. Where? in emacs.c:main, look for: if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args)) { #ifndef DOS_NT pid_t f = fork (); Why? - mainly because I never thought about the emacs --daemon && emacsclient use-case. - in order to not make detaching an elisp function, and have to deal with users trying to call it from different contexts - the `fork' call for detaching needs to happen before some of the initialization is run (although after my 2008-09-28 change it might be possible to push it later), and also before .emacs is run and before the server is started. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-02 17:26 ` Dan Nicolaescu @ 2008-10-02 21:32 ` Stefan Monnier 2008-10-02 22:34 ` Dan Nicolaescu 2008-10-02 22:42 ` Trent W. Buck 0 siblings, 2 replies; 37+ messages in thread From: Stefan Monnier @ 2008-10-02 21:32 UTC (permalink / raw To: Dan Nicolaescu; +Cc: trentbuck, 1058, Romain Francoise >> I could accept a similar patch, maybe, but first I need to understand >> why/where we currently "detach" so early. > Where? in emacs.c:main, look for: > if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args)) > { > #ifndef DOS_NT > pid_t f = fork (); Oh, thanks. I somehow overlooked it. > - in order to not make detaching an elisp function, and have to deal > with users trying to call it from different contexts > - the `fork' call for detaching needs to happen before some of the > initialization is run (although after my 2008-09-28 change it might be > possible to push it later), and also before .emacs is run and before > the server is started. I see what you mean. But I think forking so early is wrong: all the --eval and .emacs processing should take place "in the foreground" with input/output from stdin/stdout (like --batch). That means that detaching needs indeed to be done late if we want to do it right. Of course, that means it's more difficult to implement since it can be called in many more different contexts (we can/should reject most of them, but we still need to test/detect the undesirable ones). I see 3 different solutions: 1 - Someone fixes the code so as to do it right. 2 - we don't touch anything for now postpone the fix to 23.2. 3 - we drop the `fork' for now (so it doesn't behave like an actual daemon, more like a --batch); waiting for a `daemonize' Elisp function to be added in 23.2. I'm not sure if 1 can be done in a way appropriate for 23.1. What happens to messages resulting from executing .emacs in solution nb 2 are they sent to stdout or are they silently dropped? Stefan PS: Currently "emacs --daemon" doesn't do anything for me: it immediately (as in "I've never seen Emacs start or stop so fast") returns with no output and no remaining process. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-02 21:32 ` Stefan Monnier @ 2008-10-02 22:34 ` Dan Nicolaescu 2008-10-02 22:46 ` Trent W. Buck 2008-10-03 1:12 ` Stefan Monnier 2008-10-02 22:42 ` Trent W. Buck 1 sibling, 2 replies; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-02 22:34 UTC (permalink / raw To: Stefan Monnier; +Cc: trentbuck, 1058, Romain Francoise Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > > - in order to not make detaching an elisp function, and have to deal > > with users trying to call it from different contexts > > - the `fork' call for detaching needs to happen before some of the > > initialization is run (although after my 2008-09-28 change it might be > > possible to push it later), and also before .emacs is run and before > > the server is started. > > I see what you mean. But I think forking so early is wrong: all > the --eval and .emacs processing should take place "in the foreground" > with input/output from stdin/stdout (like --batch). Is that desirable? We seem to be looking at this from different points of view. I want the daemon to start the server early, and that should be the only way to interact with it. You want to have a full blown emacs until the server is started... IMHO if someone's .emacs wants to chat during startup, then he needs to fix his .emacs if he wants to use --daemon. Chatty deamons are evil (or devils?). :-) > That means that detaching needs indeed to be done late if we want to do > it right. Of course, that means it's more difficult to implement since > it can be called in many more different contexts (we can/should reject > most of them, but we still need to test/detect the undesirable ones). Looking at it again, it should not be too bad, tedious, but not complicated. > I see 3 different solutions: > 1 - Someone fixes the code so as to do it right. > 2 - we don't touch anything for now postpone the fix to 23.2. > 3 - we drop the `fork' for now (so it doesn't behave like an actual > daemon, more like a --batch); waiting for a `daemonize' Elisp > function to be added in 23.2. > > I'm not sure if 1 can be done in a way appropriate for 23.1. Depending on what the definition if "right" is... If it means enabling interaction before detaching, then you might be right (haven't checked). If it means the patch that Romain posted, that should be fine to go in now. > What happens to messages resulting from executing .emacs in solution nb > 2 are they sent to stdout or are they silently dropped? deamon's stdin/stdout/stderr go to /dev/null. > PS: Currently "emacs --daemon" doesn't do anything for me: it > immediately (as in "I've never seen Emacs start or stop so fast") > returns with no output and no remaining process. How about "emacs -Q --daemon" ? Is this CVS HEAD, or your famous patched tree? ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-02 22:34 ` Dan Nicolaescu @ 2008-10-02 22:46 ` Trent W. Buck 2008-10-03 1:12 ` Stefan Monnier 1 sibling, 0 replies; 37+ messages in thread From: Trent W. Buck @ 2008-10-02 22:46 UTC (permalink / raw To: Dan Nicolaescu; +Cc: 1058, Romain Francoise, Stefan Monnier On Thu, Oct 02, 2008 at 03:34:42PM -0700, Dan Nicolaescu wrote: > Depending on what the definition if "right" is... If it means enabling > interaction before detaching, then you might be right (haven't checked). > If it means the patch that Romain posted, that should be fine to go in > now. Currently if you "emacs --daemon" and .emacs contains a syntax error, you don't get any warning of this. Currently if you do something like "emacs --daemon -f irc -f gnus", any minibuffer prompts will appear when you connect a client. I think I'd prefer the first to change and the latter to stay the same, but I haven't had any coffee yet. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-02 22:34 ` Dan Nicolaescu 2008-10-02 22:46 ` Trent W. Buck @ 2008-10-03 1:12 ` Stefan Monnier 2008-10-03 4:52 ` Dan Nicolaescu 2008-10-13 2:03 ` Dan Nicolaescu 1 sibling, 2 replies; 37+ messages in thread From: Stefan Monnier @ 2008-10-03 1:12 UTC (permalink / raw To: Dan Nicolaescu; +Cc: trentbuck, 1058, Romain Francoise > Is that desirable? We seem to be looking at this from different points > of view. I want the daemon to start the server early, and that should > be the only way to interact with it. You want to have a full blown > emacs until the server is started... I think we agree: I also want a full blown Emacs until the server is started. But I also want to run some Elisp code (especially the .emacs) before the server is started. > IMHO if someone's .emacs wants to chat during startup, then he needs to > fix his .emacs if he wants to use --daemon. Agreed. > Chatty deamons are evil (or devils?). :-) But daemons which fork before detecting if there's an error somewhere and hence don't report such errors are even more evil. >> That means that detaching needs indeed to be done late if we want to do >> it right. Of course, that means it's more difficult to implement since >> it can be called in many more different contexts (we can/should reject >> most of them, but we still need to test/detect the undesirable ones). > Looking at it again, it should not be too bad, tedious, but not complicated. Could be. > Depending on what the definition if "right" is... If it means enabling > interaction before detaching, then you might be right (haven't checked). > If it means the patch that Romain posted, that should be fine to go in > now. I can't tell yet whether Romain's patch does the right thing: do errors in .emacs get properly reported to stdout? >> What happens to messages resulting from executing .emacs in solution nb >> 2 are they sent to stdout or are they silently dropped? > deamon's stdin/stdout/stderr go to /dev/null. That's mostly OK, but not before the .emacs (and --eval) get processed. >> PS: Currently "emacs --daemon" doesn't do anything for me: it >> immediately (as in "I've never seen Emacs start or stop so fast") >> returns with no output and no remaining process. > How about "emacs -Q --daemon" ? Same thing. > Is this CVS HEAD, or your famous patched tree? ;-) CVS HEAD. Stefan ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-03 1:12 ` Stefan Monnier @ 2008-10-03 4:52 ` Dan Nicolaescu 2008-10-03 13:00 ` Stefan Monnier 2008-10-13 2:03 ` Dan Nicolaescu 1 sibling, 1 reply; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-03 4:52 UTC (permalink / raw To: Stefan Monnier; +Cc: trentbuck, 1058, Romain Francoise Stefan Monnier <monnier@iro.umontreal.ca> writes: > > Depending on what the definition if "right" is... If it means enabling > > interaction before detaching, then you might be right (haven't checked). > > If it means the patch that Romain posted, that should be fine to go in > > now. > > I can't tell yet whether Romain's patch does the right thing: do errors > in .emacs get properly reported to stdout? Romain's patch solves the other problem: the fact that the initial parent process returns before the server is started, so that emacs --daemon && emacsclient -c does not work. I am not sure if moving the code that forks/disconnects from the terminal later solves the reporting errors problem. (and I can't really try at the moment). > >> What happens to messages resulting from executing .emacs in solution nb > >> 2 are they sent to stdout or are they silently dropped? > > deamon's stdin/stdout/stderr go to /dev/null. > > That's mostly OK, but not before the .emacs (and --eval) get processed. > > >> PS: Currently "emacs --daemon" doesn't do anything for me: it > >> immediately (as in "I've never seen Emacs start or stop so fast") > >> returns with no output and no remaining process. > > > How about "emacs -Q --daemon" ? > > Same thing. Hmm, you mean that after "emacs -Q --daemon" if you look with ps there's no emacs process at all? And "emacsclient -t" does not connect to it? ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-03 4:52 ` Dan Nicolaescu @ 2008-10-03 13:00 ` Stefan Monnier 2008-10-03 17:44 ` Dan Nicolaescu 0 siblings, 1 reply; 37+ messages in thread From: Stefan Monnier @ 2008-10-03 13:00 UTC (permalink / raw To: Dan Nicolaescu; +Cc: trentbuck, 1058, Romain Francoise > Hmm, you mean that after "emacs -Q --daemon" if you look with ps there's > no emacs process at all? And "emacsclient -t" does not connect to it? Exactly. But I haven't investigated further yet. Most likely it's a simple error somewhere that causes Emacs to exit but the message is throw away. That's exactly for these kinds of reasons that it's important to keep sending messages to stdout at least until after the server is started: otherwise debugging is a pain. Stefan ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-03 13:00 ` Stefan Monnier @ 2008-10-03 17:44 ` Dan Nicolaescu 0 siblings, 0 replies; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-03 17:44 UTC (permalink / raw To: Stefan Monnier; +Cc: trentbuck, 1058, Romain Francoise Stefan Monnier <monnier@iro.umontreal.ca> writes: > > Hmm, you mean that after "emacs -Q --daemon" if you look with ps there's > > no emacs process at all? And "emacsclient -t" does not connect to it? > > Exactly. But I haven't investigated further yet. Most likely it's > a simple error somewhere that causes Emacs to exit but the message is > throw away. If this is with an up to date pristine tree, then please debug it, it's very bad. I have not seen anything like this on any of the systems that I use. > That's exactly for these kinds of reasons that it's important to > keep sending messages to stdout at least until after the server is > started: otherwise debugging is a pain. Well, but that is not how things work when using emacs normally (i.e. interactive session without --daemon). - Errors in .emacs are shown in the *Messages* buffer. That still happens with --daemon. - Interactive questions (like a y-or-n-p in .emacs) get asked in the first emacs frame that appears. I think we agree that something like this is ill formed for --daemon. It would be nice if it failed more graciously, but I am not sure it can be easily done within the current constraints. BTW, the splash screen covers that *Messages* buffer quite fast, so errors at startup are not displayed for too long ... ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-03 1:12 ` Stefan Monnier 2008-10-03 4:52 ` Dan Nicolaescu @ 2008-10-13 2:03 ` Dan Nicolaescu 2008-10-13 15:16 ` Stefan Monnier 1 sibling, 1 reply; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-13 2:03 UTC (permalink / raw To: Stefan Monnier; +Cc: trentbuck, 1058, Romain Francoise Here's a patch that adds support for --daemon=SERVER_NAME Using --daemon=SERVER_NAME for scripts is much nicer than: --daemon --eval '(setq server-name "SERVER_NAME")' So IMVHO something like this could go in now... Index: lisp/server.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/server.el,v retrieving revision 1.168 diff -u -3 -p -r1.168 server.el --- lisp/server.el 24 Sep 2008 20:12:02 -0000 1.168 +++ lisp/server.el 13 Oct 2008 00:15:28 -0000 @@ -446,7 +446,7 @@ Creates the directory if necessary and m (error "The directory %s is unsafe" dir)))) ;;;###autoload -(defun server-start (&optional leave-dead) +(defun server-start (&optional leave-dead server-arg) "Allow this Emacs process to be a server for client processes. This starts a server communications subprocess through which client \"editors\" can send your editing commands to this Emacs @@ -463,6 +463,8 @@ kill any existing server communications (when server-process ;; kill it dead! (ignore-errors (delete-process server-process))) + (when (stringp server-arg) + (setq server-name server-arg)) ;; Delete the socket files made by previous server invocations. (condition-case () (delete-file (expand-file-name server-name server-socket-dir)) Index: lisp/startup.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/startup.el,v retrieving revision 1.513 diff -u -3 -p -r1.513 startup.el --- lisp/startup.el 12 Oct 2008 16:59:01 -0000 1.513 +++ lisp/startup.el 13 Oct 2008 00:15:28 -0000 @@ -1212,8 +1212,8 @@ the `--debug-init' option to view a comp ;; This is done after loading the user's init file and after ;; processing all command line arguments to allow e.g. `server-name' ;; to be changed before the server starts. - (when (daemonp) - (server-start)) + (let ((dn (daemonp))) + (when dn (server-start nil dn))) ;; Run emacs-session-restore (session management) if started by ;; the session manager and we have a session manager connection. Index: src/emacs.c =================================================================== RCS file: /cvsroot/emacs/emacs/src/emacs.c,v retrieving revision 1.448 diff -u -3 -p -r1.448 emacs.c --- src/emacs.c 6 Oct 2008 16:16:56 -0000 1.448 +++ src/emacs.c 13 Oct 2008 00:15:28 -0000 @@ -237,6 +237,8 @@ int noninteractive1; /* Nonzero means Emacs was started as a daemon. */ int is_daemon = 0; +/* Name for the server started by the daemon.*/ +static char *daemon_name; /* Save argv and argc. */ char **initial_argv; @@ -792,6 +794,7 @@ main (int argc, char **argv) #endif int no_loadup = 0; char *junk = 0; + char *dname_arg = 0; #if GC_MARK_STACK extern Lisp_Object *stack_base; @@ -1074,8 +1077,8 @@ main (int argc, char **argv) printf (USAGE4, bug_reporting_address ()); exit (0); } - - if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args)) + if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args) + || argmatch (argv, argc, "-daemon", "--daemon", 5, &dname_arg, &skip_args)) { #ifndef DOS_NT pid_t f = fork (); @@ -1088,6 +1091,8 @@ main (int argc, char **argv) exit (1); } + if (dname_arg) + daemon_name = xstrdup (dname_arg); nfd = open ("/dev/null", O_RDWR); dup2 (nfd, 0); dup2 (nfd, 1); @@ -2387,10 +2392,17 @@ decode_env_path (evarname, defalt) } DEFUN ("daemonp", Fdaemonp, Sdaemonp, 0, 0, 0, - doc: /* Return t if the current emacs process is a daemon. */) + doc: /* Return non-nil if the current emacs process is a daemon. +If the daemon was give a name argument, return that name. */) () { - return is_daemon ? Qt : Qnil; + if (is_daemon) + if (daemon_name) + return build_string (daemon_name); + else + return Qt; + else + return Qnil; } void ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-13 2:03 ` Dan Nicolaescu @ 2008-10-13 15:16 ` Stefan Monnier 2008-10-13 17:01 ` Dan Nicolaescu 0 siblings, 1 reply; 37+ messages in thread From: Stefan Monnier @ 2008-10-13 15:16 UTC (permalink / raw To: Dan Nicolaescu; +Cc: trentbuck, 1058, Romain Francoise > -(defun server-start (&optional leave-dead) > +(defun server-start (&optional leave-dead server-arg) > "Allow this Emacs process to be a server for client processes. > This starts a server communications subprocess through which > client \"editors\" can send your editing commands to this Emacs > @@ -463,6 +463,8 @@ kill any existing server communications > (when server-process > ;; kill it dead! > (ignore-errors (delete-process server-process))) > + (when (stringp server-arg) > + (setq server-name server-arg)) Changing the global var like this is an ugly hack. I'd rather not add any feature in this direction for now anyway. Stefan ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-13 15:16 ` Stefan Monnier @ 2008-10-13 17:01 ` Dan Nicolaescu 2008-10-13 19:07 ` Stefan Monnier 0 siblings, 1 reply; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-13 17:01 UTC (permalink / raw To: Stefan Monnier; +Cc: trentbuck, 1058, Romain Francoise Stefan Monnier <monnier@iro.umontreal.ca> writes: > > -(defun server-start (&optional leave-dead) > > +(defun server-start (&optional leave-dead server-arg) > > "Allow this Emacs process to be a server for client processes. > > This starts a server communications subprocess through which > > client \"editors\" can send your editing commands to this Emacs > > @@ -463,6 +463,8 @@ kill any existing server communications > > (when server-process > > ;; kill it dead! > > (ignore-errors (delete-process server-process))) > > + (when (stringp server-arg) > > + (setq server-name server-arg)) > > Changing the global var like this is an ugly hack. Sure, it can be moved before the call to `sever-start' I also wanted to make that variable obsolete and make the functional interface the preferred method. But that is a separate issue, and it's quite orthogonal to the point of this patch. > I'd rather not add any feature in this direction for now anyway. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-13 17:01 ` Dan Nicolaescu @ 2008-10-13 19:07 ` Stefan Monnier 2008-10-14 7:26 ` Dan Nicolaescu 0 siblings, 1 reply; 37+ messages in thread From: Stefan Monnier @ 2008-10-13 19:07 UTC (permalink / raw To: Dan Nicolaescu; +Cc: trentbuck, 1058, Romain Francoise >> > -(defun server-start (&optional leave-dead) >> > +(defun server-start (&optional leave-dead server-arg) >> > "Allow this Emacs process to be a server for client processes. >> > This starts a server communications subprocess through which >> > client \"editors\" can send your editing commands to this Emacs >> > @@ -463,6 +463,8 @@ kill any existing server communications >> > (when server-process >> > ;; kill it dead! >> > (ignore-errors (delete-process server-process))) >> > + (when (stringp server-arg) >> > + (setq server-name server-arg)) >> >> Changing the global var like this is an ugly hack. > Sure, it can be moved before the call to `sever-start' > I also wanted to make that variable obsolete and make the functional > interface the preferred method. There's no need or reason to make it obsolete. You basically want to replace the last two lines above with (unless (stringp server-arg) (setq server-arg server-name)) and then pass server-arg where it's needed. > But that is a separate issue, and it's quite orthogonal to the point of > this patch. Since I'm basically not excited at the idea of adding yet more features at this point, it's good to try and make sure that any such proposal comes with the cleanest code possible, rather than with a quick fix. Stefan ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-13 19:07 ` Stefan Monnier @ 2008-10-14 7:26 ` Dan Nicolaescu 2008-10-27 7:04 ` Dan Nicolaescu 0 siblings, 1 reply; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-14 7:26 UTC (permalink / raw To: Stefan Monnier; +Cc: trentbuck, 1058, Romain Francoise Stefan Monnier <monnier@iro.umontreal.ca> writes: > >> > -(defun server-start (&optional leave-dead) > >> > +(defun server-start (&optional leave-dead server-arg) > >> > "Allow this Emacs process to be a server for client processes. > >> > This starts a server communications subprocess through which > >> > client \"editors\" can send your editing commands to this Emacs > >> > @@ -463,6 +463,8 @@ kill any existing server communications > >> > (when server-process > >> > ;; kill it dead! > >> > (ignore-errors (delete-process server-process))) > >> > + (when (stringp server-arg) > >> > + (setq server-name server-arg)) > >> > >> Changing the global var like this is an ugly hack. > > > Sure, it can be moved before the call to `sever-start' > > I also wanted to make that variable obsolete and make the functional > > interface the preferred method. > > There's no need or reason to make it obsolete. You basically want to > replace the last two lines above with > > (unless (stringp server-arg) > (setq server-arg server-name)) > > and then pass server-arg where it's needed. Ah, OK. I had the impression that server-name was needed for other functions to work correctly, but that is not the case. Updated patch follows. Now it's your choice if you want this patch now or later. I'll update the docs when checking it in. Index: lisp/server.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/server.el,v retrieving revision 1.168 diff -u -3 -p -r1.168 server.el --- lisp/server.el 24 Sep 2008 20:12:02 -0000 1.168 +++ lisp/server.el 14 Oct 2008 07:16:41 -0000 @@ -446,7 +446,7 @@ Creates the directory if necessary and m (error "The directory %s is unsafe" dir)))) ;;;###autoload -(defun server-start (&optional leave-dead) +(defun server-start (&optional leave-dead server-arg) "Allow this Emacs process to be a server for client processes. This starts a server communications subprocess through which client \"editors\" can send your editing commands to this Emacs @@ -463,9 +463,11 @@ kill any existing server communications (when server-process ;; kill it dead! (ignore-errors (delete-process server-process))) + (unless (stringp server-arg) + (setq server-arg server-name)) ;; Delete the socket files made by previous server invocations. (condition-case () - (delete-file (expand-file-name server-name server-socket-dir)) + (delete-file (expand-file-name server-arg server-socket-dir)) (error nil)) ;; If this Emacs already had a server, clear out associated status. (while server-clients @@ -476,7 +478,7 @@ kill any existing server communications (server-log (message "Server stopped")) (setq server-process nil)) (let* ((server-dir (if server-use-tcp server-auth-dir server-socket-dir)) - (server-file (expand-file-name server-name server-dir))) + (server-file (expand-file-name server-arg server-dir))) ;; Make sure there is a safe directory in which to place the socket. (server-ensure-safe-dir server-dir) ;; Remove any leftover socket or authentication file. @@ -491,7 +493,7 @@ kill any existing server communications (add-hook 'kill-emacs-hook (lambda () (server-mode -1))) ;Cleanup upon exit. (setq server-process (apply #'make-network-process - :name server-name + :name server-arg :server t :noquery t :sentinel 'server-sentinel Index: lisp/startup.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/startup.el,v retrieving revision 1.513 diff -u -3 -p -r1.513 startup.el --- lisp/startup.el 12 Oct 2008 16:59:01 -0000 1.513 +++ lisp/startup.el 14 Oct 2008 07:16:41 -0000 @@ -1212,8 +1212,8 @@ the `--debug-init' option to view a comp ;; This is done after loading the user's init file and after ;; processing all command line arguments to allow e.g. `server-name' ;; to be changed before the server starts. - (when (daemonp) - (server-start)) + (let ((dn (daemonp))) + (when dn (server-start nil dn))) ;; Run emacs-session-restore (session management) if started by ;; the session manager and we have a session manager connection. Index: src/emacs.c =================================================================== RCS file: /cvsroot/emacs/emacs/src/emacs.c,v retrieving revision 1.448 diff -u -3 -p -r1.448 emacs.c --- src/emacs.c 6 Oct 2008 16:16:56 -0000 1.448 +++ src/emacs.c 14 Oct 2008 07:16:41 -0000 @@ -237,6 +237,8 @@ int noninteractive1; /* Nonzero means Emacs was started as a daemon. */ int is_daemon = 0; +/* Name for the server started by the daemon.*/ +static char *daemon_name; /* Save argv and argc. */ char **initial_argv; @@ -792,6 +794,7 @@ main (int argc, char **argv) #endif int no_loadup = 0; char *junk = 0; + char *dname_arg = 0; #if GC_MARK_STACK extern Lisp_Object *stack_base; @@ -1074,8 +1077,8 @@ main (int argc, char **argv) printf (USAGE4, bug_reporting_address ()); exit (0); } - - if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args)) + if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args) + || argmatch (argv, argc, "-daemon", "--daemon", 5, &dname_arg, &skip_args)) { #ifndef DOS_NT pid_t f = fork (); @@ -1088,6 +1091,8 @@ main (int argc, char **argv) exit (1); } + if (dname_arg) + daemon_name = xstrdup (dname_arg); nfd = open ("/dev/null", O_RDWR); dup2 (nfd, 0); dup2 (nfd, 1); @@ -2387,10 +2392,17 @@ decode_env_path (evarname, defalt) } DEFUN ("daemonp", Fdaemonp, Sdaemonp, 0, 0, 0, - doc: /* Return t if the current emacs process is a daemon. */) + doc: /* Return non-nil if the current emacs process is a daemon. +If the daemon was give a name argument, return that name. */) () { - return is_daemon ? Qt : Qnil; + if (is_daemon) + if (daemon_name) + return build_string (daemon_name); + else + return Qt; + else + return Qnil; } void ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-14 7:26 ` Dan Nicolaescu @ 2008-10-27 7:04 ` Dan Nicolaescu 0 siblings, 0 replies; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-27 7:04 UTC (permalink / raw To: 1058; +Cc: trentbuck, Romain Francoise Dan Nicolaescu <dann@ics.uci.edu> writes: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > > > >> > -(defun server-start (&optional leave-dead) > > >> > +(defun server-start (&optional leave-dead server-arg) > > >> > "Allow this Emacs process to be a server for client processes. > > >> > This starts a server communications subprocess through which > > >> > client \"editors\" can send your editing commands to this Emacs > > >> > @@ -463,6 +463,8 @@ kill any existing server communications > > >> > (when server-process > > >> > ;; kill it dead! > > >> > (ignore-errors (delete-process server-process))) > > >> > + (when (stringp server-arg) > > >> > + (setq server-name server-arg)) > > >> > > >> Changing the global var like this is an ugly hack. > > > > > Sure, it can be moved before the call to `sever-start' > > > I also wanted to make that variable obsolete and make the functional > > > interface the preferred method. > > > > There's no need or reason to make it obsolete. You basically want to > > replace the last two lines above with > > > > (unless (stringp server-arg) > > (setq server-arg server-name)) > > > > and then pass server-arg where it's needed. > > Ah, OK. I had the impression that server-name was needed for other > functions to work correctly, but that is not the case. > Updated patch follows. > > Now it's your choice if you want this patch now or later. I'll update > the docs when checking it in. I checked in a version of this changed as requested by Stefan. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-02 21:32 ` Stefan Monnier 2008-10-02 22:34 ` Dan Nicolaescu @ 2008-10-02 22:42 ` Trent W. Buck 1 sibling, 0 replies; 37+ messages in thread From: Trent W. Buck @ 2008-10-02 22:42 UTC (permalink / raw To: Stefan Monnier; +Cc: 1058, Dan Nicolaescu, Romain Francoise On Thu, Oct 02, 2008 at 05:32:32PM -0400, Stefan Monnier wrote: > >> I could accept a similar patch, maybe, but first I need to understand > >> why/where we currently "detach" so early. > > > Where? in emacs.c:main, look for: > > if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args)) > > { > > #ifndef DOS_NT > > pid_t f = fork (); > > Oh, thanks. I somehow overlooked it. > > > - in order to not make detaching an elisp function, and have to > > deal with users trying to call it from different contexts - the > > `fork' call for detaching needs to happen before some of the > > initialization is run (although after my 2008-09-28 change it > > might be possible to push it later), and also before .emacs is run > > and before the server is started. > > I see what you mean. But I think forking so early is wrong: all > the --eval and .emacs processing should take place "in the foreground" > with input/output from stdin/stdout (like --batch). What happens if .emacs asks questions? Does 'emacs --daemon' require a terminal? Also, I'm currently using the following test to check whether the running Emacs supports --daemon. If you break it, please make some other test work. emacs --batch -q --no-site-file --daemon &>/dev/null ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-02 8:14 ` Dan Nicolaescu 2008-10-02 12:38 ` Stefan Monnier @ 2008-10-02 17:54 ` Romain Francoise 2008-10-02 18:40 ` Dan Nicolaescu ` (2 more replies) 1 sibling, 3 replies; 37+ messages in thread From: Romain Francoise @ 2008-10-02 17:54 UTC (permalink / raw To: Dan Nicolaescu; +Cc: trentbuck, 1058 Here's version one of a patch for this, please let me know what you think. diff --git a/lisp/startup.el b/lisp/startup.el index 5bd73f9..22c92c5 100644 --- a/lisp/startup.el +++ b/lisp/startup.el @@ -1224,7 +1224,8 @@ opening the first frame (e.g. open a connection to an X server).") ;; processing all command line arguments to allow e.g. `server-name' ;; to be changed before the server starts. (when (daemonp) - (server-start)) + (server-start) + (daemon-initialized)) ;; Run emacs-session-restore (session management) if started by ;; the session manager and we have a session manager connection. diff --git a/src/emacs.c b/src/emacs.c index f94d2d3..d4d16b7 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -235,6 +235,13 @@ int noninteractive1; /* Nonzero means Emacs was started as a daemon. */ int is_daemon = 0; +/* Set nonzero after the daemon has finished initializing. */ +int daemon_initialized = 0; + +/* Pipe used to send exit notification to the daemon parent at + startup. */ +int daemon_pipe[2]; + /* Save argv and argc. */ char **initial_argv; int initial_argc; @@ -1074,16 +1081,56 @@ main (int argc, char **argv) if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args)) { #ifndef DOS_NT - pid_t f = fork (); + pid_t f; int nfd; + + /* Start as a daemon: fork a new child process which will run the + rest of the initialization code, then exit. + + We want to avoid exiting before the server socket is ready, so + use a pipe for synchronization. The parent waits for the child + to close its end of the pipe (using `daemon-initialized') + before exiting. */ + if (pipe (daemon_pipe) == -1) + { + fprintf (stderr, "Cannot pipe!\n"); + exit (1); + } + + f = fork (); if (f > 0) - exit (0); + { + int retval; + char buf[1]; + + /* Close unused writing end of the pipe. */ + close (daemon_pipe[1]); + + /* Just wait for the child to close its end of the pipe. */ + do + { + retval = read (daemon_pipe[0], &buf, 1); + } + while (retval == -1 && errno == EINTR); + + if (retval < 0) + { + fprintf (stderr, "Error reading status from child\n"); + exit (1); + } + + close (daemon_pipe[0]); + exit (0); + } if (f < 0) { fprintf (stderr, "Cannot fork!\n"); exit (1); } + /* Close unused reading end of the pipe. */ + close (daemon_pipe[0]); + nfd = open ("/dev/null", O_RDWR); dup2 (nfd, 0); dup2 (nfd, 1); @@ -2389,6 +2436,24 @@ DEFUN ("daemonp", Fdaemonp, Sdaemonp, 0, 0, 0, return is_daemon ? Qt : Qnil; } +DEFUN ("daemon-initialized", Fdaemon_initialized, Sdaemon_initialized, 0, 0, 0, + doc: /* Mark the Emacs daemon as being initialized. */) + () +{ + if (is_daemon) + { + if (! daemon_initialized) + { + /* Closing the pipe will notify the parent that it can exit. */ + close (daemon_pipe[1]); + daemon_initialized = 1; + } + } + else + error ("Emacs was not started as a daemon"); + return daemon_initialized ? Qt : Qnil; +} + void syms_of_emacs () { @@ -2408,6 +2473,7 @@ syms_of_emacs () defsubr (&Sinvocation_name); defsubr (&Sinvocation_directory); defsubr (&Sdaemonp); + defsubr (&Sdaemon_initialized); DEFVAR_LISP ("command-line-args", &Vcommand_line_args, doc: /* Args passed by shell to Emacs, as a list of strings. ^ permalink raw reply related [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-02 17:54 ` Romain Francoise @ 2008-10-02 18:40 ` Dan Nicolaescu 2008-10-06 20:59 ` Dan Nicolaescu 2008-10-26 19:24 ` Dan Nicolaescu 2 siblings, 0 replies; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-02 18:40 UTC (permalink / raw To: Romain Francoise; +Cc: trentbuck, 1058 Romain Francoise <romain@orebokech.com> writes: > Here's version one of a patch for this, please let me know what you > think. Looks good to me (assuming it works), I found some nits: > @@ -1224,7 +1224,8 @@ opening the first frame (e.g. open a connection to an X server).") > ;; processing all command line arguments to allow e.g. `server-name' > ;; to be changed before the server starts. > (when (daemonp) > - (server-start)) > + (server-start) > + (daemon-initialized)) Maybe "notify-daemon-initialized"? > ;; Run emacs-session-restore (session management) if started by > ;; the session manager and we have a session manager connection. > diff --git a/src/emacs.c b/src/emacs.c > index f94d2d3..d4d16b7 100644 > --- a/src/emacs.c > +++ b/src/emacs.c > @@ -235,6 +235,13 @@ int noninteractive1; > /* Nonzero means Emacs was started as a daemon. */ > int is_daemon = 0; > > +/* Set nonzero after the daemon has finished initializing. */ > +int daemon_initialized = 0; Make it a static inside the only user? > +/* Pipe used to send exit notification to the daemon parent at > + startup. */ > +int daemon_pipe[2]; > + > /* Save argv and argc. */ > char **initial_argv; > int initial_argc; > @@ -1074,16 +1081,56 @@ main (int argc, char **argv) > if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args)) > { > #ifndef DOS_NT > - pid_t f = fork (); > + pid_t f; > int nfd; > + > + /* Start as a daemon: fork a new child process which will run the > + rest of the initialization code, then exit. The child runs everything, not only the initialization. Maybe say "exit in order to detach from the terminal" or some such? > +DEFUN ("daemon-initialized", Fdaemon_initialized, Sdaemon_initialized, 0, 0, 0, > + doc: /* Mark the Emacs daemon as being initialized. */) > + () > +{ > + if (is_daemon) > + { > + if (! daemon_initialized) > + { > + /* Closing the pipe will notify the parent that it can exit. */ > + close (daemon_pipe[1]); > + daemon_initialized = 1; > + } else error ("Can only do this once"); BTW, ideally the parent would exit when it detects that the server is started, but that's much more complicated to implement... ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-02 17:54 ` Romain Francoise 2008-10-02 18:40 ` Dan Nicolaescu @ 2008-10-06 20:59 ` Dan Nicolaescu 2008-10-07 14:26 ` Stefan Monnier 2008-10-07 18:45 ` Romain Francoise 2008-10-26 19:24 ` Dan Nicolaescu 2 siblings, 2 replies; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-06 20:59 UTC (permalink / raw To: Romain Francoise; +Cc: trentbuck, 1058 Romain Francoise <romain@orebokech.com> writes: > Here's version one of a patch for this, please let me know what you > think. Here's a version based on your code that also moves detaching from the terminal later. emacs --daemon && emacsclient -c works. Errors in ~/.emacs show up in the *Messages* buffer (as they do when starting up normally). Only lightly tested. Looking at the patch again, I there aren't any new features here, so it can go in as a bug fix. Index: lisp/startup.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/startup.el,v retrieving revision 1.508 diff -u -3 -p -r1.508 startup.el --- lisp/startup.el 6 Oct 2008 16:16:30 -0000 1.508 +++ lisp/startup.el 6 Oct 2008 20:18:41 -0000 @@ -1219,7 +1219,7 @@ opening the first frame (e.g. open a con ;; processing all command line arguments to allow e.g. `server-name' ;; to be changed before the server starts. (when (daemonp) - (server-start)) + (daemon-detach-and-start-server)) ;; Run emacs-session-restore (session management) if started by ;; the session manager and we have a session manager connection. Index: src/emacs.c =================================================================== RCS file: /cvsroot/emacs/emacs/src/emacs.c,v retrieving revision 1.448 diff -u -3 -p -r1.448 emacs.c --- src/emacs.c 6 Oct 2008 16:16:56 -0000 1.448 +++ src/emacs.c 6 Oct 2008 20:18:41 -0000 @@ -238,6 +238,10 @@ int noninteractive1; /* Nonzero means Emacs was started as a daemon. */ int is_daemon = 0; +/* Pipe used to send exit notification to the daemon parent at + startup. */ +static int daemon_pipe[2]; + /* Save argv and argc. */ char **initial_argv; int initial_argc; @@ -1078,25 +1082,7 @@ main (int argc, char **argv) if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args)) { #ifndef DOS_NT - pid_t f = fork (); - int nfd; - if (f > 0) - exit (0); - if (f < 0) - { - fprintf (stderr, "Cannot fork!\n"); - exit (1); - } - - nfd = open ("/dev/null", O_RDWR); - dup2 (nfd, 0); - dup2 (nfd, 1); - dup2 (nfd, 2); - close (nfd); is_daemon = 1; -#ifdef HAVE_SETSID - setsid(); -#endif #else /* DOS_NT */ fprintf (stderr, "This platform does not support the -daemon flag.\n"); exit (1); @@ -2393,6 +2379,87 @@ DEFUN ("daemonp", Fdaemonp, Sdaemonp, 0, return is_daemon ? Qt : Qnil; } + +DEFUN ("daemon-detach-and-start-server", Fdaemon_detach_and_start_server, Sdaemon_detach_and_start_server, 0, 0, 0, + doc: /* Detach from terminal and start the server */) + () +{ + static char daemon_initialized = 0; + pid_t f; + int nfd; + + if (!is_daemon) + error ("This function can only be called if emacs is run as a daemon"); + + if (daemon_initialized) + error ("The daemon has already been initialized"); + + if (NILP (Vafter_init_time)) + error ("This function can only be called after loading the init files"); + + /* Start as a daemon: fork a new child process which will run the + rest of the initialization code, then exit. + + We want to avoid exiting before the server socket is ready, so + use a pipe for synchronization. The parent waits for the child + to close its end of the pipe (using `daemon-initialized') + before exiting. */ + if (pipe (daemon_pipe) == -1) + { + fprintf (stderr, "Cannot pipe!\n"); + exit (1); + } + + f = fork (); + if (f > 0) + { + int retval; + char buf[1]; + + /* Close unused writing end of the pipe. */ + close (daemon_pipe[1]); + + /* Just wait for the child to close its end of the pipe. */ + do + { + retval = read (daemon_pipe[0], &buf, 1); + } + while (retval == -1 && errno == EINTR); + + if (retval < 0) + { + fprintf (stderr, "Error reading status from child\n"); + exit (1); + } + + close (daemon_pipe[0]); + exit (0); + } + if (f < 0) + { + fprintf (stderr, "Cannot fork!\n"); + exit (1); + } + + /* Close unused reading end of the pipe. */ + close (daemon_pipe[0]); + + nfd = open ("/dev/null", O_RDWR); + dup2 (nfd, 0); + dup2 (nfd, 1); + dup2 (nfd, 2); + close (nfd); + is_daemon = 1; +#ifdef HAVE_SETSID + setsid(); +#endif + call0 (intern ("server-start")); + + /* Closing the pipe will notify the parent that it can exit. */ + close (daemon_pipe[1]); + daemon_initialized = 1; +} + void syms_of_emacs () { @@ -2412,6 +2479,7 @@ syms_of_emacs () defsubr (&Sinvocation_name); defsubr (&Sinvocation_directory); defsubr (&Sdaemonp); + defsubr (&Sdaemon_detach_and_start_server); DEFVAR_LISP ("command-line-args", &Vcommand_line_args, doc: /* Args passed by shell to Emacs, as a list of strings. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-06 20:59 ` Dan Nicolaescu @ 2008-10-07 14:26 ` Stefan Monnier 2008-10-07 15:31 ` Dan Nicolaescu 2008-10-07 18:45 ` Romain Francoise 1 sibling, 1 reply; 37+ messages in thread From: Stefan Monnier @ 2008-10-07 14:26 UTC (permalink / raw To: Dan Nicolaescu; +Cc: trentbuck, 1058, Romain Francoise > Errors in ~/.emacs show up in the *Messages* buffer (as they do when > starting up normally). But is the *Messages* buffer automatically displayed (as is done when starting up normally)? This is the main reason why I think that .emacs messages should go to stdout. Especially since the error might even be something that breaks the server, so you can't connect later on to take a look at the *Messages* buffer. Stefan ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-07 14:26 ` Stefan Monnier @ 2008-10-07 15:31 ` Dan Nicolaescu 2008-10-07 23:13 ` Trent W. Buck 2008-10-08 2:25 ` Stefan Monnier 0 siblings, 2 replies; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-07 15:31 UTC (permalink / raw To: Stefan Monnier; +Cc: trentbuck, 1058, Romain Francoise Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > > Errors in ~/.emacs show up in the *Messages* buffer (as they do when > > starting up normally). There are multiple issues being discussed here. 1. > But is the *Messages* buffer automatically displayed (as is done when > starting up normally)? Not yet, but it just takes one extra `if' to do it: --- server.el.~1.168.~ 2008-09-24 17:34:59.000000000 -0700 +++ server.el 2008-10-07 08:09:16.000000000 -0700 @@ -606,7 +606,9 @@ Server mode runs a process that accepts (process-put proc 'terminal (frame-terminal frame)) ;; Display *scratch* by default. - (switch-to-buffer (get-buffer-create "*scratch*") 'norecord) + (switch-to-buffer + (get-buffer-create + (if init-file-had-error "*Messages*" "*scratch*")) 'norecord) ;; Reply with our pid. (server-send-string proc (concat "-emacs-pid " 2. During the normal interactive startup the splash screen nowadays covers the *Messages* buffer too fast, so the user can miss the error. I should file a bug about this... > This is the main reason why I think that .emacs messages should go > to stdout. 3. There's no code in emacs now that can do that for interactive sessions, and when I looked at this it did not look that it can be a small change acceptable during the feature freeze. The `noninteractive' code has it's claws in too many places. > Especially since the error might even be something that breaks the > server, so you can't connect later on to take a look at the > *Messages* buffer. 5. Making the output go to stdout does not avoid this problem at all, it reduces the possibility somewhat, but it does not avoid it. 6. But my original code to start the server early minimizes the window of opportunity for problems in starting the server, the more .emacs, default.el, site-start.el code you run, the more potential for problems in starting the server later. Yes, starting the server early was entirely intentional. 7. This bug report is about something else: emacs --daemon && emacsclient -c not working. Romain's patch looks good, it does not add features, it's just a bug fix, so I don't see any reason it cannot go in right now. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-07 15:31 ` Dan Nicolaescu @ 2008-10-07 23:13 ` Trent W. Buck 2008-10-08 2:03 ` Stefan Monnier 2008-10-08 2:25 ` Stefan Monnier 1 sibling, 1 reply; 37+ messages in thread From: Trent W. Buck @ 2008-10-07 23:13 UTC (permalink / raw To: Dan Nicolaescu; +Cc: 1058, Romain Francoise, Stefan Monnier On Tue, Oct 07, 2008 at 08:31:47AM -0700, Dan Nicolaescu wrote: >> But is the *Messages* buffer automatically displayed (as is done when >> starting up normally)? > > Not yet, but it just takes one extra `if' to do it: > > --- server.el.~1.168.~ 2008-09-24 17:34:59.000000000 -0700 > +++ server.el 2008-10-07 08:09:16.000000000 -0700 > @@ -606,7 +606,9 @@ Server mode runs a process that accepts > (process-put proc 'terminal (frame-terminal frame)) > > ;; Display *scratch* by default. > - (switch-to-buffer (get-buffer-create "*scratch*") 'norecord) > + (switch-to-buffer > + (get-buffer-create > + (if init-file-had-error "*Messages*" "*scratch*")) 'norecord) > > ;; Reply with our pid. > (server-send-string proc (concat "-emacs-pid " Will this result in *Messages* being shown in all emacsclients, or only the first one? > 2. During the normal interactive startup the splash screen nowadays > covers the *Messages* buffer too fast, so the user can miss the error. > I should file a bug about this... > >> This is the main reason why I think that .emacs messages should go >> to stdout. Wouldn't it be better to address the actual issue (splash screen hides *Messages* when something went wrong) rather than side effects (*Messages* is hidden when --daemon, too)? > 7. This bug report is about something else: emacs --daemon && > emacsclient -c not working. Romain's patch looks good, it does not > add features, it's just a bug fix, so I don't see any reason it > cannot go in right now. Correct; stdout / splash screen stuff should be forked to a separate bug. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-07 23:13 ` Trent W. Buck @ 2008-10-08 2:03 ` Stefan Monnier 0 siblings, 0 replies; 37+ messages in thread From: Stefan Monnier @ 2008-10-08 2:03 UTC (permalink / raw To: Trent W. Buck; +Cc: 1058, Dan Nicolaescu, Romain Francoise >> 2. During the normal interactive startup the splash screen nowadays >> covers the *Messages* buffer too fast, so the user can miss the error. >> I should file a bug about this... >> >>> This is the main reason why I think that .emacs messages should go >>> to stdout. > Wouldn't it be better to address the actual issue (splash screen hides > *Messages* when something went wrong) rather than side effects > (*Messages* is hidden when --daemon, too)? The splash screen issue is completely separate. >> 7. This bug report is about something else: emacs --daemon && >> emacsclient -c not working. Romain's patch looks good, it does not >> add features, it's just a bug fix, so I don't see any reason it >> cannot go in right now. > Correct; stdout / splash screen stuff should be forked to a separate bug. Yes and no: the right fix for one is also the right fix for the other, AFAICT. Stefan ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-07 15:31 ` Dan Nicolaescu 2008-10-07 23:13 ` Trent W. Buck @ 2008-10-08 2:25 ` Stefan Monnier 1 sibling, 0 replies; 37+ messages in thread From: Stefan Monnier @ 2008-10-08 2:25 UTC (permalink / raw To: Dan Nicolaescu; +Cc: trentbuck, 1058, Romain Francoise > 1. >> But is the *Messages* buffer automatically displayed (as is done when >> starting up normally)? > Not yet, but it just takes one extra `if' to do it: Actually, I don't care much that issue right now. I'd rather remove the issue altogether than try and fix it. >> This is the main reason why I think that .emacs messages should go >> to stdout. > 3. There's no code in emacs now that can do that for interactive > sessions, and when I looked at this it did not look that it can be a > small change acceptable during the feature freeze. The `noninteractive' > code has it's claws in too many places. I'm not sure it's the case: my Emacs does send the .emacs's messages to stdout before opening the initial X11 frame and I can't remember having to make many significant changes for that, mostly I introduced a new var `uninitialized' (set to nil before loading .emacs and to t afterwards) and then changed a bunch of places that check `noninteractive' to check `noninteractive || uninintialized'. >> Especially since the error might even be something that breaks the >> server, so you can't connect later on to take a look at the >> *Messages* buffer. > 5. Making the output go to stdout does not avoid this problem at all, it > reduces the possibility somewhat, but it does not avoid it. To the contrary, it eliminates the problem altogether: no need to access the *Messages* buffer since you already get the relevant info straight from stdout. > 6. But my original code to start the server early minimizes the window > of opportunity for problems in starting the server, the more .emacs, > default.el, site-start.el code you run, the more potential for problems > in starting the server later. Yes, starting the server early was > entirely intentional. I see what you mean. It might indeed make things simpler, but it eliminates a lot of flexibility. > 7. This bug report is about something else: > emacs --daemon && emacsclient -c > not working. Romain's patch looks good, it does not add features, it's > just a bug fix, so I don't see any reason it cannot go in right now. Looking at your patch again, I think it's indeed going in the right direction. A few notes/questions, tho: I'd rather have just a `daemon-detach' and then be able to call server-start separately from startup.el. Maybe a way to get that is to leave the fork in emacs.c and to turn daemon-detach into little more than close (daemon_pipe[1]). WDYT? Stefan ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-06 20:59 ` Dan Nicolaescu 2008-10-07 14:26 ` Stefan Monnier @ 2008-10-07 18:45 ` Romain Francoise 2008-10-07 19:01 ` Dan Nicolaescu 1 sibling, 1 reply; 37+ messages in thread From: Romain Francoise @ 2008-10-07 18:45 UTC (permalink / raw To: Dan Nicolaescu; +Cc: trentbuck, 1058 Dan Nicolaescu <dann@ics.uci.edu> writes: > Here's a version based on your code that also moves detaching from the > terminal later. Hmm, but the initial frame doesn't get created anyway because `is_daemon' is still set early like before, so it doesn't really change much. I'm unsure which problems this patch addresses. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-07 18:45 ` Romain Francoise @ 2008-10-07 19:01 ` Dan Nicolaescu 0 siblings, 0 replies; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-07 19:01 UTC (permalink / raw To: Romain Francoise; +Cc: trentbuck, 1058 Romain Francoise <romain@orebokech.com> writes: > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > Here's a version based on your code that also moves detaching from the > > terminal later. > > Hmm, but the initial frame doesn't get created anyway because Not sure why you mention that. > `is_daemon' is still set early like before, so it doesn't really > change much. I'm unsure which problems this patch addresses. It moves detaching from the terminal to later, so if emacs ever gets to use stdout/stdin durin startup, it will just work (hopefully). ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-02 17:54 ` Romain Francoise 2008-10-02 18:40 ` Dan Nicolaescu 2008-10-06 20:59 ` Dan Nicolaescu @ 2008-10-26 19:24 ` Dan Nicolaescu 2 siblings, 0 replies; 37+ messages in thread From: Dan Nicolaescu @ 2008-10-26 19:24 UTC (permalink / raw To: Romain Francoise; +Cc: trentbuck, 1058 Romain Francoise <romain@orebokech.com> writes: > Here's version one of a patch for this, please let me know what you > think. I checked this in with some changes requested by Stefan. ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-01 19:39 ` Romain Francoise 2008-10-01 20:19 ` Andreas Schwab 2008-10-01 23:32 ` Dan Nicolaescu @ 2008-10-02 0:50 ` Trent W. Buck 2 siblings, 0 replies; 37+ messages in thread From: Trent W. Buck @ 2008-10-02 0:50 UTC (permalink / raw To: Romain Francoise; +Cc: 1058, Dan Nicolaescu On Wed, Oct 01, 2008 at 09:39:40PM +0200, Romain Francoise wrote: >> Just curious, what do you get if you do: emacs -Q --daemon; while ! >> ls /tmp/emacs1187/; do sleep 1; done > > Yes, the delay is caused by my change to load the init file before > starting the server. It's vaguely relevant that I have this in my .emacs: (progn (unless (< emacs-major-version 22) ;; Support multiple, concurrent Emacs servers. (setq server-name (format "server%d" (emacs-pid))) ;; Allow child processes to find the correct one. (setenv "EMACS_SOCKET_FILE" server-name) ;; Have other processes use the youngest server. (defadvice server-start (after multiple-server-start) (make-symbolic-link server-name (concat server-socket-dir "/server") t)) (ad-activate 'server-start)) (server-start)) and an emacsclient wrapper that includes ## In M-x shell always use the focused emacs, even if there are ## other Emacs servers. Requires non-standard $EMACS_SOCKET_FILE, ## which is set in my .emacs. Needs Emacs 22 or better. if [[ $EMACS_SOCKET_FILE && $INSIDE_EMACS && $v -ge 22 ]] ## With DISPLAY emacsclient tries to pop up an X frame. then exec env -u DISPLAY emacsclient -s "$EMACS_SOCKET_FILE" "$@" fi ^ permalink raw reply [flat|nested] 37+ messages in thread
* bug#1058: 23.0.60; emacs --daemon should not return until socket is ready 2008-10-01 16:51 ` Dan Nicolaescu 2008-10-01 19:39 ` Romain Francoise @ 2008-10-02 0:43 ` Trent W. Buck 1 sibling, 0 replies; 37+ messages in thread From: Trent W. Buck @ 2008-10-02 0:43 UTC (permalink / raw To: Dan Nicolaescu; +Cc: 1058, rfrancoise On Wed, Oct 01, 2008 at 09:51:10AM -0700, Dan Nicolaescu wrote: >> From this transcript, you can see that after starting 'emacs >> --daemon', it takes five seconds before the socket is actually >> available for emacsclient to talk to it. >> >> $ emacs --daemon; while ! ls /tmp/emacs1187/; do sleep 1; done > > Just curious, what do you get if you do: > > emacs -Q --daemon; while ! ls /tmp/emacs1187/; do sleep 1; done I get the same problem. Running c++ elsewhere and starting Emacs nicely, I managed to get the delay up to 17 seconds. $ nice -n 19 emacs -Q --daemon; until ls /tmp/emacs1187/; do sleep 1; done ls: cannot access /tmp/emacs1187/: No such file or directory [repeats 16 times] server ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2008-10-27 7:04 UTC | newest] Thread overview: 37+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-09-30 13:43 bug#1058: 23.0.60; emacs --daemon should not return until socket is ready SRS0+wOMF+22+gmail.com=trentbuck 2008-10-01 16:51 ` Dan Nicolaescu 2008-10-01 19:39 ` Romain Francoise 2008-10-01 20:19 ` Andreas Schwab 2008-10-02 6:05 ` Romain Francoise 2008-10-01 23:32 ` Dan Nicolaescu 2008-10-02 6:07 ` Romain Francoise 2008-10-02 8:14 ` Dan Nicolaescu 2008-10-02 12:38 ` Stefan Monnier 2008-10-02 17:26 ` Dan Nicolaescu 2008-10-02 21:32 ` Stefan Monnier 2008-10-02 22:34 ` Dan Nicolaescu 2008-10-02 22:46 ` Trent W. Buck 2008-10-03 1:12 ` Stefan Monnier 2008-10-03 4:52 ` Dan Nicolaescu 2008-10-03 13:00 ` Stefan Monnier 2008-10-03 17:44 ` Dan Nicolaescu 2008-10-13 2:03 ` Dan Nicolaescu 2008-10-13 15:16 ` Stefan Monnier 2008-10-13 17:01 ` Dan Nicolaescu 2008-10-13 19:07 ` Stefan Monnier 2008-10-14 7:26 ` Dan Nicolaescu 2008-10-27 7:04 ` Dan Nicolaescu 2008-10-02 22:42 ` Trent W. Buck 2008-10-02 17:54 ` Romain Francoise 2008-10-02 18:40 ` Dan Nicolaescu 2008-10-06 20:59 ` Dan Nicolaescu 2008-10-07 14:26 ` Stefan Monnier 2008-10-07 15:31 ` Dan Nicolaescu 2008-10-07 23:13 ` Trent W. Buck 2008-10-08 2:03 ` Stefan Monnier 2008-10-08 2:25 ` Stefan Monnier 2008-10-07 18:45 ` Romain Francoise 2008-10-07 19:01 ` Dan Nicolaescu 2008-10-26 19:24 ` Dan Nicolaescu 2008-10-02 0:50 ` Trent W. Buck 2008-10-02 0:43 ` Trent W. Buck
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.