Re: Lazy load of org-protocol

[Max Nikulin]

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.

0001-org-protocol.el-New-style-advice.patch
Description: Text Data