REFRESH!

[Minesweeper] 68 Games Played. 44 Bombs Used. 9838 Moves Performed. 13 New Users

[Rubberduck] 7 Indenter requests. 2 Synchronizations

[Zomis/Games] 1 issues opened

[MDoerner/AdventOfCode2022] 235 additions. 60 deletions. 1 commits

Either all the goals weren't reached or it's been a loooooong night... :(

Yeah, not quite running smoothly yet, bit a little more than I could chew here 😅

Matt do you envisage some red squiggles being built into the editor and some coming from a language server? Some features don't need parsing to work? I hate my python editor is so laggy with it's language server suggestions, VBE has always felt very snappy and solid. I wonder whether the theoretical minimum latency LSP (given it runs in a separate process) will make it a challenge to keep things feeling sharp?

Where does syntax highlighting come from? And does intellisense require a full parse of a partial module?

@MathieuGuindon

@Greedo syntax highlighting is built into the editor, it works off simple regex-based rules. There's a simple parser in place, that just gets a parse tree (and syntax errors, plus a token stream rewriter), with listeners for syntax errors and block foldings - that parser runs on an idle timer.

That yields enough data to populate the members drop-down

But not enough to populate the left dropdown with the member providers

So we quickly get syntax error squiggles, and in theory we could run the parse tree inspections off the quick-parse too

The actual full parse with the resolvers isn't wired up yet though

Unsure if we're going to be porting it, or reimplementing it as some LSP

in any case the full parse will always run in the background

so some inspection squiggles will show up with a latency; same for the member providers /implemented interfaces, and any additional in-editor navigation tooling, like Ctrl+click GoTo definition, or navigate to interface/implementation

IntelliSense and ParameterInfo tooltips will need the full parse dataset

Although, a limited ParameterInfo tooltip could probably work off the quick-parse tree, for calls to members that are loaded in the editor

(lol, "limited" as in "pretty much what we get in the VBE")

Oh, and non-implemented members / event handlers won't show up until the interface is known, too - so ThisWorkbook and Sheet1 modules only get the members that exist in the module, until a full parse happens.

So the initial parse will probably still take a little while, but (assuming a port) for any module that's loaded in the editor it can just grab the existing parse tree, so there's that.

In any case, RD3 is much snappier than 2.x, partly because it doesn't do much yet, but there's a lot of stuff going on in 2.x constructors that's now being deferred, so even with all the features in I think we'll have a better startup time and overall experience.

I think we'll need custom syntax highlighting at some point, because dead code /unused variables and members can't appear dimmed with just a regex rule.

So, an additional text colorizer run needs to happen after a full parse

[rubberduck-vba/Rubberduck] 1679 stars vs. [decalage2/oletools] 2279 stars