bug#65902: 29.0.92; emacsclient-mail.desktop fails due to complicated escaping

[Spencer Baugh]

Jim Porter <jporterbugs@gmail.com> writes:

> On 9/13/2023 12:13 PM, Eli Zaretskii wrote:
>> And I don't understand why we need to add any options to Emacs itself,
>> btw.  The suggestion to have some "symmetry" here was one of the
>> reasons that discussion got nowhere.  So let's learn from that
>> mistake, at least.
>
> There's a practical benefit to this. If you have $EDITOR set in your
> environment to something like "emacsclient --alternate-editor=emacs",
> then it would be nice if you could say this:
>
>   $EDITOR --apply some-func arg1 arg2
>
> and have it do the same thing whether or not there was already an
> Emacs server running. The symmetry between the two commands (plus
> proper argument forwarding) would make that work.

This already works out of the box with --alternate-editor='', no need
for any argument forwarding, and no need for support for this argument
in Emacs itself.

It doesn't work with --alternate-editor=emacs, but I think that is OK.
I think the alternate-editor='' configuration is far more common, and
that works just fine.

And we have not before done any special casing for forwarding arguments
from emacsclient to alternate-editor=emacs, so I don't think there's any
reason to start now.  (I personally think that alternate-editor=emacs is
somewhat ill-advised, since it doesn't ensure that the server gets
started)

That being said, supporting --apply in Emacs itself is fine with me,
although it's not strictly necessary since in Emacs itself,
--apply func --
is basically equivalent to
--eval (apply func command-line-args-left)

(This doesn't work in emacsclient, and would be very difficult to
support, so --apply is necessary for emacsclient)

> However, if people can't agree, then we could probably drop that
> part. To me, it sounds like people *do* agree that this would be good
> to have though.

I'm fine either way.