GNU bug report logs - #59956
29.0.60: Failure when completing arguments in Eshell after variable interpolation

Previous Next

Full log

View this message in rfc822 format

From: Jim Porter <jporterbugs <at> gmail.com>
To: Augusto Stoffel <arstoffel <at> gmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: John Wiegley <johnw <at> newartisans.com>, Gregory Heytings <gregory <at> heytings.org>, Eli Zaretskii <eliz <at> gnu.org>, 59956 <at> debbugs.gnu.org
Subject: bug#59956: 29.0.60: Failure when completing arguments in Eshell after variable interpolation
Date: Mon, 19 Dec 2022 10:04:51 -0800

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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.