From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Lazy load of org-protocol
Date: Wed, 9 Feb 2022 23:46:26 +0700 [thread overview]
Message-ID: <su0r54$f42$1@ciao.gmane.io> (raw)
In-Reply-To: <450a25ba-e1f5-16db-c953-92fef0bfdc1a@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3869 bytes --]
On 08/02/2022 17:44, Tianshu Wang wrote:
> Max Nikulin writes:
>
>> 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.
>
> Yes, I replaced the original code with advice-add (not fully tested).
Sorry, I was not clear enough. I meant a patch similar to the attached
one. It is not tested for greedy subprotocols. It allows to check
arguments to decide if it is necessary to load org-protocol:
(defun org-protocol-lazy-load (args)
(if (or (featurep 'org-protocol)
(not (delq nil
(mapcar (lambda (loc)
;; loc: (file-name . (line . column))
(string-match-p "\\(?:^\\|[/\\\\]\\)org-protocol:" (car loc)))
(car args)))))
args
(require 'org-protocol)
(org-protocol-detect-protocol-server args)))
(server-start)
(advice-add 'server-visit-files :filter-args #'org-protocol-lazy-load)
On 08/02/2022 02:06, Jim Porter wrote:
> 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'.
It is not a problem to implement --apply in addition to --arg. It may
just mean
--eval '(apply-from-command-line-args-left)'
emacs --batch -l apply-from-command-line-args-left.el \
--eval '(apply-from-command-line-args-left)' \
message 'test %S, %S' Hello 'World!'
(defun apply-from-command-line-args-left ()
(let* ((name (car command-line-args-left))
(func (symbol-function (intern name))))
(if func
(apply func (cdr command-line-args-left))
(error (format "Symbol's function definition is void: %s" name)))))
OK, I forgot to set the variable to nil.
> 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).
emacsclient --alternate-editor '' --eval '(message "hi")'
But it makes it harder to use it during debugging when -Q -L
~/src/org-mode/lisp options are required.
[-- Attachment #2: 0001-org-protocol.el-New-style-advice.patch --]
[-- Type: text/x-patch, Size: 2217 bytes --]
From 8a4f8db239d004513be35249ed71e222381b0162 Mon Sep 17 00:00:00 2001
From: Max Nikulin <manikulin@gmail.com>
Date: Wed, 9 Feb 2022 23:25:28 +0700
Subject: [PATCH] org-protocol.el: New-style advice
lisp/org-protocol.el (org-protocol-detect-protocol-server): Use
`advice-add' instead of deprecated `defadvice'.
Advice as a function allows to call it from another similar advice
loading `org-protocol' on demand.
---
lisp/org-protocol.el | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el
index 7c4de03bc..fb41e3c0f 100644
--- a/lisp/org-protocol.el
+++ b/lisp/org-protocol.el
@@ -687,25 +687,29 @@ to deal with new-style links.")
(throw 'fname t))))))))
fname)))
-(defadvice server-visit-files (before org-protocol-detect-protocol-server activate)
+(defun org-protocol-detect-protocol-server (args)
"Advice server-visit-flist to call `org-protocol-modify-filename-for-protocol'."
- (let ((flist (if org-protocol-reverse-list-of-files
- (reverse (ad-get-arg 0))
- (ad-get-arg 0)))
- (client (ad-get-arg 1)))
+ (let* ((files (nth 0 args))
+ (client (nth 1 args))
+ (flist (if org-protocol-reverse-list-of-files
+ (reverse files)
+ files)))
(catch 'greedy
(dolist (var flist)
;; `\' to `/' on windows. FIXME: could this be done any better?
(let ((fname (expand-file-name (car var))))
(setq fname (org-protocol-check-filename-for-protocol
- fname (member var flist) client))
+ fname (member var flist) client))
(if (eq fname t) ;; greedy? We need the t return value.
(progn
- (ad-set-arg 0 nil)
+ (setcar args nil)
(throw 'greedy t))
(if (stringp fname) ;; probably filename
(setcar var fname)
- (ad-set-arg 0 (delq var (ad-get-arg 0))))))))))
+ (setcar args (delq var files))))))))
+ args)
+
+(advice-add 'server-visit-files :filter-args #'org-protocol-detect-protocol-server)
;;; Org specific functions:
--
2.25.1
next prev parent reply other threads:[~2022-02-09 16:48 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
2022-02-09 16:46 ` Max Nikulin [this message]
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='su0r54$f42$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).