Re: Lazy load of org-protocol

[Max Nikulin]

On 06/02/2022 09:40, Tianshu Wang wrote:
> (defadvice server-execute (before enable-org-protocol activate)
>   (unless (featurep 'org-protocol) (require 'org-protocol)))
Thank you, such approach, unlike mine example, does not have code 
duplication. On the other hand it loads org-protocol on any remote 
command, not only for "files" representing org-protocol URIs. Maybe 
defadvice in org-protocol.el should be changed by newer advice-add with 
a function containing body of the old advice.
On 07/02/2022 02:40, Jim Porter wrote:
> On 2/6/2022 8:42 AM, Max Nikulin wrote:
> > On 06/02/2022 01:27, Jim Porter wrote:
> > I think, the solution is to add -arg command to emacs server protocol 
> > that pushes its argument to a list and extend -exec command that would 
> > make such list available as argv or as `command-line-args-left' for 
> > evaluated expression. Of course, emacsclient option parser should be 
> > modified as well to support --arg option
> >       emacsclient --eval '(func)' --arg 1 2 3
> >       emacsclient --eval '(func)' --arg -- 1 2 3
> > and maybe even for multiple eval+arg pairs
> >       emacsclient --eval '(f1)' --arg 'a1' --eval '(f2)' --arg 'a2' 'a3'
> I think something like this could work, so long as the arguments can be 
> forwarded correctly in the alternate editor case. If I understand how 
> emacsclient handles --eval, I think that might work, but it would still 
> require writing Lisp functions that know how to handle argv or 
> `command-line-args-left'. I'm also not totally sure how safe/sensible 
> that is when the arguments aren't from the invocation of emacs itself, 
> but from emacsclient (and thus, the args could be updated multiple times 
> throughout a session). It probably wouldn't actually break anything, but 
> it does seem a bit surprising to me...
Of course, I mean let-bind of `argv' and `command-line-args-left' just 
for processing of the passed expression, not setq that would change them 
globally.
> 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.
> This would work effectively like how I momentarily thought --funcall 
> works. Then you could say:
>    emacsclient --apply org-protocol-capture %u
>    # or ...
>    emacs --apply org-protocol-capture %u
Just because of there were a couple of recent threads related to calling 
conventions for subprotocol handlers, it is better to provide a bit more 
"real" example
    emacsclient --eval '(org-protocol-check-filename-for-protocol (pop 
command-line-args-left) nil nil)' --args %u