[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lazy load of org-protocol

From: Max Nikulin
Subject: Re: Lazy load of org-protocol
Date: Mon, 7 Feb 2022 21:57:09 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]