[Mono-dev] Completion refactoring?

Alexandre Miguel Pedro Gomes alexmipego at gmail.com
Sat Aug 13 19:00:26 EDT 2005

I've been looking into completion lately and I've a few questions,
comments and suggestions to do.

First thing to say is that I don't like the "new concept" of having
completion window under MonoDevelop.Base.Gui. I do believe that is
specific to the source editor widget.

Secondly, there is a lot of logic code inside the Source Editor; That's
bad! We are doing 2 things wrong in this topic, we are doing
"C#-parsing" and we are processing the completion there too - I had no
time to check, but I suppose boo, vb.net and other completion is done
somewhere else, where?

The problem is that there isn't anything better to know what and when to
show the help the user needs than the Language Binding itself.

So, here is my suggestion:
1. There should be a kind of SourceEditor Specification that states that
it should be able to show completion windows, insight-window and even
other 'tooltips'.
2. SourceEditor should be associated with a LanguageBinding and
interactively notify the LanguageBinding about current "iter"/caret
3. Based on that data the LanguageBinding can tell the Source Editor to
show "these completion options" or "this insight window", etc...
4. When the context is made invalid, LanguageBinding tell Source Editor
to hide the completion/... windows

Using this work-flow we win several things:
1. Better support to implement completion-information for new languages
2. Better abstraction enabling third-party Source Editor or, even,
Completion Window, etc...
3. New helper "tools", examples for C#:
* "Press TAB to implement event/interface/abstract class"
* Refactoring and Templates
* "Goto Definition"
* See only fit-able properties/methods for that method param/assign (ex:
foo (int a) would only show methods/properties/fields that return int
when completion opens in 'foo (')

I don't believe the current Language Binding can support that now and in
a easy way. Maybe we need a new class to do that?

Alexandre Miguel Pedro Gomes <alexmipego at gmail.com>

More information about the Mono-devel-list mailing list