MonoDevelop addin: Plumbing and autocompletion

[nerdzero]

For comments and doc strings, I'm not sure what the best way to do it would be either. I wouldn't want to slow down the parser any since this wouldn't be particularly useful for actually compiling code.

For the blank line, that's exactly what I ended up doing so I'm glad you had the same idea. My implementation felt hacky though. It's a style issue at this point I suppose. I'll refine it until I convince myself it's good.

Hmm...thinking about it a bit on the drive home from work, I foresee a problem with line continuations even with an .endingToken. If I'm not in the first line of a existing method declaration that spans multiple lines, I'm going to have to know that so variables declared in the method body aren't displayed as proposals. I'm getting ahead of myself. I'll cross that bridge when I get there. .endingToken will still work for the common line continuation case and for non-indented namespaces so I'm looking forward to that.

[Charles]

I wouldn't worry about it slowing down the parser. For one thing, it could be an option which means the only overhead when it's not in use would be checking a boolean which is negligible.

It also occurred to me that doc strings in the compiler could be instances of a DocString class which would hold the .text, .token and .endToken. That still doesn't help with comments, but then the "side-effect list" I proposed could be comprised strictly of comments and nothing else since nodes keep a reference to their doc strings (currently typed as String).

So just thinking out loud here. Mull it over and let me know what would help.

Also, I got .endToken started (no point in calling it "endingToken" like I originally wrote) in changeset:2850. It always returns something and proper implementations are provided for types and various members. I still need to review enums, multi-line expressions, etc. but you can start using it now.

[nerdzero]

Cool. I'll get crackin' on this. I'll think about comments and doc strings, too. Does the tokenizer keep around the list of tokens it consumed after the parser finishes or does this list get cleared?

[Charles]

At the beginning of parsing, the parser gets a list of tokens from the tokenizer, which it then works through. I don't recall if it keeps the list at the end of parsing or not, but it would be no big deal if we wanted to keep it.