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

[Spencer Baugh]

On Sep 14, 2023 10:31, Eli Zaretskii <eliz@gnu.org> wrote:

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: sbaugh@catern.com,  jporterbugs@gmail.com,  65902@debbugs.gnu.org
> Date: Thu, 14 Sep 2023 10:04:48 -0400
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > What you are doing is representing a rare problem related to a niche
> > feature is if it were a general one, by inventing use cases to justify
> > that.  But if those use cases were important, people would have asked
> > for them long ago.  They didn't.  Why? because --eval already exists.
>
> No... these are real use cases that I personally have.  I have really
> wanted this for a long time.  As I said in my original email, "I expect
> this to also be useful in other places; the need to escape arbitrary
> inputs before passing them to emacsclient is frequently annoying."

Maybe it's annoying, but it can be done.  And Emacs has the same
feature, btw.

> > Emacs developers make mistakes even in the simple regexps we have in
> > our code.  That doesn't mean we should abandon regexps.  The solution
> > for sending Lisp forms to the server exists, and the quoting, although
> > tricky in some cases, is not rocket science to get right.
>
> I think this (the current contents of emacsclient-mail.desktop):
> sh -c "u=\\$(echo \\"\\$1\\" | sed 's/[\\\\\\"]/\\\\\\\\&/g'); exec
> emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" --eval
> \\"(message-mailto \\\\\\"\\$u\\\\\\")\\"" sh %u
>
> is in fact rocket science, and rocket science that needs to be repeated
> by every user who wants to pass arbitrary strings to Emacs.

We disagree.


> And keep in mind this mass of escaping *is currently broken*.

Patches to fix it are welcome, although as I said I'd be quite glad to
remove these desktop files from our repository.

> > That's an illusion.  There's nothing simple about it.  You are
> > inventing a new mechanism for passing Lisp forms as something other
> > than Lisp.
>
> But I don't want to pass Lisp forms, that's the entire point.  I have
> some arbitrary string which is *not* Lisp, and I want Emacs to *not*
> parse it as Lisp.

It becomes Lisp when the server executes the request.

> >   $ emacsclient --apply func arg1 'foo arg2 'bar
> >
> > Escape-quoting, here we come again!
>
> That example works fine with --apply.  The call becomes:
> (func "arg1" "'foo" "arg2" "'bar")
> which is reliable and expected.
>
> Maybe you're referring to how, if you run that command through a shell,
> the shell interprets the single quotes as creating a string?

Of course, I am!

> But that's that's a separate issue, because:
>
> - I don't plan to run any of my commands using --apply through a shell
>   (which means they will require zero escaping or quoting whatsoever)

This feature, if it will be added, is not just for you, it's for
everyone.  And emacsclient is a shell command, so invoking it from the
shell is both natural and frequently used.

> - Right now with --eval you have to do escaping for both the shell and
>   Lisp.  With --apply you only have to do escaping for the shell, if you
>   do use a shell, and if you don't use a shell you don't have to do
>   anything.

But we do that for Emacs, and do it quite a lot.

> I think it is simpler to reduce the amount of quoting and escaping from
> "both Lisp and shell" to "just shell, and not even that if you don't use
> a shell".

At what cost?  The cost of adding yet another protocol for passing
Lisp forms to the server is just too high for my palate.

Okay, if I do this without making modifications to emacsclient.c or the server protocol, would that be more acceptable? The approach I described in another email, with server-eval-args-left, all it adds is a new variable.