On 10/02/2022 02:22, Jim Porter wrote:
On 2/9/2022 8:46 AM, Max Nikulin wrote:
On a related note, there is still an issue with `--eval' in some
cases. It fails to work with emacsclient when invoking an alternate
editor:
emacsclient --alternate-editor emacs --eval '(message "hi")'
If Emacs isn't already running, that will open a new buffer named
'(message "hi")'. I think that's just a bug in how emacsclient
handles `--eval', though fixing it would make org-protocol links work
more reliably (if they used `--eval' as proposed, that is).
emacsclient --alternate-editor '' --eval '(message "hi")'
But it makes it harder to use it during debugging when -Q -L
~/src/org-mode/lisp options are required.
Right, invoking the main Emacs instance as a daemon (i.e. when
--alternate-editor is the empty string) works pretty differently from
invoking the main Emacs instance directly (i.e. when --alternate-editor
is "emacs" or somesuch). In the former case, emacsclient starts "emacs
--daemon" and then tries to reconnect to the daemon; in the latter, it
just takes the arguments passed to emacsclient and forwards them (well,
some of them) to emacs. The end result is that it runs "emacs '(message
"hi")'", which isn't correct.
It looks like a bug. I believed that other application may be specified
as --alternate-editor, so --eval arguments should not be passed to it.
Actually I do not like --alternate-editor option at all. It is a single
string, not an array of executable and options. It allows quotes but
does not support escaping.
On linux a solution is to start emacs daemon from systemd session as a
socket-activated application.
