bug in server-start

bug in server-start

[Nick Roberts]

This change:

2008-12-12  Juanma Barranquero  <lekktu@gmail.com>
	    Stefan Monnier  <monnier@iro.umontreal.ca>

throws the error:

error: Server "server" is already running

with a second emacs instance when (server-start) is in
the .emacs file because, in this case server-process is nil and so
the server process doesn't actually get deleted.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: bug in server-start

[Juanma Barranquero]

On Mon, Dec 15, 2008 at 10:00, Nick Roberts <nickrob@snap.net.nz> wrote:

> error: Server "server" is already running
>
> with a second emacs instance when (server-start) is in
> the .emacs file because, in this case server-process is nil and so
> the server process doesn't actually get deleted.

IIUC, you're saying that with

;;; .emacs
(server-start)
;;; end of .emacs

and running two emacs at once, the second one throws an error.

That's a feature. If you want to be sure that the most recent Emacs
instance is the current server, you can use

;;; .emacs
(server-force-delete)
(server-start)
;;; end of .emacs

If that's not what you meant, please post detailed instructions to
reproduce the problem.

TIA,

    Juanma

Re: bug in server-start

[Sven Joachim]

On 2008-12-15 11:29 +0100, Juanma Barranquero wrote:

> On Mon, Dec 15, 2008 at 10:00, Nick Roberts <nickrob@snap.net.nz> wrote:
>
>> error: Server "server" is already running
>>
>> with a second emacs instance when (server-start) is in
>> the .emacs file because, in this case server-process is nil and so
>> the server process doesn't actually get deleted.
>
> IIUC, you're saying that with
>
> ;;; .emacs
> (server-start)
> ;;; end of .emacs
>
> and running two emacs at once, the second one throws an error.
>
> That's a feature.

But a feature that doesn't work right ATM, because I can't even check in
.emacs if a server is already running without loading server.el first.
Either make server-start return nil and display a message instead of
throwing an error, or autoload server-running-p so that

(unless (server-running-p)
  (server-start))

works in .emacs.

Sven

Re: bug in server-start

[Juanma Barranquero]

On Mon, Dec 15, 2008 at 11:50, Sven Joachim <svenjoac@gmx.de> wrote:

> But a feature that doesn't work right ATM, because I can't even check in
> .emacs if a server is already running without loading server.el first.

(require 'server)
(unless (server-running-p)
   (server-start))

works. It forces you to load server.el, but an autoload on
server-running-p will do the same thing.

> Either make server-start return nil and display a message instead of
> throwing an error, or autoload server-running-p so that

Turning the error into a message is OK to me. Let's see what does Stefan think.

    Juanma

Re: bug in server-start

[Nick Roberts]

Juanma Barranquero writes:
 > On Mon, Dec 15, 2008 at 10:00, Nick Roberts <nickrob@snap.net.nz> wrote:
 > 
 > > error: Server "server" is already running
 > >
 > > with a second emacs instance when (server-start) is in
 > > the .emacs file because, in this case server-process is nil and so
 > > the server process doesn't actually get deleted.
 > 
 > IIUC, you're saying that with
 > 
 > ;;; .emacs
 > (server-start)
 > ;;; end of .emacs
 > 
 > and running two emacs at once, the second one throws an error.
 > 
 > That's a feature. If you want to be sure that the most recent Emacs
 > instance is the current server, you can use
 > ;;; .emacs
 > (server-force-delete)
 > (server-start)
 > ;;; end of .emacs

What benefit does that bring?  Presumably, previously the first Emacs
instance was the current server, which was fine with me.


 > If that's not what you meant, please post detailed instructions to
 > reproduce the problem.

Yes, that is what I mean't and it follows the description in the manual:

                                            ...or put the expression
  `(server-start)' in your initialization file (*note Init File::).

So I expect many Emacs users will encounter this error.

In contrast, I see no mention of server-force-delete, so they probably won't
know what to do about it except remove server-start from their .emacs, or put
it in a condition-case.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: bug in server-start

[Juanma Barranquero]

On Mon, Dec 15, 2008 at 12:04, Nick Roberts <nickrob@snap.net.nz> wrote:

> What benefit does that bring?  Presumably, previously the first Emacs
> instance was the current server, which was fine with me.

No. If you were using TCP sockets, for example, the second instance
overwrote the authentication file, so the first one was "blind" (there
was no way an emacsclient could connect with it).

> Yes, that is what I mean't and it follows the description in the manual:
>
>                                            ...or put the expression
>  `(server-start)' in your initialization file (*note Init File::).
>
> So I expect many Emacs users will encounter this error.
>
> In contrast, I see no mention of server-force-delete, so they probably won't
> know what to do about it except remove server-start from their .emacs, or put
> it in a condition-case.

I agree that server-force-delete is underdocumented, if not for other
thing that it is just added and we're still trying to see what is the
best interface (so your complain here certainly helps).

That said, the same Info page that you quote says:

   You can run multiple Emacs servers on the same machine by giving
each one a unique "server name", using the variable `server-name'.

Running two instances of Emacs that start servers with the same name
is an error. It's just that it was an undetected error before.

    Juanma

Re: bug in server-start

[Juanma Barranquero]

>> In contrast, I see no mention of server-force-delete, so they probably won't
>> know what to do about it except remove server-start from their .emacs, or put
>> it in a condition-case.

Additional info: I've explained how server-force-delete would help in
your case (if you want the second instance to take over the server
duties).

That said, server-force-delete is more of a user command. The right
thing to do (so to speak) is making sure that you're not starting two
instances with the same name, or that the second one refuses to start.

Perhaps the current behavior of server-start when it detects a server
collision, i.e. erroring out, is too harsh and what Sven Joachim
proposed is better: just show a message and don't start the server.
WDYT?

    Juanma

Re: bug in server-start

[Juanma Barranquero]

On Mon, Dec 15, 2008 at 12:26, Juanma Barranquero <lekktu@gmail.com> wrote:

> Perhaps the current behavior of server-start when it detects a server
> collision, i.e. erroring out, is too harsh and what Sven Joachim
> proposed is better: just show a message and don't start the server.

A message is too inconspicuous, it won't be noticed. A warning, perhaps.

    Juanma

Re: bug in server-start

[Stefan Monnier]

> What benefit does that bring?  Presumably, previously the first Emacs
> instance was the current server, which was fine with me.

No, as mentioned the second was "the current server", overriding
the first.  And when the second exits, it doesn't magically re-enable
the first.
So when starting the second (in Emacs-22), the first server is neutered,
but without even knowing it.  In Emacs-22 it was a problem, but a fairly
minor one.  With "emacs --daemon" this is now a much more serious
problem since if the daemon is thus neutered it will keep running
without the user having any way to access it: it can only look for it in
`ps' and kill it.


        Stefan

Re: bug in server-start

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > What benefit does that bring?  Presumably, previously the first Emacs
  > > instance was the current server, which was fine with me.
  > 
  > No, as mentioned the second was "the current server", overriding
  > the first.  And when the second exits, it doesn't magically re-enable
  > the first.
  > So when starting the second (in Emacs-22), the first server is neutered,
  > but without even knowing it.  In Emacs-22 it was a problem, but a fairly
  > minor one.  With "emacs --daemon" this is now a much more serious
  > problem since if the daemon is thus neutered it will keep running
  > without the user having any way to access it: it can only look for it in
  > `ps' and kill it.

We could install something by default to restart the server when
receiving an USR1 or USR2 signal.

Also currently the daemon is broken:

emacs -Q -f server-start&

emacs --daemon 
Server "server" is already running

and the daemon is not started...

Re: bug in server-start

[Juanma Barranquero]

On Mon, Dec 15, 2008 at 18:24, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> We could install something by default to restart the server when
> receiving an USR1 or USR2 signal.

That was discussed a while ago, IIRC. Why wasn't it installed?

> Also currently the daemon is broken:
>
> emacs -Q -f server-start&
>
> emacs --daemon
> Server "server" is already running
>
> and the daemon is not started...

Do you mean, I suppose, that Emacs starts but it is not responsive
because it is running no server?

How do you propose to fix it? We can make --daemon to do the
equivalent of "(progn (server-force-delete) (server-start))", or exit
with an error if there's a name-matching server. Other ideas?

    Juanma

Re: bug in server-start

[Romain Francoise]

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

> How do you propose to fix it? We can make --daemon to do the
> equivalent of "(progn (server-force-delete) (server-start))", or
> exit with an error if there's a name-matching server. Other ideas?

Start a server named 'server.$pid'?  Then you can attach and kill it
properly.

Re: bug in server-start

[Dan Nicolaescu]

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

  > On Mon, Dec 15, 2008 at 18:24, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > We could install something by default to restart the server when
  > > receiving an USR1 or USR2 signal.
  > 
  > That was discussed a while ago, IIRC. Why wasn't it installed?
  > 
  > > Also currently the daemon is broken:
  > >
  > > emacs -Q -f server-start&
  > >
  > > emacs --daemon
  > > Server "server" is already running
  > >
  > > and the daemon is not started...
  > 
  > Do you mean, I suppose, that Emacs starts but it is not responsive
  > because it is running no server?

No.

Re: bug in server-start

[Ulrich Mueller]

>>>>> On Mon, 15 Dec 2008, Juanma Barranquero wrote:

> On Mon, Dec 15, 2008 at 18:24, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>> We could install something by default to restart the server when
>> receiving an USR1 or USR2 signal.

> That was discussed a while ago, IIRC. Why wasn't it installed?

As far as I've understood, Stefan didn't find it very useful. So I've
added the following to Gentoo site initialisation, if Emacs is running
as a daemon: (define-key special-event-map [sigusr1] 'server-start)

>> Also currently the daemon is broken:
>> 
>> emacs -Q -f server-start&
>> 
>> emacs --daemon
>> Server "server" is already running
>> 
>> and the daemon is not started...

> Do you mean, I suppose, that Emacs starts but it is not responsive
> because it is running no server?

> How do you propose to fix it? We can make --daemon to do the
> equivalent of "(progn (server-force-delete) (server-start))",

Hm, this doesn't look very consistent to me, because the behaviour is
different from starting a second server.

> or exit with an error if there's a name-matching server. Other
> ideas?

Exit with an error, please. And if possible, the parent process should
return a nonzero exit status. (AFAICS, not calling daemon-initialized
should be sufficient for this, but I haven't tested it.)

If users want a daemon to take precedence over a "normal" server (i.e.
your first suggestion), they can still put a (server-force-delete)
into their .emacs or site-start.el.

Ulrich

Re: bug in server-start

[Juanma Barranquero]

On Tue, Dec 16, 2008 at 08:03, Ulrich Mueller <ulm@gentoo.org> wrote:

> Exit with an error, please. And if possible, the parent process should
> return a nonzero exit status. (AFAICS, not calling daemon-initialized
> should be sufficient for this, but I haven't tested it.)

Please, try the attached patch.

    Juanma



Index: lisp/server.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/server.el,v
retrieving revision 1.176
diff -u -2 -r1.176 server.el
--- lisp/server.el	12 Dec 2008 00:33:34 -0000	1.176
+++ lisp/server.el	16 Dec 2008 09:21:13 -0000
@@ -480,5 +480,6 @@
 	  (ignore-errors (delete-file server-file))
 	(setq server-mode nil) ;; already set by the minor mode code
-	(error "Server %S is already running" server-name))
+	(display-warning 'server (format "Server %S is already running" server-name))
+	(setq leave-dead t))
       ;; If this Emacs already had a server, clear out associated status.
       (while server-clients
@@ -487,5 +488,5 @@
       (if leave-dead
 	  (progn
-	    (server-log (message "Server stopped"))
+	    (unless (eq t leave-dead) (server-log (message "Server stopped")))
 	    (setq server-process nil))
 	;; Make sure there is a safe directory in which to place the socket.
Index: lisp/startup.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/startup.el,v
retrieving revision 1.523
diff -u -2 -r1.523 startup.el
--- lisp/startup.el	22 Nov 2008 20:44:42 -0000	1.523
+++ lisp/startup.el	16 Dec 2008 09:22:11 -0000
@@ -695,4 +695,5 @@

 (defvar server-name)
+(defvar server-process)

 (defun command-line ()
@@ -1221,5 +1222,8 @@
       (when (stringp dn) (setq server-name dn))
       (server-start)
-      (daemon-initialized)))
+      (if server-process
+	  (daemon-initialized)
+	(message "Could not start daemon %S" server-name)
+	(kill-emacs 1))))

   ;; Run emacs-session-restore (session management) if started by

Re: bug in server-start

[Ulrich Mueller]

>>>>> On Tue, 16 Dec 2008, Juanma Barranquero wrote:

>> Exit with an error, please. And if possible, the parent process should
>> return a nonzero exit status. (AFAICS, not calling daemon-initialized
>> should be sufficient for this, but I haven't tested it.)

It turns out that I should have tested this ...

> Please, try the attached patch.

Looks good, except for the exit status of the parent which is zero.
The following will test for one character to be read from the pipe
(which is sent when daemon-initialized is called):

--- src/emacs.c
+++ src/emacs.c
@@ -1124,7 +1124,7 @@
 	    }
 	  while (retval == -1 && errno == EINTR);
 
-	  if (retval < 0)
+	  if (retval <= 0)
 	    {
 	      fprintf (stderr, "Error reading status from child\n");
 	      exit (1);

Ulrich

Re: bug in server-start

[Juanma Barranquero]

On Tue, Dec 16, 2008 at 12:49, Ulrich Mueller <ulm@gentoo.org> wrote:

> Looks good, except for the exit status of the parent which is zero.
> The following will test for one character to be read from the pipe
> (which is sent when daemon-initialized is called):
>
> --- src/emacs.c
> +++ src/emacs.c
> @@ -1124,7 +1124,7 @@
>            }
>          while (retval == -1 && errno == EINTR);
>
> -         if (retval < 0)
> +         if (retval <= 0)
>            {
>              fprintf (stderr, "Error reading status from child\n");
>              exit (1);
>

I cannot test that part of the code, so I'll leave that change for Dan.

As for my changes, have you tested them? ("Looks good" is not the same
as "Works OK" ;-)

    Juanma

Re: bug in server-start

[Ulrich Mueller]

>>>>> On Tue, 16 Dec 2008, Juanma Barranquero wrote:

>> Looks good, except for the exit status of the parent which is zero.

> As for my changes, have you tested them? ("Looks good" is not the
> same as "Works OK" ;-)

I meant the latter. Tested and works fine. :)

Ulrich

Re: bug in server-start

[Stefan Monnier]

>>> Exit with an error, please. And if possible, the parent process should
>>> return a nonzero exit status. (AFAICS, not calling daemon-initialized
>>> should be sufficient for this, but I haven't tested it.)
> It turns out that I should have tested this ...
>> Please, try the attached patch.
> Looks good, except for the exit status of the parent which is zero.
> The following will test for one character to be read from the pipe
> (which is sent when daemon-initialized is called):

> --- src/emacs.c
> +++ src/emacs.c
> @@ -1124,7 +1124,7 @@
>  	    }
>  	  while (retval == -1 && errno == EINTR);
 
> -	  if (retval < 0)
> +	  if (retval <= 0)
>  	    {
>  	      fprintf (stderr, "Error reading status from child\n");
>  	      exit (1);

Indeed, we should return a non-zero status, but this patch ends up with
this undesirable "Error reading status from child" message, so we want
something better.


        Stefan

Re: bug in server-start

[Ulrich Mueller]

>>>>> On Tue, 16 Dec 2008, Stefan Monnier wrote:

>> --- src/emacs.c
>> +++ src/emacs.c
>> @@ -1124,7 +1124,7 @@
>> }
>> while (retval == -1 && errno == EINTR);
 
>> -	  if (retval < 0)
>> +	  if (retval <= 0)
>> {
>> fprintf (stderr, "Error reading status from child\n");
>> exit (1);

> Indeed, we should return a non-zero status, but this patch ends up with
> this undesirable "Error reading status from child" message, so we want
> something better.

If only the error message is your concern, then one could check for
retval < 0 and retval == 0 separately.

Ulrich

Re: bug in server-start

[Dan Nicolaescu]

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

  > On Tue, Dec 16, 2008 at 08:03, Ulrich Mueller <ulm@gentoo.org> wrote:
  > 
  > > Exit with an error, please. And if possible, the parent process should
  > > return a nonzero exit status. (AFAICS, not calling daemon-initialized
  > > should be sufficient for this, but I haven't tested it.)
  > 
  > Please, try the attached patch.
  > 
  >     Juanma
  > 
  > 
  > 
  > Index: lisp/server.el
  > ===================================================================
  > RCS file: /sources/emacs/emacs/lisp/server.el,v
  > retrieving revision 1.176
  > diff -u -2 -r1.176 server.el
  > --- lisp/server.el	12 Dec 2008 00:33:34 -0000	1.176
  > +++ lisp/server.el	16 Dec 2008 09:21:13 -0000
  > @@ -480,5 +480,6 @@
  >  	  (ignore-errors (delete-file server-file))
  >  	(setq server-mode nil) ;; already set by the minor mode code
  > -	(error "Server %S is already running" server-name))
  > +	(display-warning 'server (format "Server %S is already running" server-name))
  > +	(setq leave-dead t))
  >        ;; If this Emacs already had a server, clear out associated status.
  >        (while server-clients
  > @@ -487,5 +488,5 @@
  >        (if leave-dead
  >  	  (progn
  > -	    (server-log (message "Server stopped"))
  > +	    (unless (eq t leave-dead) (server-log (message "Server stopped")))
  >  	    (setq server-process nil))
  >  	;; Make sure there is a safe directory in which to place the socket.
  > Index: lisp/startup.el
  > ===================================================================
  > RCS file: /sources/emacs/emacs/lisp/startup.el,v
  > retrieving revision 1.523
  > diff -u -2 -r1.523 startup.el
  > --- lisp/startup.el	22 Nov 2008 20:44:42 -0000	1.523
  > +++ lisp/startup.el	16 Dec 2008 09:22:11 -0000
  > @@ -695,4 +695,5 @@
  > 
  >  (defvar server-name)
  > +(defvar server-process)
  > 
  >  (defun command-line ()
  > @@ -1221,5 +1222,8 @@
  >        (when (stringp dn) (setq server-name dn))
  >        (server-start)
  > -      (daemon-initialized)))
  > +      (if server-process
  > +	  (daemon-initialized)
  > +	(message "Could not start daemon %S" server-name)

This shouldn't mention the server-name name if --daemon is not passed
any argument.  Most users won't know, nor care about that.

The same is true about the server.el error:
Server "server" is already running
is kind of confusing.

Re: bug in server-start

[Juanma Barranquero]

On Tue, Dec 16, 2008 at 17:01, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> This shouldn't mention the server-name name if --daemon is not passed
> any argument.  Most users won't know, nor care about that.

Do you mean to default to not showing the server name, except when it
is different from "server"?
That's OK to me.

    Juanma

Re: bug in server-start

[Dan Nicolaescu]

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

  > On Tue, Dec 16, 2008 at 17:01, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > This shouldn't mention the server-name name if --daemon is not passed
  > > any argument.  Most users won't know, nor care about that.
  > 
  > Do you mean to default to not showing the server name, except when it
  > is different from "server"?

No.

Re: bug in server-start

[Juanma Barranquero]

On Tue, Dec 16, 2008 at 17:15, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> No.

Then you'll have to explain it more clearly. I cannot read your mind.

    Juanma

Re: bug in server-start

[Dan Nicolaescu]

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

  > On Tue, Dec 16, 2008 at 17:15, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > No.
  > 
  > Then you'll have to explain it more clearly. I cannot read your mind.

Why don't you explain what part of what I wrote was unclear?

Re: bug in server-start

[Juanma Barranquero]

> Why don't you explain what part of what I wrote was unclear?

The part where you consider that

   Server "server" is already running

(while talking about server.el) is confusing but apparently you don't
consider confusing

   Could not start daemon "server"

if passed --daemon=server; or, now that I think of it,

   Could not start daemon "daemon"

if passed --daemon=daemon.

As for the "Most users won't know, nor care about that", diagnostic
messages usually contain relevant information, that the user is free
to ignore. We're not talking of several screenfuls of data, just
server-name (which the user would benefit of knowing about).

    Juanma

Re: bug in server-start

[Dan Nicolaescu]

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

  > > Why don't you explain what part of what I wrote was unclear?
  > 
  > The part where you consider that
  > 
  >    Server "server" is already running
  > 
  > (while talking about server.el) is confusing but apparently you don't
  > consider confusing

  >    Could not start daemon "server"

What exactly made you think that I said the above message was not
confusing???

  > if passed --daemon=server; or, now that I think of it,

Yes, if the user makes the conscious choice of passing an argument to
--daemon, then you can mention it in the error message.  If she doesn't,
then there's little point of doing so, especially when the message is so
short and unexplanatory.

The take home message here is that the error messages need a bit more
thought put into them.

Re: bug in server-start

[Juanma Barranquero]

On Tue, Dec 16, 2008 at 18:00, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> What exactly made you think that I said the above message was not
> confusing???

I'm talking of the case where the user passes "server" as daemon name.

> Yes, if the user makes the conscious choice of passing an argument to
> --daemon, then you can mention it in the error message.  If she doesn't,
> then there's little point of doing so, especially when the message is so
> short and unexplanatory.

As I've stated previously, I don't agree with the "there's little
point of doing so" part.

> The take home message here is that the error messages need a bit more
> thought put into them.

I've put some more thought into it, and I still don't agree with you.
Let's hear other people's opinions.

    Juanma

Re: bug in server-start

[Dan Nicolaescu]

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

  > On Tue, Dec 16, 2008 at 18:00, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > What exactly made you think that I said the above message was not
  > > confusing???
  > 
  > I'm talking of the case where the user passes "server" as daemon name.

Again, can you please point out where exactly I said that the message
you cited was not confusing???

  > > Yes, if the user makes the conscious choice of passing an argument to
  > > --daemon, then you can mention it in the error message.  If she doesn't,
  > > then there's little point of doing so, especially when the message is so
  > > short and unexplanatory.
  > 
  > As I've stated previously, I don't agree with the "there's little
  > point of doing so" part.


  > > The take home message here is that the error messages need a bit more
  > > thought put into them.
  > 
  > I've put some more thought into it, and I still don't agree with you.

You haven't yet given any explanation why not.

Re: bug in server-start

[Juanma Barranquero]

On Tue, Dec 16, 2008 at 19:51, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Again, can you please point out where exactly I said that the message
> you cited was not confusing???

You didn't exactly said that, of course. You said that the message in
server.el was confusing, and that you supported adding the server name
to the error message when the user passed it explicitly. I assumed
that you meant that you don't think the message is confusing when the
user has passed the server name. Apparently what you mean is that when
the user passes the server name, the error message will sometimes be
confusing, but you don't care because the user gets what he asked for.

> You haven't yet given any explanation why not.

Yes, I've done it: I've said that I think error messages should be
informative, and that knowing the server name is useful IMHO. Perhaps
you don't use multiple servers, or if you do, you don't use the
default "server". I do.

AFAICS, your explanation of why you oppose this is "Most users won't
know, nor care about that", which is a generalization, too. You don't
know what most users know or care, any more than I do.

    Juanma

Re: bug in server-start

[Dan Nicolaescu]

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

  > On Tue, Dec 16, 2008 at 19:51, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > Again, can you please point out where exactly I said that the message
  > > you cited was not confusing???
  > 
  > You didn't exactly said that, of course. 

Then PLEASE STOP making statements about what I said when that is
clearly not true.

For the record, I do think that this is unhelpful:

(display-warning 'server (format "Server %S is already running" server-name))

Given that the 23.1 behavior is different than what happened before,
this will not help users easily find out what is wrong. 

  > You said that the message in
  > server.el was confusing, and that you supported adding the server name
  > to the error message when the user passed it explicitly. I assumed
  > that you meant that you don't think the message is confusing when the
  > user has passed the server name. Apparently what you mean is that when
  > the user passes the server name, the error message will sometimes be
  > confusing, but you don't care because the user gets what he asked for.
  > 
  > > You haven't yet given any explanation why not.
  > 
  > Yes, I've done it: I've said that I think error messages should be
  > informative, and that knowing the server name is useful IMHO. Perhaps
  > you don't use multiple servers, or if you do, you don't use the
  > default "server". 

PLEASE STOP making statements here about what I do or do not, when you
have no information to support your suppositions.  Thank you.

  > AFAICS, your explanation of why you oppose this is "Most users won't
  > know, nor care about that", which is a generalization, too. You
  > don't know what most users know or care, any more than I do.

There's a strong hint in the fact that server-name is a defvar with no
docstring (not a defcustom).
I designed --daemon to be very easy to use, I want the error messages to
be easy to understand/debug too.

Re: bug in server-start

[Juanma Barranquero]

On Tue, Dec 16, 2008 at 20:28, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Then PLEASE STOP making statements about what I said when that is
> clearly not true.

Then PLEASE STOP trying to turn this discussion into another confrontation.

> (display-warning 'server (format "Server %S is already running" server-name))
>
> Given that the 23.1 behavior is different than what happened before,
> this will not help users easily find out what is wrong.

What will help the users find out what is wrong? Not giving them a warning?

> PLEASE STOP making statements here about what I do or do not, when you
> have no information to support your suppositions.  Thank you.

PLEASE STOP using that tone, and PLEASE LOOK for "perhaps" in a dictionary.

> There's a strong hint in the fact that server-name is a defvar with no
> docstring (not a defcustom).

Nonsense. The manual clearly says that you can run several servers
provided that you use different names, and before --daemon (and even
now, on Windows) there's no user command to set the server-name. If
anything, perhaps it should be a defcustom, or at the very least have
a docstring.

> I designed --daemon to be very easy to use, I want the error messages to
> be easy to understand/debug too.

And the difference between

   Could not start daemon

and

  Could not start daemon "server"

(or, 'Could not start daemon named "server"')

makes the error messages difficult to understand/debug? How so?

    Juanma

Re: bug in server-start

[Dan Nicolaescu]

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

  > On Tue, Dec 16, 2008 at 20:28, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > Then PLEASE STOP making statements about what I said when that is
  > > clearly not true.
  > 
  > Then PLEASE STOP trying to turn this discussion into another confrontation.

You gotta be kidding.

  > > (display-warning 'server (format "Server %S is already running" server-name))
  > >
  > > Given that the 23.1 behavior is different than what happened before,
  > > this will not help users easily find out what is wrong.
  > 
  > What will help the users find out what is wrong? Not giving them a warning?

How about an error message that is more explicit?

  > > PLEASE STOP making statements here about what I do or do not, when you
  > > have no information to support your suppositions.  Thank you.
  > 
  > PLEASE STOP using that tone, and PLEASE LOOK for "perhaps" in a dictionary.

You might want to reread what I wrote.  Making suppositions about what
someone does or does not do does not help your argument, STOP THAT.

  > > There's a strong hint in the fact that server-name is a defvar with no
  > > docstring (not a defcustom).
  > 
  > Nonsense. The manual clearly says that you can run several servers
  > provided that you use different names, and before --daemon (and even
  > now, on Windows) there's no user command to set the server-name. If
  > anything, perhaps it should be a defcustom, or at the very least have
  > a docstring.
  > 
  > > I designed --daemon to be very easy to use, I want the error messages to
  > > be easy to understand/debug too.
  > 
  > And the difference between
  > 
  >    Could not start daemon
  > 
  > and
  > 
  >   Could not start daemon "server"
  > 
  > (or, 'Could not start daemon named "server"')
  > 
  > makes the error messages difficult to understand/debug? How so?

What makes you think that it's just a binary choice here?

Re: bug in server-start

[Juanma Barranquero]

On Tue, Dec 16, 2008 at 20:58, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> You gotta be kidding.

I knew we had to have something in common...

> How about an error message that is more explicit?

OK, I can agree with that. Care to formulate it? (I'm not being
facetious; I hate writing doc messages in English).

> You might want to reread what I wrote.  Making suppositions about what
> someone does or does not do does not help your argument

Yes, sometimes it does help the argument because it helps understand
the likely mindstate of your interlocutor.

> STOP THAT.

STOP THAT you too. It's getting old.

> What makes you think that it's just a binary choice here?

That's a cop out. What is the exact message you want?

    Juanma

Re: bug in server-start

[Dan Nicolaescu]

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

  > On Tue, Dec 16, 2008 at 20:58, Dan Nicolaescu <dann@ics.uci.edu> wrote:

  > > How about an error message that is more explicit?
  > 
  > OK, I can agree with that. Care to formulate it? (I'm not being
  > facetious; I hate writing doc messages in English).

You could have said so in the beginning, without all this drawn out,
pointless, nonsense.

  > > What makes you think that it's just a binary choice here?
  > 
  > That's a cop out. What is the exact message you want?

Given that we aren't getting anywhere here, I don't want to waste any
more time on this at the moment.  I'll take care of this one (the daemon
error message to be specific) after the code gets checked in.

Hopefully someone else will take care of the server.el error message.

Re: bug in server-start

[Juanma Barranquero]

On Tue, Dec 16, 2008 at 21:59, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> You could have said so in the beginning, without all this drawn out,
> pointless, nonsense.

Ridiculous: I hate writing docstrings, but I still think that showing
the server-name is the Right Thing To Do, which is what I was
defending. At *no point* I've said or implied that I though my wording
could not be enhanced (quite the contrary).

> Given that we aren't getting anywhere here, I don't want to waste any
> more time on this at the moment.  I'll take care of this one (the daemon
> error message to be specific) after the code gets checked in.

How like you.

    Juanma

Re: bug in server-start

[Chong Yidong]

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

>    Could not start daemon "server"
>    Could not start daemon "daemon"

If the point is that the daemon could not start because the server name
is already taken, just make it explicit:

    Unable to start daemon: Emacs server named "server" already running

Re: bug in server-start

[Juanma Barranquero]

On Tue, Dec 16, 2008 at 21:56, Chong Yidong <cyd@stupidchicken.com> wrote:

>    Unable to start daemon: Emacs server named "server" already running

Yes, I'll use that. Thanks.

    Juanma

Re: bug in server-start

[Stefan Monnier]

>> This shouldn't mention the server-name name if --daemon is not passed
>> any argument.  Most users won't know, nor care about that.
> Do you mean to default to not showing the server name, except when it
> is different from "server"?
> That's OK to me.

Agreed,


        Stefan

Re: bug in server-start

[Stefan Monnier]

> We could install something by default to restart the server when
> receiving an USR1 or USR2 signal.

We could, but it wouldn't change much to the underlying problem: the
user still needs to somehow figure out (or at least suspect) that
there's a dormant server, then use `ps' to find the PID.

> Also currently the daemon is broken:

> emacs -Q -f server-start&

> emacs --daemon 
> Server "server" is already running

> and the daemon is not started...

Indeed, there's a bug here: it's correct that the daemon is not started,
but the error should cause the daemon to quit.


        Stefan

Re: bug in server-start

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > We could install something by default to restart the server when
  > > receiving an USR1 or USR2 signal.
  > 
  > We could, but it wouldn't change much to the underlying problem: the
  > user still needs to somehow figure out (or at least suspect) that
  > there's a dormant server, then use `ps' to find the PID.

Having the binding gives you one way to handle the server instead of none.

Sometimes the "server" socket gets deleted by an overzealous /tmp cleaner
cron job leaving you with no way to control the server...

Re: bug in server-start

[Stefan Monnier]

> Sometimes the "server" socket gets deleted by an overzealous /tmp cleaner
> cron job leaving you with no way to control the server...

The last time I heard of such an idiotic thing was what .... 10 years ago?
Has anybody seen such a beast more recently, really?


        Stefan

Re: bug in server-start

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > Sometimes the "server" socket gets deleted by an overzealous /tmp cleaner
  > > cron job leaving you with no way to control the server...
  > 
  > The last time I heard of such an idiotic thing was what .... 10 years ago?
  > Has anybody seen such a beast more recently, really?

Yep, within last month, with an OS that was released in 2002.  Don't
underestimate how long IT people want to keep systems in use.