bug#72345: 29.4; Emacs daemon on Windows OS

bug#72345: 29.4; Emacs daemon on Windows OS

[Constantin Kulikov]

[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]

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)

[-- Attachment #2: Type: text/html, Size: 2837 bytes --]

bug#72345: 29.4; Emacs daemon on Windows OS

[Constantin Kulikov]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

*> 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@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)
>

[-- Attachment #2: Type: text/html, Size: 789 bytes --]

bug#72345: 29.4; Emacs daemon on Windows OS

[Sebastián Monía]

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

bug#72345: 29.4; Emacs daemon on Windows OS

[Constantin Kulikov]

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

*> 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@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@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)
>>
>

[-- Attachment #2: Type: text/html, Size: 2951 bytes --]

bug#72345: 29.4; Emacs daemon on Windows OS

[Constantin Kulikov]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

*> 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@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@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@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)
>>>
>>

[-- Attachment #2: Type: text/html, Size: 2164 bytes --]

bug#72345: 29.4; Emacs daemon on Windows OS

[Eli Zaretskii]

> From: Constantin Kulikov <zxnotdead@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.

bug#72345: 29.4; Emacs daemon on Windows OS

[Eli Zaretskii]

> Cc: 72345@debbugs.gnu.org, code@sebasmonia.com
> Date: Mon, 29 Jul 2024 15:12:58 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Constantin Kulikov <zxnotdead@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.