bug#60021: 29.0.60; Eshell completion errors in the presence of buffer redirects

[Gregory Heytings <gregory@heytings.org>]

>> Daniel, can you please try the attached patch and tell us if it fixes 
>> the issue without introducing regressions?
>
> Thanks for looking into this!
>

Thanks for your reply!

>
> I inspected the patch and it seems like a reasonable fix for the 
> problem. I wonder about the introduction of the `pcomplete-arg-value' 
> string property. Is the introduction of this property necessary? Do you 
> have a use case for this right now?
>

Not right now, no.  It's a kind of compromise.  Previously pcomplete-args 
(and pcomplete.el in general) assumed that 
pcomplete-parse-argument-function would return strings, and only strings. 
When that's not the case, such as in eshell, it fails.  For example, with 
your recipe, when '#<*scratch*>' is parsed, a buffer object is returned. 
That value could have been transformed into a string with 'format', but 
that would mean that the original value has been lost (from the point of 
view of pcomplete).  The solution we found is to wrap that value in a 
string, the textual representation of the argument, namely the string 
"#<*scratch*>" in your recipe.  With that solution it becomes possible to 
design other pcomplete functions that would use that value.

>
> If the recipes of #59956 and #60021 are fixed by this on your setup, I 
> trust it will work properly on my setup. No reason for additional 
> testing on my side.
>

They are fixed, but I don't use eshell (and neither does Stefan M IIUC), 
so I may very well have missed some important other cases in which that 
fix would introduce a regression.