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

From: Jim Porter <[email-masked]>
Date: Sun, 18 Dec 2022 18:15:48 -0800

On 12/18/2022 5:19 PM, Gregory Heytings wrote:
> Hmmm...  So I guess it would be better, instead of replacing lists (and 
> in general non-strings) by their string representation, and instead of 
> always looking at an unexpanded argument, to look at the unexpanded 
> argument only when the expanded argument is not a string?  E.g. if $foo 
> is "-u" we would use "-u", but if $foo is (b a r) we would use "$foo".

For external commands called from Eshell, the most-correct thing to do 
would be to take the list of all arguments, flatten it, and convert 
every element in the flattened list to a string. That's how Eshell will 
ultimately call the program.

The tricky bit in my mind is how to do that automatically for external 
commands, but to still allow a Pcomplete function for an Eshell command 
(i.e. a function named 'eshell/FOO') to have access to the "raw"[1] 
expanded form, even if it contains sublists, numbers, other objects, 
etc. Maybe we could just do the first thing above, and then think about 
adding a new API to Pcomplete that gets the "raw" expanded form for later...

[1] Is it really "raw" if variables have been expanded? Probably not. I 
can't think of a better name at the moment though.