[MonoDevelop] Code Completion guts
Fri, 23 Apr 2004 16:32:31 -0400
On Fri, 2004-23-04 at 23:34 +1000, Iain McCoy wrote:
> I'm trying to work out a way of avoiding the code completion database
> generation thang. Obviously, what I need is to pick up the code that
> reads from the database and produce an equivalent interface that doesn't
> hit a database.
> The problem is that this code is, quite frankly, a quagmire. Here's my
> src/AddIns/DisplayBindings/SourceEditor/CodeCompletion/ICompletionDataProvider.cs is not actually a completion data provider. It's just the thing you call to say "I've got this text and this cursor, what shall I suggest to the user". Ultimately, the data is actually pulled from the database by src/Main/Base/Services/ParserService/DefaultParserService.cs, which *also* handles parsing the file. That class implements an interface which provides *both* parsing and completion data lookup.
> My proposal:
> Ditch the ICompletionDataProvider interface. I can't see any reason for
> it to be an interface.
> Split the completion data provider bits from the IParserService
> interface; put them into ICompletionDataProvider.cs. Move the completion
> database access stuff out of DefaultParserService, put it in some class
> implementing ICompletionDataProvider.cs
Well, there is a reason for it :)
There are three completable data types right now, Code, Comment and
Template. Obviously right now we only implement one of the 3, however in
the future support for all three will absolutely be implemented.
CodeCompletionDataProvider.cs in that same dir is the place where the
parser gets called.
The reason it calls into the Parser, is that for this to work, it needs
access to the Resolver provided by the ParserService.
> I think that will make the system a little more sane. Assuming nobody
> tells me it's a bad idea, I'll do the refactoring in a few days.
Im not sure I see the point, but god created branches so you can show
> Iain McCoy <firstname.lastname@example.org>
> Monodevelop-list mailing list