[MonoDevelop] Code Completion guts

[John Luke]

On Fri, 2004-04-23 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
> understanding:
> 
> 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
> 
> 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.

A few potential problems with the above:
- I don't really think you gain much by diverging from SharpDevelop here
- make sure you don't break anything that other languages would need
  (which changing ICompletionDataProvider may or may not do)
- I thought we were just going to have a downloadable db, and that way
the generation would become completely optional (and secondary) anyways?

I would personally like to have more of the details of what the overall
plan for code-completion generation is on the table.