emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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



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