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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> There's a tension here: we want the completion to operate on the actual
>> buffer text obviously, so in some places we definitely want to see the
>> "unexpanded argument" [1], but when it comes to looking at other arguments
>> to decide which completion table to use at point, it's often more useful
>> to see the expanded arguments (i.e. the thing that the command will
>> actually see).  E.g. if the previous arg is `$foo` which expands to `-u`
>> we'd probably prefer to see `-u` in order to know we should complete
>> against user names.
>
> If $foo is "-u -v"`, your patch will make pcomplete see this as a single
> argument, no?

I must admit that this gets into detailed semantics of Eshell with which
I'm not familiar, but AFAIK if $foo contains a string such as "-u -v",
then my patch won't have any effect at all.

More generally my patch doesn't change the number of arguments as seen
by `pcomplete-arg`.  IOW if $foo is turned into several arguments, it's
presumably done before those are turned into what Pcomplete sees as "the
list of arguments".

> 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.

Could make sense, indeed.  I'd be interested to see what a patch for
that could look like, tho.


        Stefan