From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Lazy load of org-protocol
Date: Mon, 7 Feb 2022 21:57:09 +0700 [thread overview]
Message-ID: <strc07$3o0$1@ciao.gmane.io> (raw)
In-Reply-To: <62519b3f-d1fa-4497-e32f-2a0960c4d1fe@gmail.com>
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
next prev parent reply other threads:[~2022-02-07 15:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-05 11:54 Lazy load of org-protocol Max Nikulin
2022-02-05 18:27 ` Jim Porter
2022-02-06 16:42 ` Max Nikulin
2022-02-06 19:40 ` Jim Porter
2022-02-07 14:57 ` Max Nikulin [this message]
2022-02-07 19:06 ` Jim Porter
2022-02-09 16:46 ` Max Nikulin
2022-02-09 19:22 ` Jim Porter
2022-02-10 14:44 ` Max Nikulin
2022-02-08 10:44 ` Emacs-orgmode Digest, Vol 192, Issue 8 Tianshu Wang
[not found] <mailman.61.1644253327.32758.emacs-orgmode@gnu.org>
2022-02-08 19:02 ` [PATCH] lisp/org-capture.el: Add hook & hook options to org-capture (Valentin Herrmann) No Wayman
2022-02-09 4:10 ` Ihor Radchenko
2022-02-09 7:11 ` No Wayman
2022-03-20 10:43 ` Ihor Radchenko
2022-02-10 19:32 ` Greg Minshall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='strc07$3o0$1@ciao.gmane.io' \
--to=manikulin@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).