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

Hi John,

As the original designer of both Eshell and Pcomplete, what's your
opinion on the below:

>>> Starting from "emacs -Q -f -eshell", type "echo $exec-path " (note the 
>>> trailing space), and then hit TAB. The result is this error:
>>> 
>>>    pcomplete-match: Wrong type argument: stringp, ("/usr/bin" ...)
>>> 
>>> This is a regression from Emacs 28, and it looks like it's due to 
>>> 'pcomplete-here-using-help' assuming that all the pcomplete args are 
>>> strings. However, 'exec-path' is a list (and Eshell reports it this way 
>>> to pcomplete), so the completion fails. I think all that's necessary is 
>>> checking that the pcomplete args are strings in 
>>> 'pcomplete-here-using-help', but I know next to nothing about pcomplete...
>>
>> Adding Stefan, who should know more about pcomplete.
>> Stefan, any suggestions?
>
> For the record, this problem afflicts just about every pcomplete rule
> (except probably those meant specifically for eshell).  I just tried
> `cvs $echo-path TAB` and I get the same error.

Indeed, it seems to be a pervasive problem.

> The issue here is what eshell returns via (pcomplete-arg ...) etc.
> Currently it can be a list.  How about changing it to the string
> "$echo-path", with the list sneaked in as a text property?

From the point of view of Pcomplete, `pcomplete-arg` should indeed
always return a string, I think.  But should it be the string as it
stands in the buffer or the string *represented* by what's in
the buffer (i.e. after $ expansion and such)?
Should `pcomplete-arg` return nil in a case like `echo $nil`?

For "normal" shells, this is not an issue since they don't really
manipulate anything else than strings (or so we can pretend), but
obviously things aren't that simple for Eshell.


        Stefan