GNU bug report logs - #72345
29.4; Emacs daemon on Windows OS

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 72345 in the body.
You can then email your comments to 72345 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Constantin Kulikov <zxnotdead <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.4; Emacs daemon on Windows OS
Date: Mon, 29 Jul 2024 01:08:44 +0300

[Message part 1 (text/plain, inline)]

Trying to use emacs daemon on Windows:

In powershell, cd where emacs is unziped and run it:

```
# .\bin\emacs.exe -q --load D:\path-to-my-init\init.el --daemon
```

I use emacs.exe but it does not matter if I use runemacs.exe here and in
all other commands mentioned in this bugreport, the only difference is
that the emacs process is detached from the terminal.

The first problem was the "server socket" file. It was not created. Then I
tried without loading my init.el:

```
# .\bin\emacs.exe -q --daemon
```

The server file was created in
C:\Users\User\AppData\Roaming\.emacs.d\server

That's ok, but I need it to be in another location. Internet suggests to
set EMACS_SERVER_FILE environment variable, so I set it in powershell
before running emacs:

```
# $env:EMACS_SERVER_FILE = "D:\emacs\.emacs.d\server\server"
```

Seems like it's ignored by emacs. Maybe it's outdated.

Then I tried loading my init.el again, the server file was not created.
I tried starting with --debug, etc. No errors. Then I added
`(server-start)` and other server-* settings to init.el, restarted emacs
and got the server file in the desired location.
Now it is time for emacsclient (emacsclientw makes no difference here):

```
# .\bin\emacsclient.exe -server-file "$(Resolve-Path
'.\.emacs.d\server\server')" -c
```

The frame was created. Success? I'm pressing M-x to enter a command
and... emacs is waiting for input but not in GUI frame but in terminal
where the daemon was started! (runemacs.exe --daemon waits input somewhere
nowhere)
Fail!
(And even the input from terminal is not working properly in that case. You
can enter
string to terminal and it reacts to Enter key press, but seems like
input received by emacs is always nil)


In GNU Emacs 29.4 (build 2, x86_64-w64-mingw32) of 2024-07-05 built on
 AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.20348
System Description: Microsoft Windows Server 2022 Datacenter
(v10.0.2009.20348.1366)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation=aot
 --without-compress-install --with-sqlite3 --with-tree-sitter
 CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

[Message part 2 (text/html, inline)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Constantin Kulikov <zxnotdead <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: 29.4; Emacs daemon on Windows OS
Date: Mon, 29 Jul 2024 03:20:57 +0300

[Message part 1 (text/plain, inline)]

*> input from terminal is not working properly*
Well this is not true. It works with standard read-* methods, and fail if
used with for example ivy-mode.

On Mon, 29 Jul 2024 at 01:08, Constantin Kulikov <zxnotdead <at> gmail.com>
wrote:

> (And even the input from terminal is not working properly in that case.
> You can enter
> string to terminal and it reacts to Enter key press, but seems like
> input received by emacs is always nil)
>

[Message part 2 (text/html, inline)]

Message #11 received at 72345 <at> debbugs.gnu.org (full text, mbox):

From: Sebastián Monía <code <at> sebasmonia.com>
To: Constantin Kulikov <zxnotdead <at> gmail.com>
Cc: 72345 <at> debbugs.gnu.org
Subject: Re: bug#72345: 29.4; Emacs daemon on Windows OS
Date: Sun, 28 Jul 2024 23:43:44 -0400

Hi Constantin,

It has been a long time since I setup the daemon in Windows. I don't use
it anymore.
Some things to try:

>   In powershell, cd where emacs is unziped and run it:
>
>   ```
>   # .\bin\emacs.exe -q --load D:\path-to-my-init\init.el --daemon
>   ```

Can you try this in good old cmd, just in case.

>   Internet suggests to set EMACS_SERVER_FILE environment variable, so
>   I set it in powershell before running emacs:

One suggestion I make to every Windows user, is to setup a HOME
environment variable. A lot of open source software respects its value,
and you can chose something shorter like `C:\home`, much shorter then
%USERPROFILE%. And then all Emacs config and server file etc would be
somewhere under this directory.

Hope this helps,
Sebastián

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Constantin Kulikov <zxnotdead <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org, code <at> sebasmonia.com
Subject: Re: 29.4; Emacs daemon on Windows OS
Date: Mon, 29 Jul 2024 12:28:08 +0300

[Message part 1 (text/plain, inline)]

*> It works with standard read-* methods, and fail if used with for example
ivy-mode.*

This is not true either. I can switch buffer with C-x b, but can not get
help for a function with C-h f .

*> Can you try this in good old cmd*

cmd makes no difference


*> One suggestion I make to every Windows user, is to setup a
HOMEenvironment variable.*

Good suggestion. As for emacs, one can also specify --init-directory in the
command line.

I found the root of the problem. The horrors I described in starting post
happens only if you specify custom command line parameters in emacs
--daemon command, like:

```
# emacs.exe --daemon -myparam test
```

Which can be used in a config like:

```
(let ((myparamcons (member "-myparam" command-line-args)))
    (setq myparam (cadr myparamcons)))
```

If you specify such a command line argument then the server file is not
created by default and if you manually (server-start) from your config then
emacs read-* functions are trying to read input from the terminal. But
interestingly that if you press C-x C-c in emacsclient frame -- then emacs
request to save modified files are handled properly in GUI frame.

So the "solution" is not to specify any custom command line arguments.
I consider it as a bug.


On Mon, 29 Jul 2024 at 03:20, Constantin Kulikov <zxnotdead <at> gmail.com>
wrote:

> *> input from terminal is not working properly*
> Well this is not true. It works with standard read-* methods, and fail if
> used with for example ivy-mode.
>
> On Mon, 29 Jul 2024 at 01:08, Constantin Kulikov <zxnotdead <at> gmail.com>
> wrote:
>
>> (And even the input from terminal is not working properly in that case.
>> You can enter
>> string to terminal and it reacts to Enter key press, but seems like
>> input received by emacs is always nil)
>>
>

[Message part 2 (text/html, inline)]

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Constantin Kulikov <zxnotdead <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: 29.4; Emacs daemon on Windows OS
Date: Mon, 29 Jul 2024 13:52:39 +0300

[Message part 1 (text/plain, inline)]

*> So the "solution" is not to specify any custom command line arguments.*

The actual solution is to remove all custom arguments from the
`command-line-args-left' while config is loading.

Then "THE BUG" is that the emacs daemon silently stays in half-working more
like a hanging state in case if `command-line-args-left' is not nil after
config is loaded.

On Mon, 29 Jul 2024 at 12:28, Constantin Kulikov <zxnotdead <at> gmail.com>
wrote:

> So the "solution" is not to specify any custom command line arguments.
> I consider it as a bug.
>
>
> On Mon, 29 Jul 2024 at 03:20, Constantin Kulikov <zxnotdead <at> gmail.com>
> wrote:
>
>> *> input from terminal is not working properly*
>> Well this is not true. It works with standard read-* methods, and fail if
>> used with for example ivy-mode.
>>
>> On Mon, 29 Jul 2024 at 01:08, Constantin Kulikov <zxnotdead <at> gmail.com>
>> wrote:
>>
>>> (And even the input from terminal is not working properly in that case.
>>> You can enter
>>> string to terminal and it reacts to Enter key press, but seems like
>>> input received by emacs is always nil)
>>>
>>

[Message part 2 (text/html, inline)]

Message #20 received at 72345 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Constantin Kulikov <zxnotdead <at> gmail.com>
Cc: 72345 <at> debbugs.gnu.org, code <at> sebasmonia.com
Subject: Re: bug#72345: 29.4; Emacs daemon on Windows OS
Date: Mon, 29 Jul 2024 15:12:58 +0300

> From: Constantin Kulikov <zxnotdead <at> gmail.com>
> Date: Mon, 29 Jul 2024 12:28:08 +0300
> 
> I found the root of the problem. The horrors I described in starting post happens only if you specify custom
> command line parameters in emacs --daemon command, like:
> 
> ```
> # emacs.exe --daemon -myparam test
> ```
> 
> Which can be used in a config like:
> 
> ```
> (let ((myparamcons (member "-myparam" command-line-args)))
>     (setq myparam (cadr myparamcons)))
> ```
> 
> If you specify such a command line argument then the server file is not created by default and if you manually
> (server-start) from your config then emacs read-* functions are trying to read input from the terminal. But
> interestingly that if you press C-x C-c in emacsclient frame -- then emacs request to save modified files are
> handled properly in GUI frame.
> 
> So the "solution" is not to specify any custom command line arguments.
> I consider it as a bug.

I can reproduce this in Emacs 29, but not on the current emacs-30
release branch, which will eventually become Emacs 30.1.  Emacs 30
refuses to start in this case:

  d:\>emacs --daemon -Q -myparam test
  Starting Emacs daemon.
  Unknown option `-myparam'

  d:\>echo %ERRORLEVEL%
  -1

and after the above, I see no Emacs process running, so it exited with
status -1 after reporting the error.

Thus, I guess we already fixed this bug.

Message #25 received at 72345-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: zxnotdead <at> gmail.com
Cc: 72345-done <at> debbugs.gnu.org, code <at> sebasmonia.com
Subject: Re: bug#72345: 29.4; Emacs daemon on Windows OS
Date: Sat, 24 Aug 2024 11:20:38 +0300

> Cc: 72345 <at> debbugs.gnu.org, code <at> sebasmonia.com
> Date: Mon, 29 Jul 2024 15:12:58 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Constantin Kulikov <zxnotdead <at> gmail.com>
> > Date: Mon, 29 Jul 2024 12:28:08 +0300
> > 
> > I found the root of the problem. The horrors I described in starting post happens only if you specify custom
> > command line parameters in emacs --daemon command, like:
> > 
> > ```
> > # emacs.exe --daemon -myparam test
> > ```
> > 
> > Which can be used in a config like:
> > 
> > ```
> > (let ((myparamcons (member "-myparam" command-line-args)))
> >     (setq myparam (cadr myparamcons)))
> > ```
> > 
> > If you specify such a command line argument then the server file is not created by default and if you manually
> > (server-start) from your config then emacs read-* functions are trying to read input from the terminal. But
> > interestingly that if you press C-x C-c in emacsclient frame -- then emacs request to save modified files are
> > handled properly in GUI frame.
> > 
> > So the "solution" is not to specify any custom command line arguments.
> > I consider it as a bug.
> 
> I can reproduce this in Emacs 29, but not on the current emacs-30
> release branch, which will eventually become Emacs 30.1.  Emacs 30
> refuses to start in this case:
> 
>   d:\>emacs --daemon -Q -myparam test
>   Starting Emacs daemon.
>   Unknown option `-myparam'
> 
>   d:\>echo %ERRORLEVEL%
>   -1
> 
> and after the above, I see no Emacs process running, so it exited with
> status -1 after reporting the error.
> 
> Thus, I guess we already fixed this bug.

No further comments within 3 weeks, so I presume this bug was indeed
fixed, and I'm therefore closing it.

Previous Next

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