bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#65902: 29.0.92; emacsclient-mail.desktop fails due to complicated escaping
Date: Fri, 22 Sep 2023 09:36:16 +0300

> From: sbaugh@catern.com
> Date: Fri, 22 Sep 2023 01:36:47 +0000 (UTC)
> Cc: Spencer Baugh <sbaugh@janestreet.com>, jporterbugs@gmail.com,
>       65902@debbugs.gnu.org
> 
> > 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?
> 
> As in the attached patch.

I wish you'd accompanied the patch with some plain-text description of
the idea, to make it easier to understand and to avoid unnecessary
misunderstandings.

IIUC, this kind of solution is fine by me, but the protocol of
accessing and using server-eval-args-left in the Lisp expressions
specified on the emacsclient command line should be well-documented to
avoid any confusion and UB.

Also, the patch includes an unrelated change:

> --- a/lisp/server.el
> +++ b/lisp/server.el
> @@ -1165,7 +1165,7 @@ server-process-filter
>      (when prev
>        (setq string (concat prev string))
>        (process-put proc 'previous-string nil)))
> -  (condition-case err
> +  (condition-case-unless-debug err





reply via email to

[Prev in Thread] Current Thread [Next in Thread]