bug#59956: 29.0.60: Failure when completing arguments in Eshell after variable interpolation

[Jim Porter <jporterbugs@gmail.com>]

On 12/19/2022 2:31 AM, Augusto Stoffel wrote:
> If $foo is "-u -v"`, your patch will make pcomplete see this as a single
> argument, no?

For Eshell at least, that's what it should do:

   ~ $ setq foo "-AlF ."
   -AlF .
   ~/src/emacs/build $ ls $foo
   /usr/bin/ls: invalid option -- ' '
   Try '/usr/bin/ls --help' for more information.

Variable expansions in Eshell work more like they do in Zsh, where they 
*aren't* split into multiple arguments on word boundaries.

> I think it makes sense to send the string "$foo" with the list '("-u"
> "-v") embedded as text property, and add some convenience functions to
> fetch the list for the pcomplete functions that can handle the more
> refined information.

I think the best would be if code that invokes Pcomplete would tell 
Pcomplete the expanded forms of its arguments like it does now, but to 
additionally make sure that the Pcomplete function sees those arguments 
the way the actual command would. If Eshell provided a flattened list of 
strings to Pcomplete, then everything should Just Work, right?

However, I'm not sure how to do that *and* be able to provide the 
un-stringified version so that Pcomplete functions for built-in Eshell 
commands can access those arguments in their original (but still 
expanded) forms. Can Eshell know ahead of time what form to provide its 
arguments in? Should it just provide both and let the Pcomplete function 
pick its poison?