GNU bug report logs -
#72345
29.4; Emacs daemon on Windows OS
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sat, 24 Aug 2024 11:20:38 +0300
with message-id <86seuunxgp.fsf <at> gnu.org>
and subject line Re: bug#72345: 29.4; Emacs daemon on Windows OS
has caused the debbugs.gnu.org bug report #72345,
regarding 29.4; Emacs daemon on Windows OS
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
72345: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=72345
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (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 4 (text/html, inline)]
[Message part 5 (message/rfc822, inline)]
> 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.
This bug report was last modified 322 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.