emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jim Porter <jporterbugs@gmail.com>
To: Max Nikulin <manikulin@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: Lazy load of org-protocol
Date: Sat, 5 Feb 2022 10:27:27 -0800	[thread overview]
Message-ID: <9b140f0a-c75e-cf00-0f83-67e5a660935c@gmail.com> (raw)
In-Reply-To: <stlohv$17d8$1@ciao.gmane.io>

On 2/5/2022 3:54 AM, Max Nikulin wrote:
> I would prefer to avoid
>     (require 'org-protocol)
> in emacs init file and to postpone loading till invocation of 
> emacsclient with org-protocol URI.
> 
> The problem is a hack in org-protocol. URIs are actually treated as 
> (relative) file names and magic is achieved in an advice for 
> `server-visit-files' function. So the advice must be installed in advance.
> 
> My first idea was to avoid such magic and to create autoload function 
> org-protocol-from-argv with body similar to that advice. If it were 
> possible to get arguments from `command-line-args-left' then invocation 
> would look like
> 
>     emacsclient --eval '(org-protocol-from-argv)' 
> 'org-protocol:/store-link?url=u1&title=t1'
> 
> Unfortunately it is against design of emacs server protocol. If --eval 
> option is given than everything other is considered as independent 
> expressions. At the lower level there is no way to transfer `argv` as a 
> list from client to server process.

I've thought a bit about how to improve this too. One further issue with 
the current implementation is that when emacsclient invokes the 
alternate editor (usually to start the "main" emacs instance), 
org-protocol: links no longer work correctly. That's because only the 
emacsclient itself (through `server-visit-files') knows what to do with 
them.

I think the problem really starts in emacsclient's command line 
handling. You can see this in other situations too. For example, Emacs 
can be configured as your system's mailto: URL handler. (The file 
etc/emacsclient-mail.desktop in the Emacs repo does this.) The command 
to use for a new Emacs instance is simple:

   emacs -f message-mailto %u

However, doing this for emacsclient is harder:

   emacsclient --alternate-editor= --create-frame --eval 
"(message-mailto \\"%u\\")"

There's no problem with "--alternate-editor=" and "--create-frame", but 
the fact that emacsclient requires evaling the function call that way 
is: if %u holds a string with quotation marks, this will break, and 
worse, could even result in arbitrary code being executed. (In practice, 
this is probably rare, since URLs are generally URL-encoded, and so 
don't have literal quotes in them.)

As a result, I think a good first step might be to add support for 
"--funcall" to emacsclient, just like the regular emacs binary. (The 
"-f" shorthand won't work though, since emacsclient already uses that 
for "--server-file"). This would simplify the `message-mailto' case 
above and would also allow org-protocol to do something similar:

   emacsclient --funcall org-protocol-capture %u

Then, so long as `org-protocol-capture' has an autoload, this would Just 
Work, and org-protocol.el would be lazily loaded. Hopefully, this could 
also be forwarded onto the alternate editor so that when the user open 
an org-protocol: URL when Emacs is closed, it still handles the URL 
correctly.

That said, in the short term, you could try out something like:

   emacsclient --eval "(org-protocol-capture \\"%u\\")"

Of course, that has the quoting issues I mentioned above, but it could 
be helpful for developing a proof of concept.

- Jim


  reply	other threads:[~2022-02-05 18:28 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 [this message]
2022-02-06 16:42   ` Max Nikulin
2022-02-06 19:40     ` Jim Porter
2022-02-07 14:57       ` Max Nikulin
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=9b140f0a-c75e-cf00-0f83-67e5a660935c@gmail.com \
    --to=jporterbugs@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \
    /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).