Feature: string filtering for code completion [Patch attached]

[David Nolden]

2010/7/15 Milian Wolff <mail at milianw.de>:
> On Thursday, 15. July 2010 14:42:11 David Nolden wrote:
>> I guess we definitely shouldn't _always_ do this, because in many
>> cases it might also be unexpected, and also as you say in the comment,
>> it's slow. How slow it is depends on the size of the completion-lists,
>> but we want to be compatible with really long completion lists (at
>> some point we'll also start adding macros to the list, for example).
>>
>> A separate shortcut also wouldn't be nice I think. To me it seems like
>> the best solution if we'd allow specifying specic filters during
>> completion using some special character. For example:
>>
>> test.*QString : Filter the list for everything that contains "QString"
>> in an arbitrary position.
>> test.r*QString : Filter the list for everything where the "return"
>> type contains QString
>> test.a*QString : Filter the list for everything that has QString in
>> its arguments
>>
>> And similar. The tricky part would be finding a syntax for the
>> special-character that doesn't break our completion-model controllers
>> (the range has to be set correctly so that it doesn't skip the
>> character), and making sure that the character combination is invalid
>> syntax in any possible programming-language, so we don't trigger the
>> filtering accidentally.
>
> While I like the idea of writing something to trigger the filtering, what about
> this idea which right now seems to be even better in my mind:
>
> introduce new shortcuts _while completion list is shown_.  The reason is this:
>
> foo.
>
> - the "dot" triggers automatic code completion
> - all items are shown
> - I want to find some method, now with your approach I'd have to write either
> n* to find a name. When I see that this was the wrong approach, I'd have to
> delete both and change it to e.g. r* or a*.
>
> If otoh there would be a shortcut we could do this:
>
> - press $name-shortcut, insert identifier
> => filtered on names
> - I notice it was wrong, press $argument-shortcut, the identifier I inserted
> stays the same and I get just an updates list of items that now match based on
> their arguments.
>
> I think this might be faster than the n* or similar approach. Furthermore it
> would not mess with Model ranges and we don't need to care about finding a char
> that never is used in any programming language (which imo is an impossible
> task).
>
> What do you think?

The problem with shortcuts is that they are not context-dependent,
conflicts are possible, and just because I want the already visible
list filtered differently, I wouldn't like to push something like
CTRL+ALT+I. I'd rather just push "*". Especially having different
$name-shortcut, $argument-shortcut, etc. would add a plenty of new
shortcuts into our already huge shortcut-list.

I like the idea of using "*", because it can be associated with
wildcard-matching, which at least is somewhat similar. If we'd trigger
it only when there is no whitespace before and after the character,
maybe we could prevent real-life conflicts with normal written code.
Maybe we should only trigger it when the user already started manual
completion through CTRL+space, because automatic completion generally
serves just the purpose of making the writing faster, and this seems
more like a way of information-retrieval.

This scheme would be even better:

test.*QString    -> Filter everything for QString
test.*QString*n -> Filter name column for QString. You can do the
initial filtering, and if it isn't specific enough, you can tighten it
by adding *n .

I think we wouldn't have problems with completion-ranges, because we
simply wouldn't inform the completion-models as soon as the * was
entered.

The cool thing is that, with time, we could easily add additional more
powerful filterings, by adding new strings behind the second star.

For example (just for the far future):
test.*QString*rc    -> Filter everything where the return type can be
converted to QString through type-conversion
test.*my*nv -> Filter for all variables that contain 'my' in the name
test.*Q*nc -> Filter for all classes that contain "Q" in the name
test.**c -> Filter for all classes
test.*QString*rc|*get*n  -> Combination of multiple filters: Filter
everything with a return-type that can be converted to QString, and
where the name contains "get".
test.*QString*rc|*QString*a1c -> Combination of multiple filters:
Filter everything with a return-type that can be converted to QString
and where the first argument can be converted to QString
test.*1*a  -> Filter for all functions that take one argument

And so on.

Greetings, David