On Tue, Jun 17, 2014 at 5:18 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> What bash does is annoying and stupid, and any time I find a system
> with that obnoxious behavior enabled I immediately disable it, so I
> don't consider that a good precedent for anything.
I happen to totally agree with you here. Bash sometimes does awful
things with its completion.
>> Another issue is whether to print only those having exactly the minimum
>> observed Levenshtein distance, or to print everything less than some
>> cutoff. The former approach seems to me to be placing a great deal of
>> faith in something that's only a heuristic.
>
> Well, we've got lots of heuristics. Many of them serve us quite well.
> I might do something like this:
>
> (1) Set the maximum levenshtein distance to half the length of the
> string, rounded down, but not more than 3.
> (2) If there are more than 2 matches, reduce the maximum distance by 1
> and repeat this step.
> (3) If there are no remaining matches, print no hint; else print the 1
> or 2 matching items.
I could do that. I can prepare a revision if others feel that's
acceptable. My only concern with this is that a more sophisticated
scheme implies more clutter in the parser, although it should not
imply wasted cycles.
What I particularly wanted to avoid in our choice of completion scheme
is doing nothing because there is an ambiguity about what is best,
which Tom suggested. In practice, that ambiguity will frequently be
something that our users will not care about, and not really see as an
ambiguity, as in my "o.orderid or ol.orderid?" example. However, if
there are 3 equally distant Vars, and not just 2, that's very probably
because none are useful, and so we really ought to show nothing. This
seems most sensible.
--
Peter Geoghegan