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

Previous Next

Package: emacs;

Reported by: Jim Porter <jporterbugs <at> gmail.com>

Date: Sun, 11 Dec 2022 01:27:02 UTC

Severity: normal

Found in version 29.0.60

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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





This bug report was last modified 2 years and 202 days ago.

Previous Next


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