>> Is there a simple way to disable this "type-matching" and if not, what
>> piece of code is responsible for it?
> On a per-tool basis, it might make sense to have a "get completions
> list", and a second "ask harder" phase. Each tool would need to decide
> how it wanted to do that. I can provide the feature if there are tools
> that could use it well.
This is how, without really knowing how it works, I think that completion should
The text just before point establishes the lookup "namespace". For example:
x = partial<completion>
triggers completion on the top-level namespace, searching for symbols starting
with `partial'; while
x = something.partial<completion>
and the like (e.g., something->, depending on language) trigger completion on
the something namespace, same prefix.
Nothing new here.
Then, three possible types of matches should be returned:
1) those that have a return type equal to that of `x' (when known)
2) those that have a return type that the language allows to implicitly cast
into the type of `x' (when known).
On a perfect world, explicit casts should also be detected an possibly
treated as in case 1.
3) those that have no known type; e.g., preprocessor macros in C/C++, in the
case their return type is not known (which is not necessarily true), or
everything in the selected namespace that has the `partial' prefix if the
type of `x' is not known.
This case would provide a sane fallback when information is incomplete, which
should be refined as the language parser matures, or simply means that the
language symbols are inherently untyped (e.g., "duck-typing" languages like
lisp or python).
Whether this approach is disruptive or not given the current infrastructure, I
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom