bug#11474: Patch for Emacsclient --eval bug

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> $ emacsclient -a nano --eval '(my-emacs-setup-thing)'
>>
>> The eval bit is meaningful in Emacs, and may be something that the user
>> feels is something that Emacs should do when called from emacsclient.
>> But if there's no server, then we should use nano.
>>
>> The current behaviour is to use nano with the file name
>> '(my-emacs-setup-thing)', while you propose to call nano with
>> --eval '(my-emacs-setup-thing)', which would be even worse, I think,
>> while just dropping the parameters completely in the -a case would make
>> this usable.
>
> I think that nowadays with the `-a ""` option the need to keep
> the --eval is indeed not very high, so I retract my objection.

Hm...  the emacsclient source code has changed substantially over the
years, I see...

  if (alternate_editor)
    {
      size_t extra_args_size = (main_argc - optind + 1) * sizeof (char *);
      size_t new_argv_size = extra_args_size;
      char **new_argv = xmalloc (new_argv_size);

[...]

      /* Append main_argv arguments to new_argv.  */
      memcpy (&new_argv[toks], main_argv + optind, extra_args_size);

      execvp (*new_argv, new_argv);
      message (true, "%s: error executing alternate editor \"%s\"\n",
               progname, alternate_editor);
    }

So it now picks out arguments from the -a="nano --foo" string, and then
appends the rest of the arguments from emacsclient.

The equivalent here would be to set extra_args_size to 0 if eval, I
guess.  But...  hm....  then we'd lose the file argument too, wouldn't
we?

I mean, if you say

$ ./lib-src/emacsclient -a "nano -v" --eval '(message "foo")' /tmp/a

the you want nano to open /tmp/a...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no