emacs daemon on win32?

emacs daemon on win32?

[dhruva]

Hello,
 I was hoping to have emacs daemon on M$ platforms. I did a quick hack
by enabling is_daemon (through the debugger - easier than modifying
the source) to see where it groks. From my limited understanding, the
'sys_select' with following message.

warning: select.WaitForMultipleObjects (2, 4406) failed with 6

If am in the process of debugging it further, if someone has already
explored this path, please let me know or guide me.

-dhruva

-- 
Contents reflect my personal views only!

Re: emacs daemon on win32?

[Eli Zaretskii]

> Date: Sun, 12 Oct 2008 10:45:19 +0530
> From: dhruva <dhruvakm@gmail.com>
> 
>  I was hoping to have emacs daemon on M$ platforms. I did a quick hack
> by enabling is_daemon (through the debugger - easier than modifying
> the source) to see where it groks. From my limited understanding, the
> 'sys_select' with following message.
> 
> warning: select.WaitForMultipleObjects (2, 4406) failed with 6
> 
> If am in the process of debugging it further, if someone has already
> explored this path, please let me know or guide me.

Why does it make sense to have this on Windows?  What would you like
to accomplish with this option on Windows?

Re: emacs daemon on win32?

[Juanma Barranquero]

On Sun, Oct 12, 2008 at 20:03, Eli Zaretskii <eliz@gnu.org> wrote:

>> Date: Sun, 12 Oct 2008 10:45:19 +0530
>> From: dhruva <dhruvakm@gmail.com>
>>
>>  I was hoping to have emacs daemon on M$ platforms.
[...]
>
> Why does it make sense to have this on Windows?  What would you like
> to accomplish with this option on Windows?

I'm not proposing doing anything right now (these are new features),
but I think a daemon-like behavior on Windows would make sense, even
if we're not talking of a true Windows service (which would bring
little benefit, other than automatic (re)starting, for quite a lot of
added complexity).

The cool thing would be to have a Windows Emacs server start as a
systray app. I'd love for Emacs not to use space in the taskbar, just
in the tray, until I bring it forward with emacsclient. David De La
Harpe Golden proposed as much back in August (though he was talking
about GNU/Linux, I think).

As a lesser alternative, an Emacs server could simply hide its taskbar
button(s) when minimized, at least initially.

Not really related, but still: why does Emacs on Windows not handle
WM_(QUERY)ENDSESSION messages? There was discussion in July 2006 (in a
thread called "Exit hooks not run at logout on w32"), with no clear
consensus emerging on what to do.

   Juanma

Re: emacs daemon on win32?

[jasonr]

Quoting Juanma Barranquero <lekktu@gmail.com>:

> Not really related, but still: why does Emacs on Windows not handle
> WM_(QUERY)ENDSESSION messages?

It uses SetConsoleCtrlHandler to register a handler for shutdown messages
instead, since that works even for emacs -nw.

Re: emacs daemon on win32?

[Juanma Barranquero]

On Tue, Oct 28, 2008 at 15:39,  <jasonr@f2s.com> wrote:

> It uses SetConsoleCtrlHandler to register a handler for shutdown messages
> instead, since that works even for emacs -nw.

Aha, thanks.

             Juanma

Re: emacs daemon on win32?

[David De La Harpe Golden]

Juanma Barranquero wrote:

> The cool thing would be to have a Windows Emacs server start as a
> systray app. I'd love for Emacs not to use space in the taskbar, just
> in the tray, until I bring it forward with emacsclient. David De La
> Harpe Golden proposed as much back in August (though he was talking
> about GNU/Linux, I think).
> 

I was, or rather freedesktop.org compliant desktops in general that 
follow the relevant systray spec*, but only because that's the 
environment I personally know or care about, similar functionality on 
other platforms with GUI conventions for such things is presumably 
equally desirable.

While I believe the spec is straightforward, I personally won't have 
time to look implementing it in the next few days anyway (tax filing 
deadline is Hallowe'en in Ireland, appropriately enough!), so below find 
my (trivial) design notes.

*
http://standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html


I imagined an emacs icon in the systray, clicking left button just 
opening a new frame, right button bringing up a small menu with 
something like
Open File...						[1]
New Frame
New Frame on Display...					[2]
Start Emacs Server [/ Stop Emacs Server]                [3]
Settings...						[4]
Quit Emacs						[5]

I really don't think you'd want more than that on the menu, keep it simple.

Note that the systray support could also be used for popup balloon 
message notifications too, in the manner described in *, e.g. new mail 
notifications for intra-emacs mail/news clients. (biff being long-dead 
for all practical purposes)

[1] - Jumping straight to open file dialog, opening in new frame.
(or of course new frame and show file list if you've turned the 
dire-on-gtk/gnome system GUI file dialog off)

[2] Not sure about this one, might be considered advanced functionality.

[3] I think for the present people will want to be able to restart the 
emacsclient server from the menu (since in my experience it's fairly 
easy to accidentally nuke the socket with another emacs or whatever, and 
then the only practical option is to restart it).   I guess a tooltip 
should say something like "when the server is running, you can use 
emacsclient from the command line to edit files in this emacs session". 
  The started/stopped state should probably be persistent across sessions
(i.e. whether emacs starts the server when emacs is started upon login).

[4] jumping straight to a new frame opened on the customize toplevel I 
guess.

[5] This should probably give a modified close dialog asking if you want 
emacs restarted upon next login or not, most systray apps do AFAIK even 
if it's strictly kinda redundant (since one could just not quit it or
restart it before logout if you wanted the session to save the fact it's 
there...)

Re: emacs daemon on win32?

[David De La Harpe Golden]

David De La Harpe Golden wrote:

> While I believe the spec is straightforward, I personally won't have 
> time to look implementing it in the next few days anyway (tax filing 
> deadline is Hallowe'en in Ireland, appropriately enough!), so below find 
> my (trivial) design notes.
> 
> *
> http://standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html 
> 
> 


Braindump addendum:
Also to note, gtk+ has a system tray icon abstraction class 
GtkStatusIcon, I guess gtk+ emacs maybe should go through that rather 
than implementing the spec from scratch...

http://yettocome.blogspot.com/2007/08/gtk-system-tray-icon-example.html
http://library.gnome.org/devel/gtk/unstable/GtkStatusIcon.html

Re: emacs daemon on win32?

[Juanma Barranquero]

On Tue, Oct 28, 2008 at 17:33, David De La Harpe Golden
<david@harpegolden.net> wrote:

> While I believe the spec is straightforward, I personally won't have time to
> look implementing it in the next few days anyway (tax filing deadline is
> Hallowe'en in Ireland, appropriately enough!), so below find my (trivial)
> design notes.

We're talking about a new feature, so there is no need to hurry. It
won't be in 23.1 anyway.

> I imagined an emacs icon in the systray, clicking left button just opening a
> new frame, right button bringing up a small menu with something like
> Open File...                                            [1]
> New Frame
> New Frame on Display...                                 [2]
> Start Emacs Server [/ Stop Emacs Server]                [3]
> Settings...                                             [4]
> Quit Emacs                                              [5]
>
> I really don't think you'd want more than that on the menu, keep it simple.

Perhaps even simpler.

> Also to note, gtk+ has a system tray icon abstraction class GtkStatusIcon, I guess gtk+ emacs
> maybe should go through that rather than implementing the spec from scratch...

I think the main problem is defining a flexible interface at the
C/elisp level to abstract the differences between OS/X, GNU/Linux and
Windows.

  Juanma

Re: emacs daemon on win32?

[Eli Zaretskii]

> Date: Tue, 28 Oct 2008 18:07:09 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, emacs-devel@gnu.org
> 
> I think the main problem is defining a flexible interface at the
> C/elisp level to abstract the differences between OS/X, GNU/Linux and
> Windows.

Do we need anything beyond 2 APIs: one to minimize to systray, the
other to come back, and perhaps a way to pop up a menu when the icon
is clicked?

Re: emacs daemon on win32?

[Lennart Borgman]

On Tue, Oct 28, 2008 at 7:19 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 28 Oct 2008 18:07:09 +0100
>> From: "Juanma Barranquero" <lekktu@gmail.com>
>> Cc: "Eli Zaretskii" <eliz@gnu.org>, emacs-devel@gnu.org
>>
>> I think the main problem is defining a flexible interface at the
>> C/elisp level to abstract the differences between OS/X, GNU/Linux and
>> Windows.
>
> Do we need anything beyond 2 APIs: one to minimize to systray, the
> other to come back, and perhaps a way to pop up a menu when the icon
> is clicked?

That seems ok to me, but I would rather have add to systray and remove
from systray (+ the menu).

Re: emacs daemon on win32?

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think the main problem is defining a flexible interface at the
>> C/elisp level to abstract the differences between OS/X, GNU/Linux and
>> Windows.
>
> Do we need anything beyond 2 APIs: one to minimize to systray, the
> other to come back, and perhaps a way to pop up a menu when the icon
> is clicked?

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.)

Re: emacs daemon on win32?

[Juanma Barranquero]

On Tue, Oct 28, 2008 at 20:31, Chong Yidong <cyd@stupidchicken.com> 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.

Hmm, no. I don't want to run emacsclient from the icon (or at least,
that wouldn't be my primary mode of interaction with a trayed Emacs).
And it is certainly possible to have menu entries in the icon that
send commands to the server / daemon that do not require it to untray.

  Juanma

Re: emacs daemon on win32?

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Tue, 28 Oct 2008 15:31:23 -0400
> Cc: Juanma Barranquero <lekktu@gmail.com>, david@harpegolden.net,
> 	emacs-devel@gnu.org
> 
> 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.

Maybe on Posix platforms this makes sense; but there's no meaning on
Windows to "start Emacs in daemon mode".

Personally, I don't see much sense in having emacsclient involved in
this, even on Posix platforms.

Re: emacs daemon on win32?

[David De La Harpe Golden]

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...

Re: emacs daemon on win32?

[Chong Yidong]

David De La Harpe Golden <david@harpegolden.net> writes:

>> 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.

The systray application could simply do something like

  emacsclient --eval "(kill-emacs)"

on logout.

The advantage of this is that it can be implemented rather easily.  Not
that I'm going to spend time on this, but I suspect it won't take more
than a day to hack up a usable Gnome applet, which won't need to do
anything but issue a handful of different shell commands.

Re: emacs daemon on win32?

[Juanma Barranquero]

On Tue, Oct 28, 2008 at 19:19, Eli Zaretskii <eliz@gnu.org> wrote:

> Do we need anything beyond 2 APIs: one to minimize to systray, the
> other to come back, and perhaps a way to pop up a menu when the icon
> is clicked?

Yes, a way to pop up a menu would be required, as I expect different
packages could make use of (and modify) the systray app's menu.

There would be necessary to define how would several frames minimize
to the tray, as one single icon (and the menu would allow restoring
only one, for example) or several.

Also, the ability to dynamically change the icon would be useful.

             Juanma

Re: emacs daemon on win32?

[Eli Zaretskii]

> Date: Tue, 28 Oct 2008 13:14:46 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: dhruva <dhruvakm@gmail.com>, emacs-devel@gnu.org
> 
> The cool thing would be to have a Windows Emacs server start as a
> systray app. I'd love for Emacs not to use space in the taskbar, just
> in the tray, until I bring it forward with emacsclient.

That's not --daemon, that's --systray, a different feature which could
be nice for those who, like you, would like Emacs to stay clear of the
desktop.  (I don't share that desire, because I more or less live
inside Emacs, and there's too little space for that in that little
systray icon ;-)

The reason I asked about the sense of having --daemon on Windows is
because Windows, unlike Posix platforms, is not suited well for remote
logins.

Re: emacs daemon on win32?

[Juanma Barranquero]

On Tue, Oct 28, 2008 at 19:18, Eli Zaretskii <eliz@gnu.org> wrote:

> That's not --daemon, that's --systray, a different feature which could
> be nice for those who, like you, would like Emacs to stay clear of the
> desktop.

Well, yes, but there seems to be some synergy between both functionalities.

> (I don't share that desire, because I more or less live
> inside Emacs, and there's too little space for that in that little
> systray icon ;-)

Yeah, it'd be too crowded.

> The reason I asked about the sense of having --daemon on Windows is
> because Windows, unlike Posix platforms, is not suited well for remote
> logins.

I don't see there's a necessary relationship between a daemon and
remote logins...

             Juanma

Re: emacs daemon on win32?

[Eli Zaretskii]

> Date: Tue, 28 Oct 2008 21:05:53 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: dhruvakm@gmail.com, emacs-devel@gnu.org
> 
> > The reason I asked about the sense of having --daemon on Windows is
> > because Windows, unlike Posix platforms, is not suited well for remote
> > logins.
> 
> I don't see there's a necessary relationship between a daemon and
> remote logins...

Then let me ask you: what _is_, in your opinion, the raison d'etre of
the daemon mode?

Re: emacs daemon on win32?

[mail]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 28 Oct 2008 21:05:53 +0100
>> From: "Juanma Barranquero" <lekktu@gmail.com>
>> Cc: dhruvakm@gmail.com, emacs-devel@gnu.org
>> 
>> > The reason I asked about the sense of having --daemon on Windows is
>> > because Windows, unlike Posix platforms, is not suited well for remote
>> > logins.
>> 
>> I don't see there's a necessary relationship between a daemon and
>> remote logins...
>
> Then let me ask you: what _is_, in your opinion, the raison d'etre of
> the daemon mode?
>

Running emacs without a window, so that, when an editor is needed, emacs
can bring up the existing session with approximately zero startup
time. This is especially useful for applications that want to invoke an
editor on some arbitrary file (though you get nearly the same effect by
simply having the window that runs the server minimized all of the
time).

Re: emacs daemon on win32?

[Eli Zaretskii]

> From: mail@justinbogner.com
> Date: Tue, 28 Oct 2008 15:12:33 -0600
> 
> Running emacs without a window, so that, when an editor is needed, emacs
> can bring up the existing session with approximately zero startup
> time.

I don't think this is right, because...

> (though you get nearly the same effect by simply having the window
> that runs the server minimized all of the time).

Exactly!

Re: emacs daemon on win32?

[Juanma Barranquero]

On Tue, Oct 28, 2008 at 21:22, Eli Zaretskii <eliz@gnu.org> wrote:

> Then let me ask you: what _is_, in your opinion, the raison d'etre of
> the daemon mode?

Same that in a Windows service: the system is responsible of starting,
stopping and maintaining the process alive (and dependency
relationships between services).

  Juanma

Re: emacs daemon on win32?

[Eli Zaretskii]

> Date: Tue, 28 Oct 2008 22:27:47 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Tue, Oct 28, 2008 at 21:22, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Then let me ask you: what _is_, in your opinion, the raison d'etre of
> > the daemon mode?
> 
> Same that in a Windows service: the system is responsible of starting,
> stopping and maintaining the process alive (and dependency
> relationships between services).

Unless Emacs is a service and can be started as such, you cannot do
this on Windows (AFAIK) without logging in as one of the users defined
on the particular machine.

Someone else wrote in this thread what I think is the main goal of the
daemon mode: be detached from the process group and so don't get
killed when the user logs out.  And I think this is impossible on
Windows for a normal (non-service) process.

Re: emacs daemon on win32?

[Juanma Barranquero]

On Wed, Oct 29, 2008 at 05:21, Eli Zaretskii <eliz@gnu.org> wrote:

> Unless Emacs is a service and can be started as such, you cannot do
> this on Windows (AFAIK) without logging in as one of the users defined
> on the particular machine.

I suppose I misunderstood your question. My answer was about what I
think is, generally speaking, the raison d'etre of daemon processes.
Specifically for an Emacs daemon, my motivation is not process
control, but Emacs running as quietly and stealthily as possible until
I need it. If that is --systray instead of --daemon, so be it (though
I still think they are related concepts, at least in theory).

> Someone else wrote in this thread what I think is the main goal of the
> daemon mode: be detached from the process group and so don't get
> killed when the user logs out.  And I think this is impossible on
> Windows for a normal (non-service) process.

Though that would be undoubtedly useful, it's not a primary goal for me.

  Juanma