Re: Lazy load of org-protocol

[Jim Porter]

On 2/7/2022 6:57 AM, Max Nikulin wrote:
> > Maybe another option would be to add an --apply argument that really 
> > *does* consume the other command-line args and turns them into a 
> > properly-quoted function call. Roughly speaking, it would turn this:
> >
> >    emacs --apply func foo bar baz
> >
> > into this:
> >
> >    (apply #'func '(foo bar baz))
>
> You have almost managed to sell this idea to me. However even --apply is 
> just sugar for
>
>      emacsclient --eval "(apply #'func command-line-args-left)" --arg 1 2
>
> So it is --apply option that may require to write a dedicated function 
> if --arg is not implemented. Another limitation of --apply is that the 
> function must accept string arguments only, no lists or even integers or 
> boolean.

Yeah, `--arg' does have greater flexibility in that regard, but it comes 
at the cost of verbosity and some slight behavioral differences with the 
equivalent in the main emacs executable. For emacs itself, any elements 
of `command-line-args-left' that aren't consumed by a function will get 
opened as files, but I don't think that would be the case with 
emacsclient. Does this difference matter? Probably not. However, 
avoiding `command-line-args-left' just feels intuitively "cleaner" to 
me. Still, I think `--arg' should work and be backwards-compatible, so I 
don't mind it, even if I prefer the simplicity of `--apply'.

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).

- Jim