Daemon mode wishlist

Daemon mode wishlist

[Romain Francoise]

The new daemon mode is neat but it's not really useful for me
because there's no way to customize the socket name, it always uses
the default 'server' socket.  --daemon is processed before --eval so
I can't change it with --eval '(setq server-name "foo")' as the
preload-emacs script does.

Ideally emacs would have a -S option to set the session/socket name
and emacsclient would have switches to list the available sessions
and select one, like screen does.

Re: Daemon mode wishlist

[Dan Nicolaescu]

Romain Francoise <romain@orebokech.com> writes:

  > The new daemon mode is neat but it's not really useful for me
  > because there's no way to customize the socket name, it always uses
  > the default 'server' socket.  --daemon is processed before --eval so
  > I can't change it with --eval '(setq server-name "foo")' as the
  > preload-emacs script does.

Doesn't --eval '(progn (setq server-name "foo") (server-start))' work?

  > Ideally emacs would have a -S option to set the session/socket name
  > and emacsclient would have switches to list the available sessions
  > and select one, like screen does.

My plan is to change --daemon syntax to be --daemon[=NAME[:PORT]]
Then (daemonp) would return (NAME . PORT)
and change server-start to take NAME and PORT as optional arguments.

Do you want to help implementing/documenting and more importantly
getting this approved?

Re: Daemon mode wishlist

[Stefan Monnier]

>> The new daemon mode is neat but it's not really useful for me
>> because there's no way to customize the socket name, it always uses
>> the default 'server' socket.  --daemon is processed before --eval so
>> I can't change it with --eval '(setq server-name "foo")' as the
>> preload-emacs script does.

We should change startup.el so that server-start is called after processing
the .emacs (and the --eval).


        Stefan

Re: Daemon mode wishlist

[Romain Francoise]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Doesn't --eval '(progn (setq server-name "foo") (server-start))' work?

Ah, I hadn't thought of that.  The server gets restarted, of course,
but yes it works.  Thanks.

> My plan is to change --daemon syntax to be --daemon[=NAME[:PORT]]
> Then (daemonp) would return (NAME . PORT)
> and change server-start to take NAME and PORT as optional arguments.

And PORT could be t if you want Emacs to start a TCP server on a
random port as is the default now?

> Do you want to help implementing/documenting and more importantly
> getting this approved?

The first step is probably to get this approved. :)

Re: Daemon mode wishlist

[Stefan Monnier]

>> Doesn't --eval '(progn (setq server-name "foo") (server-start))' work?

> Ah, I hadn't thought of that.  The server gets restarted, of course,
> but yes it works.  Thanks.

>> My plan is to change --daemon syntax to be --daemon[=NAME[:PORT]]
>> Then (daemonp) would return (NAME . PORT)
>> and change server-start to take NAME and PORT as optional arguments.

> And PORT could be t if you want Emacs to start a TCP server on a
> random port as is the default now?

>> Do you want to help implementing/documenting and more importantly
>> getting this approved?

> The first step is probably to get this approved. :)

All of these new features will have to wait.  The only thing we should
do at this stage is move the (server-start) to after processing .emacs
and --eval.


        Stefan

Re: Daemon mode wishlist

[Dan Nicolaescu]

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

  > >> The new daemon mode is neat but it's not really useful for me
  > >> because there's no way to customize the socket name, it always uses
  > >> the default 'server' socket.  --daemon is processed before --eval so
  > >> I can't change it with --eval '(setq server-name "foo")' as the
  > >> preload-emacs script does.
  > 
  > We should change startup.el so that server-start is called after processing
  > the .emacs (and the --eval).

I don't see that as being better, but if someone else wants to do it and
also find a way to solve the problem of specifying the server name and
port on the command line, I won't stand in the way.

Re: Daemon mode wishlist

[Dan Nicolaescu]

Romain Francoise <romain@orebokech.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > My plan is to change --daemon syntax to be --daemon[=NAME[:PORT]]
  > > Then (daemonp) would return (NAME . PORT)
  > > and change server-start to take NAME and PORT as optional arguments.
  > 
  > And PORT could be t if you want Emacs to start a TCP server on a
  > random port as is the default now?

Just omitting it sounds better.

Re: Daemon mode wishlist

[Stefan Monnier]

>> We should change startup.el so that server-start is called after processing
>> the .emacs (and the --eval).

> I don't see that as being better, but if someone else wants to do it and
> also find a way to solve the problem of specifying the server name and
> port on the command line, I won't stand in the way.

It allows the use of

   emacs --eval '(setq server-name "foo")' --daemon

which seems sufficient.  Also it makes server-start take into account
the config settings in the user's .emacs.
I.e. I thing it's just the right thing to do.

You happened to place the call to server-start just at the same place
where you had to disable the call to frame-initialize, but there's
really no fundamental reason why it should be there.


        Stefan

Re: Daemon mode wishlist

[Dan Nicolaescu]

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

  > >> We should change startup.el so that server-start is called after processing
  > >> the .emacs (and the --eval).
  > 
  > > I don't see that as being better, but if someone else wants to do it and
  > > also find a way to solve the problem of specifying the server name and
  > > port on the command line, I won't stand in the way.
  > 
  > It allows the use of
  > 
  >    emacs --eval '(setq server-name "foo")' --daemon
  > 
  > which seems sufficient.  Also it makes server-start take into account
  > the config settings in the user's .emacs.
  > I.e. I thing it's just the right thing to do.

Using --eval is a hack (a Turing complete one), using parameters to
--daemon is more in the spirit of how command line options work (see
what I described in a previous mail: --daemon[=NAME[:PORT]]).
But having that implemented would have increased the size of the patch
(and it's only useful to a very small minority anyway, and that small
minority can use --eval to set the server-name and restart the server).

  > You happened to place the call to server-start just at the same place
  > where you had to disable the call to frame-initialize, but there's
  > really no fundamental reason why it should be there.

Not exactly, I wanted things to work by default, if people change the
server name in .emacs, and use --daemon=NAME, I'd rather want the server
name to be NAME.  But again, if someone wants to change the place where
the server is started, he can go ahead.

Re: Daemon mode wishlist

[Stefan Monnier]

> Not exactly, I wanted things to work by default, if people change the
> server name in .emacs, and use --daemon=NAME, I'd rather want the server
> name to be NAME.  But again, if someone wants to change the place where
> the server is started, he can go ahead.

Could someone do that, please?


        Stefan

Re: Daemon mode wishlist

[Paul R]

Hello,

On Sat, 27 Sep 2008 18:39:12 -0700 (PDT), Dan Nicolaescu <dann@ics.uci.edu> said:
Dan> Not exactly, I wanted things to work by default, if people change
Dan> the server name in .emacs, and use --daemon=NAME, I'd rather want
Dan> the server name to be NAME.

Dan makes a good point here. It also seems to me, from an interface
point of view, that emacs command line should either provide :

    emacs --eval '(progn (setq server-name "foo") (daemonize))'

or

    emacs --daemon[=name[:port]]


Or maybe both. Mixing the two as proposed by Stephan makes perfect
sense for whoever happens to know precisely the loading sequence of
emacs. But probably not as much for the rest of the world.

I know it's feature freeze, but polishing *the CLI* of daemon mode
isn't really a *feature*, and is not likely to introduce some new bug
reports, don't you think ?

-- 
  Paul

Re: Daemon mode wishlist

[Romain Francoise]

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

> Could someone do that, please?

Done.

Re: Daemon mode wishlist

[Stefan Monnier]

>     emacs --eval '(progn (setq server-name "foo") (daemonize))'
> or
>     emacs --daemon[=name[:port]]

   emacs --eval '(setq server-name "foo")' --daemon

should work now.  The server-name can also be set in your .emacs.
This seems to be plenty for those rare cases where this is needed.

> I know it's feature freeze, but polishing *the CLI* of daemon mode
> isn't really a *feature*, and is not likely to introduce some new bug
> reports, don't you think ?

We have more important things to fix first,


        Stefan

Re: Daemon mode wishlist

[Romain Francoise]

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

> All of these new features will have to wait.  The only thing we
> should do at this stage is move the (server-start) to after
> processing .emacs and --eval.

Unfortunately this causes a problem if .emacs prompts the user for
something, as `desktop-read' does if a stale lock exists for the
desktop file.  It calls `y-or-n-p' but the user cannot see nor
answer the question because there is no initial frame, and the
server is not yet started. :(

Any suggestions on how we should handle this?  Should desktop.el be
changed to not prompt?

Re: Daemon mode wishlist

[Stefan Monnier]

>> All of these new features will have to wait.  The only thing we
>> should do at this stage is move the (server-start) to after
>> processing .emacs and --eval.

> Unfortunately this causes a problem if .emacs prompts the user for
> something, as `desktop-read' does if a stale lock exists for the
> desktop file.  It calls `y-or-n-p' but the user cannot see nor
> answer the question because there is no initial frame, and the
> server is not yet started. :(

> Any suggestions on how we should handle this?  Should desktop.el be
> changed to not prompt?

By fixing the other problem, the one where "emacs --daemon" returns
before the server is ready.  Basically, all the .emacs should be read as
if we're running with "--batch", and only at the end should we detach
from the terminal.

As for desktop-read, it will probably need to be reworked to do the
right thing with --daemon.


        Stefan

Re: Daemon mode wishlist

[emacs-dwim]

This one bit me today, causing only minor crashage.  /tmp/X.log filled the
drive with "y, n, or !" prompts from emacs-daemon when my desktop tried to
reload a file with an unsafe file-local variable.  Emacs itself survived
until i shut down gracefully; other processes did not.
-- 
View this message in context: http://old.nabble.com/Daemon-mode-wishlist-tp19695101p28758321.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Daemon mode wishlist

[Chong Yidong]

emacs-dwim <gift_o@excite.com> writes:

> This one bit me today, causing only minor crashage.  /tmp/X.log filled the
> drive with "y, n, or !" prompts from emacs-daemon when my desktop tried to
> reload a file with an unsafe file-local variable.  Emacs itself survived
> until i shut down gracefully; other processes did not.

Could you be a bit more specific about what went wrong?  Do you mean
that repeated "y, n, or !" prompts were issued in daemon mode, but not
when you run Emacs normally?