From: Eli Zaretskii <eliz@gnu.org>
To: Spencer Baugh <sbaugh@janestreet.com>
Cc: 65902@debbugs.gnu.org, sbaugh@catern.com, jporterbugs@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 [thread overview]
Message-ID: <83o7i4ltbz.fsf@gnu.org> (raw)
In-Reply-To: <iermsxoam0v.fsf@janestreet.com> (message from Spencer Baugh on Thu, 14 Sep 2023 10:04:48 -0400)
> 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.
Bottom line: the escaping issue doesn't seem to me a reason strong
enough to justify adding such a new feature.
next prev parent reply other threads:[~2023-09-14 14:31 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fe2cc764-86c6-4840-80b7-8f3a3778b374@email.android.com>
2023-09-13 14:50 ` bug#65902: 29.0.92; emacsclient-mail.desktop fails due to complicated escaping Eli Zaretskii
2023-09-13 15:01 ` Andreas Schwab
2023-09-13 15:23 ` Spencer Baugh
2023-09-13 16:19 ` Jim Porter
2023-09-13 19:13 ` Eli Zaretskii
2023-09-13 19:33 ` Jim Porter
2023-09-13 20:00 ` Spencer Baugh
2023-09-13 20:16 ` Jim Porter
2023-09-14 5:10 ` Eli Zaretskii
2023-09-14 11:03 ` sbaugh
2023-09-14 11:18 ` sbaugh
2023-09-14 11:35 ` sbaugh
2023-09-14 13:36 ` Eli Zaretskii
2023-09-14 14:04 ` Spencer Baugh
2023-09-14 14:31 ` Eli Zaretskii [this message]
2023-09-14 19:16 ` Jim Porter
2023-09-15 5:33 ` Eli Zaretskii
2023-09-16 13:43 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-16 14:02 ` Eli Zaretskii
2023-09-16 15:54 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] <80d8aeb0-c9f1-410f-b83d-60f83ca5b3af@email.android.com>
2023-09-14 14:57 ` Eli Zaretskii
2023-09-14 15:10 ` Spencer Baugh
2023-09-15 6:29 ` Eli Zaretskii
2023-09-22 1:36 ` sbaugh
2023-09-22 6:36 ` Eli Zaretskii
2023-09-23 20:24 ` sbaugh
2023-09-24 5:18 ` Eli Zaretskii
2023-09-24 14:20 ` sbaugh
2023-10-21 15:20 ` sbaugh
2023-10-22 5:27 ` Eli Zaretskii
2023-10-22 14:15 ` sbaugh
2023-10-22 16:09 ` Andreas Schwab
2023-10-22 19:53 ` sbaugh
2023-10-23 16:38 ` Andreas Schwab
2023-10-23 16:52 ` Jim Porter
2023-10-24 16:27 ` sbaugh
2023-10-29 12:20 ` Eli Zaretskii
2023-10-22 5:39 ` Jim Porter
2023-09-22 7:05 ` Stefan Kangas
2023-09-22 7:14 ` Eli Zaretskii
2023-09-22 9:29 ` Andreas Schwab
2023-09-22 11:32 ` Eli Zaretskii
2023-09-22 12:37 ` Andreas Schwab
2023-09-22 12:56 ` Eli Zaretskii
2023-09-22 13:23 ` Andreas Schwab
2023-09-22 14:51 ` Eli Zaretskii
2023-09-22 14:52 ` Andreas Schwab
2023-09-13 2:24 sbaugh
2023-09-13 2:30 ` sbaugh
2023-09-13 3:46 ` Jim Porter
2023-09-13 8:00 ` Robert Pluim
2023-09-13 13:06 ` Eli Zaretskii
2023-09-13 14:22 ` Robert Pluim
2023-09-13 12:41 ` Eli Zaretskii
2023-09-13 12:57 ` sbaugh
2023-09-13 12:41 ` Eli Zaretskii
2023-09-13 13:01 ` sbaugh
2023-09-13 13:26 ` Eli Zaretskii
2023-09-16 13:30 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83o7i4ltbz.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=65902@debbugs.gnu.org \
--cc=jporterbugs@gmail.com \
--cc=sbaugh@catern.com \
--cc=sbaugh@janestreet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).