Re: _approximate doesn't work

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Feb 19, 10:19am, Peter Stephenson wrote:
} Subject: Re: _approximate doesn't work
}
} On Tue, 19 Feb 2008 00:29:35 -0800
} Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > Looking through the output, PREFIX gets set by the replacement
} > compadd created via _approximate -- but that doesn't happen until
} > *inside* the call to _wanted, long after the test in _path_commands.
} 
} [...] this is an extremely general problem.  Very many completion
} functions assume quite reasonably that testing PREFIX tests what the
} completer is trying to match.

I just looked through "grep PREFIX Completion/**/*(.)" and I don't
think there are very many functions that use PREFIX as a pattern in
the way that _path_commands does.  Most of them test another pattern
against $PREFIX, to determine context based on what $PREFIX contains.

The real, more general problem IMO is that we've allowed the lines of
responsibility to become way too blurry.  The original idea (ISTR)
was that the completion functions (as opposed to "completers", or
what the manual calls "control functions") would generate a large
set of possible completions and then compadd would filter them down
to the actual matches, because only compadd knows enough about the
internal state of the shell to do so.

This gets compromised for performance reasons (e.g., if we know an
entire directory path, limit file names to those in that directory)
but the early functions were careful to do this only with the parts
of the command line that were already unambiguous.  That is not, in
general, true of $PREFIX.

The job of a completer is to figure out the context and supply the
corresponding tags.  The job of a completion function is to enumerate
all the possible strings for some subset of tags.  The job of compadd
is to reduce that set of strings to the actual completions.  As soon
as either of the functions starts crossing those boundaries, there's
a potential problem, and it better be happening for a good reason.
 
} Perhaps we need to make approximation/correction more visible by
} introducing parameters that are local to the completion system and
} only contain text in the appropriate case (e.g. APPROX="(#a1)")?

It may be that approximation is worthy of addition to compset/compadd.
The fact that _approximate has to create a dummy compadd function in
order to be implemented, argues in that direction.  However, I still
think _path_commands was wrong to pre-filter on $PREFIX.