Re: start emacs without creating frames and connect with emacsclient later

[Dan Nicolaescu]

David De La Harpe Golden <address@hidden> writes:

  > Dan Nicolaescu wrote:
  > > "Richard M. Stallman" <address@hidden> writes:
  > > 
  > >   >     Should something like this go in?  We do have a feature freeze, 
but this
  > >   >     is quite simple, and it completes the multi-tty functionality, 
which is
  > >   >     one of the major features of 23.1.
  > >   > 
  > >   > I think it should go in
  > >   > provided you write the text for etc/NEWS AND all the relevant manuals.
  > > 
  > > I'll update the all the docs whenever it gets checked in. 
  > > 
  > > Here's a new version of the patch, now it has code to detach from the
  > > terminal, so it is a real daemon (how scary, emacs is haunted by daemons
  > > now).
  > > 
  > 
  > FWIW (Which may not be much...),  I'm not sure that
  > [not opening an initial frame yet retaining ability to open frames] and
  > [daemonizing (detaching from the process group)] and
  > [starting an emacsclient server]
  > should be conflated to quite such a degree.

Well, it's a design goal, and it fits perfectly my use case, which is
not uncommon, a number of people have written scripts to simulate
something like this with a suspended screen session.

  > IMO, a most useful use case for no initial full frame would be in
  > conjunction with systray support i.e. something like emacs --tray (or
  > better a customize variable) that means emacs docks into the systray
  > while obeying X session management.

If someone wants to provide something like that, they can go ahead and
develop a patch.  (I personally have no interest for such a use).

  > That way one could start emacs like a mail client such as kmail,
  > at gui login, and it would be in the systray, popping up new frames
  > on left click, and perhaps having a right click menu
  > {new frame, start/stop server, quit} or the like.
  > 
  > Not sure any of that need to _daemonize_ though (not saying daemonizing
  > isn't useful!) - in fact it might be counterproductive, as emacs
  > might kind of "escape" the session manager.

The fact that emacs "escape" the session manager here is absolutely
intentional.  Being able to access an emacs session over the net,
keeping emacs alive if X crashes, etc is extremely helpful.