Re: Regression in braces completion

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 13, 10:04am, Peter Stephenson wrote:
} Subject: Re: Regression in braces completion
}
} It's certainly possible that the code that takes account of braces in
} the case of compadd -U isn't present because it's never been tested
} before, but that would be bug: the C code takes pains to hide the
} existence of the braces from the rest of the system

The direct effect of -U (if the doc is remotely descriptive of the code)
is to cause matching of the returned words against the command line to
be skipped, so perhaps the code that handles braces is embedded in the
compresult code that performs matching.

The usual indirect effect of -U is that the the word on the command
line is thrown away and replaced entirely with the result from compadd,
which does look like what's happening here.  Maybe all that's been lost
is the position at which to re-insert the brace, but I'm betting that
this comment above cline_str() is significant:

/* This builds the unambiguous string. If ins is one, it is immediately
 * inserted into the line. Otherwise csp is used to return the relative
 * cursor position in the string returned and posl contains all 
 * positions with missing or ambiguous characters. If ins is two, csp
 * and posl contain real command line positions (including braces). */

Comparing walkthroughs of cline_str() when ins==1 for the correct case
(-U removed from compadd) and the incorrect case, the difference is at
line 240, where in the correct case li==3 and in the incorrect li==0.
The value for li comes from l->prefix->llen, which must be the result
of the call to cut_cline() on line 175.

I've run out of time to spend on this, but I suspect that the effect of
the -U option is to cause cut_cline() to decide that nothing that was
already on the line is worth keeping, when really in this case we want
to keep the first three characters up to the brace.

However, I'm not sure the C code is actually wrong here.  Postulate a
completer that given "abcd" as the thing to match, returns "zyxw" and
uses compadd -U to say "accept this as a completion even though it does
not look like what you started with."  Now call that completer for a
line with "abc{d".  Is the right answer really "zyx{w" ?

} so there's no way you can treat this as a special case anywhere else

I wasn't suggesting treating this as a special case, I was suggesting
that _path_files treat a spelling correction in the path prefix as a
special case.  That's the stated reason why _path_files is using -U.

In fact _path_files probably ought to bail out in the case where it has 
corrected the path prefix and make the user confirm that the correction
is, well, correct, before it goes on to guessing about stuff further
along in the path.  The trouble most likely is that we're trying to do
too many things in one go.

Of course if we change that, someone will complain that what used to
need only one tab now needs two, but this may be a case of lesser of
evils.  Or there may be an entirely other way of solving this, such as
adding the entire paths including the correction as separate matches
so that the point of ambiguity is much farther to the left.  In any
case if you agree that the C code behavior for -U is correct, then the
right fix is something that eliminates the -U from _path_files by using
another approach for the original auto-correction problem.