[MonoDevelop] Rethinking the "toggle completion categories" command

[IBBoard]

On 09/01/11 05:48, Michael Hutchinson wrote:
> I've been finding the completion filtering mildly annoying because
> it's very easy to toggle it on accidentally by hitting "control-space"
> while the completion window is open. I don't like having the feature
> always enabled, because it alters the sorting and makes filtering feel
> very strange because the list is not alphabetical, though I understand
> some users do like to keep it always enabled. However, I do like to be
> able to use it occasionally - and when I do, I usually use Shift-Down
> or Shift-Up to enable it (but then get annoyed by having to toggle it
> off when I'm done).
>
> We had a long discussion last time about how to control this mode, and
> the solution wasn't completely satisfactory to everyone at the time.
> Now that we've had the command for some time, so people have some
> practical experience with it, I'd like to bring the discussion up
> again, and maybe we can find a better solution.
>
> I think that perhaps shift-space would be better, since I *think* it's
> harder to do that by accident, because it's not the key that triggers
> completion. It's also more consistent with shift-up and shift-down. It
> might be easy to hit it accidentally while typing uppercase chars
> right after spaces, though spaces are very rarely used *within* the
> completion list. Alt-space is used by the window menu on Windows, and
> it would be good to keep this consistent across platforms. tI wouldn't
> make it keybindable, as that would "use up" a keybinding for a feature
> that only works on one very limited context, and I don't think it's
> sufficiently important to be able to rebind this command.
>
> Also, if categorization is implicitly enabled by using shift-up or
> shift-down while it's disabled, it would be nice if it only stayed
> enabled as long as the list is open. Explicitly toggling it via
> shift-space would be persistent.
>
> Another point - sometimes categories are enabled but the list doesn't
> show categories, because there are no categories to show. But if we
> always showed some kind of category header, at least it would be
> clearer when the list is in category mode. This would also help to
> indicate to users that it's a mode, and not just happening randomly.
> I'm sure we could add categories for other contexts, such as "locals",
> "parameters", "templates", "keywords", "members", "types".
>
> Thoughts?
>

Michael,

That all sounds like a good idea and would suit my way of working as 
well. I'm in a similar situation that I don't use it but keep 
accidentally activating the grouping. Shift+Space seems close enough to 
not involve too much moving and similar enough to be memorable while not 
being too easy to accidentally do if you don't want it.

I think the "always group by something when we have grouping mode" is a 
good idea, as it would make it explicit what the current behaviour is. 
You mentioned alternatives of different types - have you looked at the 
Eclipse "content assist"? They have what they call "proposal kinds" for 
their auto-complete functionality. The default is to show everything, 
but you can also have filtered sub-sets (e.g. Java Type Proposals, Java 
Non-Type Proposals, Java Proposals, Template Proposals, etc). The 
proposals are filtering rather than grouping, but they are quite useful 
for similar reasons to what you're suggesting. For example, if I want to 
create a JUnit test then I type "Te", hit Ctrl+Space twice (brings up 
content assist then moves to Template Proposals) and the "Test" template 
is now top of the list, where as it would have been about a dozen items 
down in the first list it showed. If you want to check it out yourself 
then it is in Window > Preferences then Java > Editor > Content Assist > 
Advanced.

On the off-chance that I did ever want grouping (or if it became more 
like the Eclipse filtering and cycled options rather than just toggling 
grouping) then making it fall back to your default behaviour each time 
sounds like a sensible approach.

As with everything, once it gets implemented then I'll happily keep up 
with the Git head and test it :) I've already learnt that Shift+Up/Down 
exists just from this email.

My only thought with it not being key-bindable is whether something else 
somewhere will clash with it outside MD. From a quick search then 
OpenOffice.org seems to have had complaints about accidentally 
triggering it [1], and apparently some Mac apps use it for scrolling 
back up [2]. The main results appear to be app-specific, so it'd just be 
a change of convention rather than a collision, but there might be 
something.

Regards,

IBBoard

[1] http://www.oooforum.org/forum/viewtopic.phtml?t=26222
[2] http://forums.cocoaforge.com/viewtopic.php?f=18&t=6771