Feature: string filtering for code completion [Patch attached]

[Milian Wolff]

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?
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100715/ecafd35d/attachment.sig>