Feature: string filtering for code completion [Patch attached]
mail at milianw.de
Thu Jul 15 13:09:17 UTC 2010
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:
- 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
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
What do you think?
mail at milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the KDevelop-devel