GNU bug report logs - #19688
[patch] add support for emacs daemon on Windows

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mark Laws <mdl <at> 60hz.org>
Cc: 19688 <at> debbugs.gnu.org
Subject: bug#19688: [patch] add support for emacs daemon on Windows
Date: Sat, 14 Feb 2015 18:53:31 +0200

> Date: Sun, 15 Feb 2015 01:34:48 +0900
> From: Mark Laws <mdl <at> 60hz.org>
> Cc: 19688 <at> debbugs.gnu.org
> 
> I gave it a try, but it doesn't work--most likely because, as you
> said, Emacs is built as a console application, so WaitForInputIdle
> simply returns immediately because of the race between emacsclient
> attempting to wait on Emacs and Emacs establishing a Windows message
> queue.

No, I think it returns immediately, period.  As I wrote, when Emacs
establishes the input queue, it's already way past the daemon
initialization.

> So, the options are either using an event or modifying Emacs to
> run under the Windows subsystem--I don't think I need to tell you
> which one is the less invasive change. :)

The latter is not invasive, it simply cannot be done without losing
some very valuable features.  So it's out of the question.

Back to the event-based method: is using a named event with a fixed
name workable?  That is, is a situation imaginable where we would need
more than one event at the same time on the same system?

If a single event is enough, I think a named event with a name
specific to Emacs (but not a GUID) is a better alternative.
Otherwise, we will have to pass the handle via the command line; using
the environment is not an idea I like, because it means complications:
possible conflict with other variables, possible overflow of the 32K
limit on environment variables, possible conflicts in nested
invocations, etc.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.