Re: Lazy load of org-protocol

[Max Nikulin <manikulin@gmail.com>]

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.