Feature: string filtering for code completion [Patch attached]

[Eduardo Robles Elvira]

On Thu, Jul 15, 2010 at 4:25 PM, David Nolden <zwabel at googlemail.com> wrote:
> 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

Hello everyone:

I'm glad you people like the idea. I think the key point here would be
to try to create a way to trigger this new kind of code completion in
the most user-intuitive possible way. I would say that perhaps adding
some widgets to let the user change the behavior of the code
completion as in "Quick open.." would be nice. Perhaps show an action
button for each kind of completion, and those action buttons should
use KAcceleratorManager::manage() to get accelerators. That solution
makes the interface user-intuitive, easy to use with the keyboard, and
as Milian said, introduce new shortcuts only _while completion list is
shown_.

Regards,
   Eduardo RE