bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Damien Cassou]

Hi,

The file emacsclient-mail.desktop that is provided by Emacs (see below
for an excerpt) doesn't seem to work for me. I would like mailto: links
in the web browser to open with emacsclient but nothing happens. How to
reproduce:

1. start the Emacs daemon (if not already done)

2. go to
https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg00320.html in
a non-Emacs web browser

3. click the "Eli Zaretskii" button after "reply via email to"

Expected: An Emacs client frame appears with a buffer in message mode
Actual: Nothing happens

If you try to reproduce and you get a different application opening to
compose your email, you might want to add the following to
~/.config/mimeapps.list:

  [Default Applications]
  x-scheme-handler/mailto=emacsclient-mail.desktop

It feels like launching my web browser from the terminal sometimes makes
it work, but that's not really reliable.

The freedesktop Desktop Entry Specification [1] contains:

  Field codes must not be used inside a quoted argument, the result of
  field code expansion inside a quoted argument is undefined.

It seems to me that the .desktop file Emacs provides does just that: use
a field code (%u) inside a quoted argument. I might be wrong in the
interpretation of the spec though as the next sentence in the spec seems
to contradict this interpretation.

Anyway, I found a way to always have it working:

1. create a file emacs-compose-email.sh that starts emacsclient
2. add the executable bit to the file
3. reference the shell script from emacsclient-mail.desktop

See below for the script and .desktop file. Another advantage of this
approach is that the desktop file becomes much simpler with much less
backslashes.

My question is: do you want a patch with this change?

emacs-compose-email.sh:
  #!/usr/bin/env bash
  emacsclient --alternate-editor= --eval "(message-mailto \"$1\")"

Working emacsclient-mail.desktop:
  [Desktop Entry]
  Exec=emacs-compose-email.sh %u
  MimeType=x-scheme-handler/mailto
  Name=Emacs (Mail, Client)
  NoDisplay=true
  Terminal=false
  Type=Application
  Version=1.4

Excerpt of the existing (non-working) emacsclient-mail.desktop:
  [Desktop Entry]
  Exec=sh -c "exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" --eval \\\\(message-mailto\\\\ \\\\\\"%u\\\\\\"\\\\)"
  Name=Emacs (Mail, Client)
  MimeType=x-scheme-handler/mailto;
  Actions=new-window;new-instance;
  
  [Desktop Action new-window]
  Name=New Window
  Exec=emacsclient --alternate-editor= --create-frame --eval "(message-mailto \\"%u\\")"
  
  [Desktop Action new-instance]
  Name=New Instance
  Exec=emacs -f message-mailto %u

[1]: https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Lars Ingebrigtsen]

Damien Cassou <damien@cassou.me> writes:

> Anyway, I found a way to always have it working:
>
> 1. create a file emacs-compose-email.sh that starts emacsclient
> 2. add the executable bit to the file
> 3. reference the shell script from emacsclient-mail.desktop
>
> See below for the script and .desktop file. Another advantage of this
> approach is that the desktop file becomes much simpler with much less
> backslashes.
>
> My question is: do you want a patch with this change?

I'd prefer to have a .desktop file that works without any helper
scripts.   Can't the emacsclient-mail.desktop file be rewritten to not
use quoting here?

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Damien Cassou]

Lars Ingebrigtsen <larsi@gnus.org> writes:
> I'd prefer to have a .desktop file that works without any helper
> scripts.   Can't the emacsclient-mail.desktop file be rewritten to not
> use quoting here?

This is maybe possible but I haven't found a way. Moreover, the
constraints that "Field codes must not be used inside a quoted argument"
makes things more complex. One way we could maybe implement this is if
it was possible to pass additional CLI arguments to emacsclient and read
them from elisp the same way it is possible in batch mode with emacs.

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Eli Zaretskii]

> Cc: Peter Oliver <git@mavit.org.uk>, 57752@debbugs.gnu.org
> From: Damien Cassou <damien@cassou.me>
> Date: Tue, 13 Sep 2022 15:29:10 +0200
> 
> One way we could maybe implement this is if
> it was possible to pass additional CLI arguments to emacsclient and read
> them from elisp the same way it is possible in batch mode with emacs.

You mean, by using --eval from the emacsclient command line?

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Damien Cassou]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Damien Cassou <damien@cassou.me>
>> One way we could maybe implement this is if
>> it was possible to pass additional CLI arguments to emacsclient and read
>> them from elisp the same way it is possible in batch mode with emacs.
>
> You mean, by using --eval from the emacsclient command line?

no because --eval would require a valid elisp expression such as

  emacsclient --eval (message-mailto "%u")

which seems to go against the specification constraint. I thought about
using something like the following:

  emacsclient --function message-mailto-reading-cli-args %u

And message-mailto-reading-cli-args would read command-line-args-left or
similar to do its job.

This requires adding these features to emacsclient and implementing
message-mailto-reading-cli-args.

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Robert Pluim]

>>>>> On Tue, 13 Sep 2022 15:58:06 +0200, Damien Cassou <damien@cassou.me> said:
    Damien> which seems to go against the specification constraint. I thought about
    Damien> using something like the following:

    Damien>   emacsclient --function message-mailto-reading-cli-args %u

    Damien> And message-mailto-reading-cli-args would read command-line-args-left or
    Damien> similar to do its job.

    Damien> This requires adding these features to emacsclient and implementing
    Damien> message-mailto-reading-cli-args.

`message-mailto' already looks at `command-line-args-left' (and has
done so for quite some time), so all we need is the '-f <function'
bit, which would be a nice addition.

Robert
-- 

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Damien Cassou]

Robert Pluim <rpluim@gmail.com> writes:
> `message-mailto' already looks at `command-line-args-left' (and has
> done so for quite some time), so all we need is the '-f <function'
> bit, which would be a nice addition.

Excellent news, I should have checked! Thank you.

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Jim Porter]

On 9/13/2022 6:58 AM, Damien Cassou wrote:
> no because --eval would require a valid elisp expression such as
> 
>    emacsclient --eval (message-mailto "%u")
> 
> which seems to go against the specification constraint. I thought about
> using something like the following:
> 
>    emacsclient --function message-mailto-reading-cli-args %u

I agree that this would be a useful feature. Org Mode could also benefit 
from it (and probably some other places too). See 
https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00056.html

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Lars Ingebrigtsen]

Jim Porter <jporterbugs@gmail.com> writes:

>> no because --eval would require a valid elisp expression such as
>>    emacsclient --eval (message-mailto "%u")
>> which seems to go against the specification constraint. I thought
>> about
>> using something like the following:
>>    emacsclient --function message-mailto-reading-cli-args %u
>
> I agree that this would be a useful feature. Org Mode could also
> benefit from it (and probably some other places too). See
> https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00056.html

I've idly wondered before whether we should add a general mechanism for
this to avoid having to create functions that look at
`command-line-args-left' themselves.  (And --eval is problematic in
circumstances like this.)

So something like

--function foo --function-args bar zot gazonk

would result in calling `foo' with those arguments.

Hm...  would we need some way to say "here's the end of
--function-args", perhaps?  "--"?  So:

--function foo --function-args bar zot gazonk --

Anybody have any thoughts here?

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Robert Pluim]

>>>>> On Fri, 16 Sep 2022 11:54:22 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> I've idly wondered before whether we should add a general mechanism for
    Lars> this to avoid having to create functions that look at
    Lars> `command-line-args-left' themselves.  (And --eval is problematic in
    Lars> circumstances like this.)

emacsclient interprets

    emacsclient arg1 arg2 --eval (form1) (form2) (form3)

as "send (form1), then (form2) then (form3), so by analogy this:

    Lars> --function foo --function-args bar zot gazonk

doesnʼt require a --function-args parameter

    Lars> would result in calling `foo' with those arguments.

    Lars> Hm...  would we need some way to say "here's the end of
    Lars> --function-args", perhaps?  "--"?  So:

and this also isnʼt necessary, since the end of args is implicit by
reaching the end of the arguments, same as '--eval'

    Lars> --function foo --function-args bar zot gazonk --

    Lars> Anybody have any thoughts here?

I idly wondered whether emacsclient could create a monster ʼ--evalʼ
form with a binding for `command-line-args-left', but then I started
having nightmares about string handling in C, so perhaps itʼs best to
just send stuff over to emacs and let server.el handle it :-)

Robert
-- 

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

>     Lars> I've idly wondered before whether we should add a general
>     Lars> mechanism for
>     Lars> this to avoid having to create functions that look at
>     Lars> `command-line-args-left' themselves.  (And --eval is problematic in
>     Lars> circumstances like this.)
>
> emacsclient interprets
>
>     emacsclient arg1 arg2 --eval (form1) (form2) (form3)
>
> as "send (form1), then (form2) then (form3), so by analogy this:
>
>     Lars> --function foo --function-args bar zot gazonk
>
> doesnʼt require a --function-args parameter

I was thinking first and foremost about on the Emacs side, not on the
emacsside client.  But if then Emacs had --function-args, then by
analogy, emacsclient should also have it.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Damien Cassou]

Robert Pluim <rpluim@gmail.com> writes:
>     Lars> Hm...  would we need some way to say "here's the end of
>     Lars> --function-args", perhaps?  "--"?  So:
>
> and this also isnʼt necessary, since the end of args is implicit by
> reaching the end of the arguments, same as '--eval'


does it mean emacsclient will never be able to execute more than
one function at a time?

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Gregory Heytings]

>
> does it mean emacsclient will never be able to execute more than one 
> function at a time?
>

I'm not sure what you want to do, but you can use an arbitrarily complex 
form in eval, with as many function calls as you want, for example:

emacsclient --eval '(progn (foo) (bar) (baz) (zot))'

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Robert Pluim]

>>>>> On Fri, 16 Sep 2022 12:14:33 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    Lars> I've idly wondered before whether we should add a general
    Lars> mechanism for
    Lars> this to avoid having to create functions that look at
    Lars> `command-line-args-left' themselves.  (And --eval is problematic in
    Lars> circumstances like this.)
    >> 
    >> emacsclient interprets
    >> 
    >> emacsclient arg1 arg2 --eval (form1) (form2) (form3)
    >> 
    >> as "send (form1), then (form2) then (form3), so by analogy this:
    >> 
    Lars> --function foo --function-args bar zot gazonk
    >> 
    >> doesnʼt require a --function-args parameter

    Lars> I was thinking first and foremost about on the Emacs side, not on the
    Lars> emacsside client.  But if then Emacs had --function-args, then by
    Lars> analogy, emacsclient should also have it.

Wouldnʼt it be easier to define a macro to do the
`command-line-args-left' handling on behalf of a defun? That macro
would then consume any args up to the next arg starting with '-', so
you could do

emacs --function foo arg1 arg2 arg3 --function bar arg4 arg5 arg6

There are also quoting and conversion issues to think about, eg:

emacs --function foo hello 3 indent-tabs-mode 'always

Do we make people say

"hello" if they want strings, which implies that indent-tabs-mode
would be treated as a variable, 3 as a number, and the ' needs to be
escaped somehow?

Robert
-- 

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Robert Pluim]

>>>>> On Fri, 16 Sep 2022 14:38:46 +0200, Damien Cassou <damien@cassou.me> said:

    Damien> Robert Pluim <rpluim@gmail.com> writes:
    Lars> Hm...  would we need some way to say "here's the end of
    Lars> --function-args", perhaps?  "--"?  So:
    >> 
    >> and this also isnʼt necessary, since the end of args is implicit by
    >> reaching the end of the arguments, same as '--eval'


    Damien> does it mean emacsclient will never be able to execute more than
    Damien> one function at a time?

Hmm, thatʼs a good point. May have the next argument starting with a
ʼ-ʼ implicitly end the arglist, so you could do ʼ--functionʼ again?

Robert
-- 

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Damien Cassou]

Gregory Heytings <gregory@heytings.org> writes:
> I'm not sure what you want to do

emacsclient \
  --function fun1 --function-args arg1 arg2 \
  --function fun2 --function-args arg3

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Damien Cassou]

Robert Pluim <rpluim@gmail.com> writes:
> Hmm, thatʼs a good point. May have the next argument starting with a
> ʼ-ʼ implicitly end the arglist, so you could do ʼ--functionʼ again?

I think the suggestion of Lars using ʼ--ʼ was clearer and is also
aligned with other commands I often use.

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Gregory Heytings]

>> I'm not sure what you want to do
>
> emacsclient \
>  --function fun1 --function-args arg1 arg2 \
>  --function fun2 --function-args arg3
>

But emacsclient doesn't have a --function / --function-args parameter? 
And why is the above easier / better than

emacsclient --eval '(progn (fun1 arg1 arg2) (fun2 arg3))'

?

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Jim Porter]

On 9/16/2022 2:54 AM, Lars Ingebrigtsen wrote:
> I've idly wondered before whether we should add a general mechanism for
> this to avoid having to create functions that look at
> `command-line-args-left' themselves.  (And --eval is problematic in
> circumstances like this.)
> 
> So something like
> 
> --function foo --function-args bar zot gazonk
> 
> would result in calling `foo' with those arguments.
> 
> Hm...  would we need some way to say "here's the end of
> --function-args", perhaps?  "--"?  So:
> 
> --function foo --function-args bar zot gazonk --
> 
> Anybody have any thoughts here?

I have two thoughts:

1) Instead of specifying the function args with a flag, I think I'd go 
the other way and specify the function as being special, e.g.:

   emacs --apply func arg1 arg2

2) Even better, why not just use --function and pass some higher-order 
function:

   emacs --function apply-from-command-line func arg1 arg2

That way, it's easy to substitute in some other higher-order function if 
you want. emacsclient would still need to add a --function flag though, 
and probably some changes to how it forwards arguments to the main emacs 
so that you can do stuff like this.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Jim Porter]

On 9/16/2022 7:18 AM, Robert Pluim wrote:
> There are also quoting and conversion issues to think about, eg:
> 
> emacs --function foo hello 3 indent-tabs-mode 'always
> 
> Do we make people say
> 
> "hello" if they want strings, which implies that indent-tabs-mode
> would be treated as a variable, 3 as a number, and the ' needs to be
> escaped somehow?

Hopefully not, since one of the goals here is to be able to accept 
arbitrary strings from other programs (e.g. your mailto: handler). If we 
required strings to look "like this", then it becomes much more 
difficult to ensure that internal quotation marks are properly escaped.

Instead, I think the arguments passed this way should always be strings. 
If you need something fancier, --eval can step in. (Of course, a 
function called with --function can convert its arguments however it likes.)

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Peter Oliver]

On Fri, 16 Sep 2022, Gregory Heytings wrote:

> And why is the above easier / better than
>
> emacsclient --eval '(progn (fun1 arg1 arg2) (fun2 arg3))'

Because, with this, you have to correctly format the arguments with appropriate quoting into a lisp program, rather than just passing them straight in.  If the arguments are input from something else, this is harder than it appears.  Bad quoting is a common source of bugs (things like SQL injection, for example).

-- 
Peter Oliver

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Gregory Heytings]

>> And why is the above easier / better than
>> 
>> emacsclient --eval '(progn (fun1 arg1 arg2) (fun2 arg3))'
>
> Because, with this, you have to correctly format the arguments with 
> appropriate quoting into a lisp program, rather than just passing them 
> straight in.  If the arguments are input from something else, this is 
> harder than it appears.  Bad quoting is a common source of bugs (things 
> like SQL injection, for example).
>

If that's the intended use case, IMO instead of adding two --function and 
--function-arg arguments it would be much clearer to add a --setq 
parameter:

emacsclient --setq arg1 ... --setq arg2 ... --setq arg3 ... --eval '(progn (fun1 arg1 arg2) (fun2 arg3))'

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Jim Porter]

On 9/16/2022 9:42 AM, Gregory Heytings wrote:
>>> And why is the above easier / better than
>>>
>>> emacsclient --eval '(progn (fun1 arg1 arg2) (fun2 arg3))'
>>
>> Because, with this, you have to correctly format the arguments with 
>> appropriate quoting into a lisp program, rather than just passing them 
>> straight in.  If the arguments are input from something else, this is 
>> harder than it appears.  Bad quoting is a common source of bugs 
>> (things like SQL injection, for example).
>>
> 
> If that's the intended use case, IMO instead of adding two --function 
> and --function-arg arguments it would be much clearer to add a --setq 
> parameter:
> 
> emacsclient --setq arg1 ... --setq arg2 ... --setq arg3 ... --eval 
> '(progn (fun1 arg1 arg2) (fun2 arg3))'

I'm not convinced that '--function-arg' is necessary, but I do think 
that adding '--function' to emacsclient would be the best solution of 
the ones presented so far. That would allow both of the following in 
.desktop files:

   emacsclient --function my-function-taking-one-url %u
   emacsclient --function my-function-taking-many-urls %U

(Likewise for %f/%F, which expands to one/many file names.) '--setq' has 
the disadvantage that you'd need some way to prepend *each* URL/filename 
with it in the %U/%F cases.

The functions above would need to be able to consume command-line 
arguments (like 'message-mailto' does), but that's not a big deal. We 
could even add an 'apply-from-command-line' function that adapts any 
existing function to do this:

   emacsclient --function apply-from-command-line func arg1 arg2

'apply-from-command-line' could look at the arity of 'func' and consume 
the appropriate number of command-line arguments.

Adding '--function' to emacsclient also has the advantage that it's 
already available for emacs, so it's not really an all-new feature so 
much as it is just adding a new place you can use it from. The semantics 
of '--function' are already set, and should work just fine for the cases 
described in this bug.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Gregory Heytings]

>
> I'm not convinced that '--function-arg' is necessary, but I do think 
> that adding '--function' to emacsclient would be the best solution of 
> the ones presented so far.
>

It's not very adaptable, whereas --eval allows you to run an arbitrary 
form.

>
> That would allow both of the following in .desktop files:
>
> emacsclient --function my-function-taking-one-url %u
> emacsclient --function my-function-taking-many-urls %U
>

Sure, and how would you use it say in shell scripts, in which these 
%u/%U/%f/%F constructs do not exist?

>
> '--setq' has the disadvantage that you'd need some way to prepend *each* 
> URL/filename with it in the %U/%F cases.
>

What about --setq args "(list %U)"?

>
> The functions above would need to be able to consume command-line 
> arguments (like 'message-mailto' does), but that's not a big deal. We 
> could even add an 'apply-from-command-line' function that adapts any 
> existing function to do this:
>
> emacsclient --function apply-from-command-line func arg1 arg2
>
> 'apply-from-command-line' could look at the arity of 'func' and consume 
> the appropriate number of command-line arguments.
>

That's over-engineering IMO.

>
> Adding '--function' to emacsclient also has the advantage that it's 
> already available for emacs,
>

No, emacs only has --funcall: call Emacs Lisp function FUNC with no 
arguments.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Jim Porter]

On 9/16/2022 11:26 AM, Gregory Heytings wrote:
>> That would allow both of the following in .desktop files:
>>
>> emacsclient --function my-function-taking-one-url %u
>> emacsclient --function my-function-taking-many-urls %U
>>
> 
> Sure, and how would you use it say in shell scripts, in which these 
> %u/%U/%f/%F constructs do not exist?

That depends on the script. However, as an example, maybe you want a 
'browse' alias that you can use from the shell (or a shell script) like 
this:

   browse https://gnu.org https://fsf.org

You might define that alias one of these ways (assuming 'eww-browse-url' 
were enhanced to use 'command-line-args-left' like 'message-mailto'):

   alias browse='firefox'
   alias browse='emacs -f eww-browse-url'
   alias browse='emacsclient --funcall eww-browse-url'

>> '--setq' has the disadvantage that you'd need some way to prepend 
>> *each* URL/filename with it in the %U/%F cases.
>>
> 
> What about --setq args "(list %U)"?

That wouldn't work, since .desktop files forbid %-expansions inside 
quotes[1]. Even working around that, the expansion would look something 
like this:

   (list mailto:foo@bar.com ...)

Since want each argument to be a string (and wrapping quotes around each 
element won't work for the same reason I previously mentioned), we'd 
probably want a different syntax than the above. I wouldn't expect that 
syntax to make a list of strings.

>> Adding '--function' to emacsclient also has the advantage that it's 
>> already available for emacs,
>>
> 
> No, emacs only has --funcall: call Emacs Lisp function FUNC with no 
> arguments.

Sorry, yes. I meant --funcall.

This would likely necessitate some changes to how emacsclient talks to 
the main emacs process though, since I believe positional arguments to 
emacsclient are currently always treated as file names to visit. For 
"emacsclient --funcall" to work like "emacs --funcall", emacsclient 
would have to let the main emacs process process at least some of the 
arguments in the same manner as command-line arguments to "emacs" (i.e. 
allow reading them via '(pop command-line-args-left)' or something similar).

(I also have an alternate strategy for addressing the original bug, 
which I'll describe in a separate message so that this subthread doesn't 
get too unwieldy.)

[1] 
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Jim Porter]

On 9/13/2022 5:19 AM, Lars Ingebrigtsen wrote:

> I'd prefer to have a .desktop file that works without any helper
> scripts.   Can't the emacsclient-mail.desktop file be rewritten to not
> use quoting here?

Here's another strategy for handling this, inspired by org-protocol[1].
For those who haven't used it, org-protocol invokes emacsclient with an 
"org-protocol://..." URL to let you do things like capture text from 
another application.

Extending from that, what if Emacs introduced URL handlers, so that these:

   emacs mailto:foo@bar.com
   emacsclient mailto:foo@bar.com

would look up a "mailto:" handler defined somewhere in Emacs[2] (e.g. 
'message-mailto') and call that function instead of 'find-file'. This is 
roughly how the org-protocol module handles this, although it only works 
for emacsclient (it adds advice to a few functions from server.el).

This would be less flexible than having a generic way of feeding certain 
command-line arguments to an Emacs Lisp function, but I'm not sure what 
practical uses we'd need that for aside from handling URLs, as in this 
bug or for org-protocol. If there are some other uses people have for 
the more-flexible implementation, I think it would help to list those so 
we can be sure the chosen solution addresses them.

[1] https://orgmode.org/manual/Protocols.html
[2] Possibly opt-in in the user's config. I don't have any preferences here.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Gregory Heytings]

>> What about --setq args "(list %U)"?
>
> That wouldn't work, since .desktop files forbid %-expansions inside 
> quotes[1]. Even working around that, the expansion would look something 
> like this:
>
> (list mailto:foo@bar.com ...)
>

Okay, now I see what you mean, you want to be able to pass an array of 
strings/arguments to Elisp.  Then I think that the cleanest/most flexible 
way to do that would be

--setq VAR VAL ... --

(note the final double hyphen) defined as having the effect of (setq VAR 
(list "VAL" ...)).  That would allow zero, one or more arguments.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Lars Ingebrigtsen]

Jim Porter <jporterbugs@gmail.com> writes:

> 1) Instead of specifying the function args with a flag, I think I'd go
> the other way and specify the function as being special, e.g.:
>
>   emacs --apply func arg1 arg2

Yes, that sounds good.  (But we'd still need "--" to say that the
arguments have ended.)

> 2) Even better, why not just use --function and pass some higher-order
> function:
>
>   emacs --function apply-from-command-line func arg1 arg2

I think that sounds more obscure, really (even if it's simpler to
implement in the "emacs" case).

> That way, it's easy to substitute in some other higher-order function
> if you want. emacsclient would still need to add a --function flag
> though, and probably some changes to how it forwards arguments to the
> main emacs so that you can do stuff like this.

Since we have to add something new to emacsclient in any case, I'd
rather go with adding "--apply" to both Emacs and emacsclient, I think.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Lars Ingebrigtsen]

Jim Porter <jporterbugs@gmail.com> writes:

> If there are some other uses people have for the more-flexible
> implementation, I think it would help to list those so we can be sure
> the chosen solution addresses them.

The general use case is that having --apply just makes things easier to
script without having to worry about string interpolation.  Getting
--eval "(...\\"$foo\\" $bar)" etc right in all circumstances is hard and
leads to fragile scripts.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Robert Pluim]

>>>>> On Fri, 16 Sep 2022 20:04:25 +0000, Gregory Heytings <gregory@heytings.org> said:

    Gregory> Okay, now I see what you mean, you want to be able to pass an array of
    Gregory> strings/arguments to Elisp.  Then I think that the cleanest/most
    Gregory> flexible way to do that would be

    Gregory> --setq VAR VAL ... --

    Gregory> (note the final double hyphen) defined as having the effect of (setq
    Gregory> VAR (list "VAL" ...)).  That would allow zero, one or more arguments.

That sounds good, although it should not be called '--setq', to avoid
people opening bugs saying "I did --setq indent-tabs-mode nil -- and
itʼs still 't'". --let or --bind or ....?

Robert
-- 

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Robert Pluim]

>>>>> On Sun, 18 Sep 2022 12:23:47 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Jim Porter <jporterbugs@gmail.com> writes:
    >> 1) Instead of specifying the function args with a flag, I think I'd go
    >> the other way and specify the function as being special, e.g.:
    >> 
    >> emacs --apply func arg1 arg2

    Lars> Yes, that sounds good.  (But we'd still need "--" to say that the
    Lars> arguments have ended.)

    >> 2) Even better, why not just use --function and pass some higher-order
    >> function:
    >> 
    >> emacs --function apply-from-command-line func arg1 arg2

    Lars> I think that sounds more obscure, really (even if it's simpler to
    Lars> implement in the "emacs" case).

    >> That way, it's easy to substitute in some other higher-order function
    >> if you want. emacsclient would still need to add a --function flag
    >> though, and probably some changes to how it forwards arguments to the
    >> main emacs so that you can do stuff like this.

I think this would be covered by '--apply apply-from-command-line func
arg1 arg2'

Youʼd have to write 'apply-from-command-line' yourself, although
thereʼd be nothing stopping us from providing a generic one that does

(apply (intern (pop command-line-args-left)) command-line-args-left)

or similar.

    Lars> Since we have to add something new to emacsclient in any case, I'd
    Lars> rather go with adding "--apply" to both Emacs and emacsclient, I think.

I think this is the best option (and we leave anything complicated to '--eval').

Robert
-- 

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Jim Porter]

On 9/18/2022 3:23 AM, Lars Ingebrigtsen wrote:
> Jim Porter <jporterbugs@gmail.com> writes:
> 
>> 1) Instead of specifying the function args with a flag, I think I'd go
>> the other way and specify the function as being special, e.g.:
>>
>>    emacs --apply func arg1 arg2
> 
> Yes, that sounds good.  (But we'd still need "--" to say that the
> arguments have ended.)

This is actually the trickiest part about this to me. If I were 
designing this, I'd say that '--apply' consumes every positional 
argument up to the next flag. If it encounters a '--' while consuming 
arguments, *every* remaining argument gets passed to the function. That 
allows the following:

   emacs --apply func1 arg1 arg2 --apply func2 arg3 arg4 -Q
     => emacs -Q
        (func1 "arg1" "arg2")
        (func2 "arg3" "arg4")

   emacs --apply func -- --arg1 --arg2
     => emacs
        (func "--arg1" "--arg2")

This way, users can pass arguments beginning with a "-" to the function 
being applied while still retaining a fair amount of flexibility in 
other cases. It would also be good for shell scripts/aliases where you 
don't know ahead of time what the arguments will look like. If you had 
this in your shell environment:

   EDITOR="emacs --apply fancy-find-file"

then you might try to visit a file named "-Q". However, it would treat 
"-Q" as an argument to emacs instead. With what I suggested above, you'd 
just say:

   EDITOR="emacs --apply fancy-find-file --"

That's a common way of doing this for other command-line tools, so I 
think most people should understand the behavior fairly easily.

>> 2) Even better, why not just use --function and pass some higher-order
>> function:
>>
>>    emacs --function apply-from-command-line func arg1 arg2
> 
> I think that sounds more obscure, really (even if it's simpler to
> implement in the "emacs" case).

Either is fine with me. Originally, I thought that "--funcall 
apply-from-command-line ..."[1] might be nicer since you could replace 
'apply-from-command-line' with a fancier function, e.g. one that parses 
numeric values, but I think you'd be able to do that with --apply 
anyway. It's probably better to keep the simple path simple and go with 
--apply.

[1] I had meant to type --funcall instead of --function in my previous 
message, but got mixed up.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Youʼd have to write 'apply-from-command-line' yourself, although
> thereʼd be nothing stopping us from providing a generic one that does
>
> (apply (intern (pop command-line-args-left)) command-line-args-left)
>
> or similar.

I don't see any advantages to having something like that over something
like --apply.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Lars Ingebrigtsen]

Jim Porter <jporterbugs@gmail.com> writes:

> This is actually the trickiest part about this to me. If I were
> designing this, I'd say that '--apply' consumes every positional
> argument up to the next flag.

Sorry, that would just be a very fiddly, often-breaking interface.  If
you say

emacs --apply foo $1 $2

and $2 happens to be "-*hakuna-matata*-", then you'd get a failure.
Morover, there's no way to separate

emacs --apply foo param1 param2

from 

emacs --apply foo param1 file-to-be-opened

So we need "--" to end the parameter list.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Gregory Heytings]

>> emacs --apply func arg1 arg2
>
> Yes, that sounds good.
>

Hmm...  I did not see the --apply proposal earlier, it's nice and lispy 
indeed.

I think I would prefer to separate the two concerns (stuffing argument 
strings into the Lisp environment on the one hand, and forms on the other 
hand), but it seems good enough, and perhaps it's the best compromise.

One disadvantage I see is that it becomes a bit more complex to write 
function calls with arguments that are not strings.  E.g. to call

(some-func 1 "arg" t)

one would have to do something like

--eval '(defun tmp-func (arg) (some-func 1 arg t))' --apply tmp-func arg

instead of something like

--set args arg -- --eval '(some-func 1 (car args) t)'

Likewise, if we want to use the arguments in multiple --eval forms, 
something like

--eval '(defun setarg1 (arg) (setq arg1 arg))' --apply setarg1 arg -- --eval '(... arg1 ...)' --eval '(... arg1 ...)'

will be necessary.  Yet another example is that to loop over all 
arguments, one would have to do something like

--eval '(defun loop-fun (args) (dolist (arg args) ...))' --apply loop-fun args

instead of something like

--set args arg -- --eval '(dolist (arg args) ...)'

One case in which --apply is better is when the function is already 
defined by Emacs, e.g. (with the .desktop example mentioned upthread, and 
assuming that find-many-files is defined by Emacs)

--apply find-many-files %F

is probably clearer than

--set files %F -- --eval '(find-many-files files)'

>
> (But we'd still need "--" to say that the arguments have ended.)
>

Except for the last argument(s), of course.  IOW, except if there are no 
arguments that must not be passed to the function after the function 
arguments.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> One disadvantage I see is that it becomes a bit more complex to write
> function calls with arguments that are not strings.  E.g. to call
>
> (some-func 1 "arg" t)

Yes, that's unfortunate.  On the other hand, where these things are
useful, you'd usually expect the Emacs to take string arguments.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Jim Porter]

On 9/19/2022 1:12 AM, Lars Ingebrigtsen wrote:
> Jim Porter <jporterbugs@gmail.com> writes:
> 
>> This is actually the trickiest part about this to me. If I were
>> designing this, I'd say that '--apply' consumes every positional
>> argument up to the next flag.
> 
> Sorry, that would just be a very fiddly, often-breaking interface.  If
> you say
> 
> emacs --apply foo $1 $2
> 
> and $2 happens to be "-*hakuna-matata*-", then you'd get a failure.

In my suggestion, this would be spelled

   emacs --apply foo -- $1 $2

However...

> Morover, there's no way to separate
> 
> emacs --apply foo param1 param2
> 
> from
> 
> emacs --apply foo param1 file-to-be-opened
> 
> So we need "--" to end the parameter list.

This would indeed be impossible in my suggestion (at least not without 
having 'foo' call 'find-file'). Just to make sure I understand your 
suggestion: '--apply' would consume *every* argument after it until it 
sees a '--'? So to apply 2 functions, you'd say:

   emacs --apply func1 arg1 arg2 -- --apply func2 arg3 arg4

That seems like it would probably be ok, so long as no one wanted to 
pass a literal '--' to the function. I don't think there's much of a 
security risk either, since the worst that would happen is someone 
sending "-- foobar", causing "foobar" to get opened as a file.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Jim Porter]

On 9/19/2022 1:56 AM, Gregory Heytings wrote:
> Hmm...  I did not see the --apply proposal earlier, it's nice and lispy 
> indeed.
> 
> I think I would prefer to separate the two concerns (stuffing argument 
> strings into the Lisp environment on the one hand, and forms on the 
> other hand), but it seems good enough, and perhaps it's the best 
> compromise.
> 
> One disadvantage I see is that it becomes a bit more complex to write 
> function calls with arguments that are not strings.  E.g. to call
> 
> (some-func 1 "arg" t)
> 
> one would have to do something like
> 
> --eval '(defun tmp-func (arg) (some-func 1 arg t))' --apply tmp-func arg
> 
> instead of something like
> 
> --set args arg -- --eval '(some-func 1 (car args) t)'

If Emacs gained a 'set-arg' function (similar to 'setarg1' in your 
message) that does the right thing, you could say:

   --apply set-arg args arg -- --eval '(some-func 1 (car args) t)'

Another way would be a function that "intelligently" converts arguments 
to other types. This is similar to how Eshell command forms work: if 
you're calling a Lisp function with sh-like syntax, it will 
automatically convert arguments that look like numbers into actual 
numbers. So maybe you could do something like:

   --apply autoconvert-strings-and-apply some-func 1 arg t

That seems clumsier to me than 'set-arg', but since these could all be 
written as Lisp functions, users or package authors should be able to do 
whatever they need. Of course, core Emacs could add whichever helper 
function(s) seem generally useful.

> One case in which --apply is better is when the function is already 
> defined by Emacs...

Yeah, for more-complex forms, you'd still need to fall back to --eval or 
something similar. But a Lisp function like 'set-arg' could let us reuse 
the --apply machinery. I think it could be as simple as this:

   (defun set-arg (name &rest value)
     (set (intern name) value))

That should give us '--set', except that it's spelled '--apply set-arg'.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Gregory Heytings]

>
> But a Lisp function like 'set-arg' could let us reuse the --apply 
> machinery. I think it could be as simple as this:
>
>  (defun set-arg (name &rest value)
>    (set (intern name) value))
>
> That should give us '--set', except that it's spelled '--apply set-arg'.
>

Indeed.  So --apply with a predefined set-args function should cover all 
cases I mentioned earlier.  That should have been obvious, sorry for the 
noise.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Lars Ingebrigtsen]

Jim Porter <jporterbugs@gmail.com> writes:

> This would indeed be impossible in my suggestion (at least not without
> having 'foo' call 'find-file'). Just to make sure I understand your
> suggestion: '--apply' would consume *every* argument after it until it
> sees a '--'? So to apply 2 functions, you'd say:
>
>   emacs --apply func1 arg1 arg2 -- --apply func2 arg3 arg4

Yes.

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Max Nikulin]

On 13/09/2022 20:29, Damien Cassou wrote:
> Lars Ingebrigtsen writes:
>> I'd prefer to have a .desktop file that works without any helper
>> scripts.   Can't the emacsclient-mail.desktop file be rewritten to not
>> use quoting here?
> 
> This is maybe possible but I haven't found a way. Moreover, the
> constraints that "Field codes must not be used inside a quoted argument"
> makes things more complex.

It is possible to pass %u to shell using positional parameters:

     sh -c 'echo "$1"' demo ARGUMENT

However POSIX shell is not enough to escape double quote and backslash 
inside %u for elisp. BASH allows to perform substitutions during 
variable expansion. The idea is the following (it needs more backslashes 
to conform XDG spec):

bash -c 'e=${1//\\/\\\\}; e=${e///\"/\\\"}; emacsclient 
--alternate-editor= --display="$DISPLAY" --eval=\(message-mailto\ 
"\"$e\""\)' emacsclient-mailto %u

bug#57752: 28.1.91; emacsclient-mail.desktop doesn't work for me

[Max Nikulin]

On 02/12/2022 21:52, Max Nikulin wrote:
> 
> bash -c 'e=${1//\\/\\\\}; e=${e///\"/\\\"}; emacsclient 
> --alternate-editor= --display="$DISPLAY" --eval=\(message-mailto\ 
> "\"$e\""\)' emacsclient-mailto %u

A similar approach has been applied in the following commits:

- c8ec0017cb9 2023-03-08 19:37:27 +0100 Ulrich Müller:
   Avoid using bash in the emacsclient desktop file
- 3c1693d08b0 2023-03-07 18:25:37 +0100 Ulrich Müller:
   Fix Elisp code injection vulnerability in emacsclient-mail.desktop
- d32091199ae 2022-12-19 16:51:20 +0100 Ulrich Müller:
   Fix quoted argument in emacsclient-mail.desktop Exec key

See
- (#60204)
- Gabriel Corona. Shell command and Emacs Lisp code
   injection in emacsclient-mail.desktop. Wed, 8 Mar 2023 12:37:29 +0100
   https://www.openwall.com/lists/oss-security/2023/03/08/2

So the specific reported issue has been fixed. I am unsure if this bug 
should be closed or it should be left open to continue discussion how to 
implement passing literal arguments through emacsclient.