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

Previous Next

Full log

Message #103 received at 65902 <at> debbugs.gnu.org (full text, mbox):

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

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: Spencer Baugh <sbaugh <at> catern.com>,  65902 <at> debbugs.gnu.org,
>    jporterbugs <at> gmail.com
> Date: Thu, 14 Sep 2023 11:10:44 -0400
> 
> We could make a command-line-args-left equivalent for emacsclient,
> called server-eval-args-left, which contains the FILE arguments passed
> to emacsclient as strings.  This can be done without making any changes
> to emacsclient.c or the server protocol.  Then the message-mailto
> use case would look like this:
> 
> emacsclient --eval '(message-mailto (pop server-eval-args-left))' %u
> 
> This would match how message-mailto uses (pop command-line-args-left)
> internally.
> 
> This would work for all the use-cases I described before; I'd be very
> happy with this solution (actually, I'm starting to prefer it to
> --apply).  And again, it doesn't change emacsclient.c or the server
> protocol.

This could perhaps be acceptable (although it's still rather kludgey,
IMO), but are you sure you understand all the consequences?
Currently, when emacsclient is invoked like this:

  $ emacsclient --eval '(func args)' foo bar

we send to the server the following commands:

  -eval (func args)
  -eval foo
  -eval bar

IOW, every command-line argument after --eval is treated as being
implicitly preceded with --eval.

With your proposal, how will the server know that some of "-eval foo"
commands should cause foo to be added to server-eval-args-left instead
of being evaluated as it does now?

Previous Next

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