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