On 2/9/2022 8:46 AM, Max Nikulin wrote:
It is not a problem to implement --apply in addition to --arg.
[snip]
For the purposes of this issue, I think either solution would probably
work. It probably depends on what people think on emacs-devel.
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'd be nice to fix the behavior of "--alternate-editor emacs" so it
passes the --eval flag along too. This might be tricky though, since the
semantics of --eval aren't quite the same for emacs and emacsclient. For
emacs, --eval means that just the next argument is Lisp code; for
emacsclient, --eval means that *all* subsequent (positional) arguments
are Lisp code.
In practice though, I don't think fixing this is actually *required* to
fix the issue of how org-protocol is handled. It only causes issues for
the subset of people who use "--alternate-editor emacs" or something
similar.
- Jim
