emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jim Porter <jporterbugs@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Lazy load of org-protocol
Date: Mon, 7 Feb 2022 11:06:48 -0800	[thread overview]
Message-ID: <450a25ba-e1f5-16db-c953-92fef0bfdc1a@gmail.com> (raw)
In-Reply-To: <strc07$3o0$1@ciao.gmane.io>

On 2/7/2022 6:57 AM, Max Nikulin wrote:
>> 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.

Yeah, `--arg' does have greater flexibility in that regard, but it comes 
at the cost of verbosity and some slight behavioral differences with the 
equivalent in the main emacs executable. For emacs itself, any elements 
of `command-line-args-left' that aren't consumed by a function will get 
opened as files, but I don't think that would be the case with 
emacsclient. Does this difference matter? Probably not. However, 
avoiding `command-line-args-left' just feels intuitively "cleaner" to 
me. Still, I think `--arg' should work and be backwards-compatible, so I 
don't mind it, even if I prefer the simplicity of `--apply'.

On a related note, there is still an issue with `--eval' in some cases. 
It fails to work with emacsclient when invoking an alternate editor:

   emacsclient --alternate-editor emacs --eval '(message "hi")'

If Emacs isn't already running, that will open a new buffer named 
'(message "hi")'. I think that's just a bug in how emacsclient handles 
`--eval', though fixing it would make org-protocol links work more 
reliably (if they used `--eval' as proposed, that is).

- Jim

  reply	other threads:[~2022-02-07 19: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
2022-02-07 19:06         ` Jim Porter [this message]
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:

  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=450a25ba-e1f5-16db-c953-92fef0bfdc1a@gmail.com \
    --to=jporterbugs@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* 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


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