GNU bug report logs - #65902
29.0.92; emacsclient-mail.desktop fails due to complicated escaping

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 65902 <at> debbugs.gnu.org, sbaugh <at> catern.com, jporterbugs <at> gmail.com
Subject: bug#65902: 29.0.92; emacsclient-mail.desktop fails due to complicated escaping
Date: Thu, 14 Sep 2023 17:31:28 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: sbaugh <at> catern.com,  jporterbugs <at> gmail.com,  65902 <at> debbugs.gnu.org
> Date: Thu, 14 Sep 2023 10:04:48 -0400
> 
> Eli Zaretskii <eliz <at> 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.

Bottom line: the escaping issue doesn't seem to me a reason strong
enough to justify adding such a new feature.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.