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.