[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
- Lazy load of org-protocol, Max Nikulin, 2022/02/05
- Re: Lazy load of org-protocol, Jim Porter, 2022/02/05
- Re: Lazy load of org-protocol, Max Nikulin, 2022/02/06
- Re: Lazy load of org-protocol, Jim Porter, 2022/02/06
- Re: Lazy load of org-protocol,
Max Nikulin <=
- Re: Lazy load of org-protocol, Jim Porter, 2022/02/07
- Re: Lazy load of org-protocol, Max Nikulin, 2022/02/09
- Re: Lazy load of org-protocol, Jim Porter, 2022/02/09
- Re: Lazy load of org-protocol, Max Nikulin, 2022/02/10
- Re: Emacs-orgmode Digest, Vol 192, Issue 8, Tianshu Wang, 2022/02/08