Re: emacs daemon on win32?

[David De La Harpe Golden <david@harpegolden.net>]

Chong Yidong wrote:

> The easiest approach is to have a separate "emacs-systray" application
> that (i) starts Emacs in daemon mode and (ii) adds a systray icon which
> runs emacsclient when clicked.  "Minimizing to systray" is just the same
> as closing the frame, which is already handled properly in daemon mode.
> 
> (Same approach works for a Gnome or KDE applet.)

Uhm. That sounds kind of complicated to me. Systray support shouldn't 
really be confused with daemon mode.  Daemon == detached from the 
process group, won't quit upon user logout, AFAIK.

Really, proof/pudding/eating, it's up to whoever gets around to actually 
implementing it, but...

The model I had pictured as useful (to me) was like a mail client - 
emacs itself runs upon GUI login since it's part of the desktop 
environment's saved x session, adding itself to the desktop 
environment's systray if show-in-systray* is t, suppressing initial 
frame auto-open if defer-initial-frame* is t**, not immediately quitting 
if all subsequently opened frames are closed and it's still showing in 
systray. And - exiting when the user logs out. I don't think I 
particularly /want/ daemonised emacs processes hanging about forever
on at least my own system, but emacs for the duration of the login 
session sounds nice.

This is kind of what I was getting at daemon mode introduction time - 
some of the secondary features introduced with daemon mode
(e.g. ability to start up without opening an initial frame but with gui 
capability) are relevant outside a true daemon context.

I'm not saying doing it that way doesn't have advantages;  A separate 
emacsclient-systray program might make some sense in conjunction with a 
true daemon mode emacs, too, in order to, well, talk to it and control 
it, like a printer queue monitor systray applet talking to cups.  The 
emacsclient-systray applet, rather than emacs itself, could be the thing 
that runs from the desktop session and quits upon logout - if there was 
an existing daemon emacs, it could presumably be detected and reused. 
And it could/would be lighter weight than firing up emacs proper upon 
login (but emacs' start time is successfully being kept reasonable
for at least modern systems as we recently saw, and it's only once at 
login...).

So on the whole, and this is only IMO, I don't think true daemon and 
emacsserver/client stuff needs to be involved at all in the default case 
of simple systray support.  It's just more stuff to go wrong.

  * hypothetical, and actually I'd maybe be quite likely to use
show-in-systray t, defer-initial-frame nil , so there's an emacs frame 
popped up when I login.

** Er. Though how a customize variable would work for that with current 
initial frame opening vs .emacs running startup-ordering I'm not sure. 
Digressing: can't imagine many people use stuff in their .emacs that 
needs a working initial frame at that time, though ISTR there are some 
from the last time it came up on emacs-devel. Gracelessly attempting to 
shift burden to them for a backward-incompatible change, could they be 
required to insert something like "(ensure-frame-exists)" before the 
first frame-requiring forms in their .emacs if any?  Maybe there's a way 
to make it automatic though, like "advising" all the frame functions 
during .emacs runtime so that if .emacs causes call to any them they in 
turn do an ensure-frame-exists...