Re: Regression in braces completion

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 12,  8:42pm, Peter Stephenson wrote:
}
} There will be an underlying reason why this particular case inserts the
} brace in the wrong place.  It will take many hours of work to find out.

It's not really "this particular case".  The brace ends up in the
wrong place in the following examples too:

schaefer<508> ls abc{g,d<TAB>
schaefer<508> ls abcdef{g,

schaefer<516> cd ..
schaefer<517> ls dta/abc{d<TAB>
schaefer<517> ls dta/abcdef{

Seems to happen any time there's a longer unambiguous prefix possible.

In order to find the possible completions of the rightmost expansion
of the brace expression, the C code removes everything between the
brace and the comma, inclusive, and then asks the completer (which
happens to be _path_files) for the matches.  It's not expecting the
completer to modify the command line as a side-effect, but that's
what happens when "compadd -U" is called.

Is there a reason you think it's deeper than that?

This one is interesting, though:

schaefer<518> ls dat/abc{d<TAB>
schaefer<518> ls dta/abc{def/
Completing corrections
abcdef/   abcdefg/
Completing original
dat/abcd

Note that it's wrong about what the "original" string is, and sort of
wrong about what the corrections are, because really the correction is
"dat" --> "dta" ... but in this case the brace is in the right place,
and menu completion cycles through:

schaefer<518> ls dta/abc{def/
schaefer<518> ls dta/abc{defg/
schaefer<518> ls dat/abc{d

Looking at _complete_debug output, this seems in part to be because
with the misspelt "dat" in front, "dta/abcghi" remains a candidate
match until later in the process.

It helps, when testing this stuff, to remove _expand and _oldlist
from the completer style.

--