<div dir="ltr"><div dir="ltr">Sounds great, Jan.<div>This has been one of those things we'd hoped to get around to, but never quite made it to the top of the pile.</div><div>The protocol looks pretty sensible to me. I'm a bit nervous that there doesn't seem to be a high-quality VSCode implementation to check our work against yet - I guess we can use Theia.</div><div>Still, I think the best way to start is go ahead with a minimal implementation (without worrying about deltas etc yet) to demonstrate it'll work.</div><div><br></div><div>Some issues to think about:</div><div><br></div><div>What's the basic implementation idea? Traverse the main-file AST after every edit, collect spans, diff them at the end? Do we do this synchronously as part of the diagnostics cycle? Latency seems likely to be ~1 second with this approach, and never under 500ms (because of the debouncing of continuous AST rebuilds).</div><div>I don't see something fundamentally better, other than tracking dirty regions and only traversing decls that intersect them. My intuition says that wouldn't save much, as we have to build the whole AST, which should be much slower than traversing it.</div><div><br></div><div>What to do before first parse? (In particular when preamble is slow)</div><div>I guess the client could fall back to its standard heuristic-parsing-based highlighting, use of TextMate scopes seems to suggest that.</div><div>An alternative: for more uniformity/control, we could instead implement such parsing on the server side as a cheap fallback when ASTs aren't available. There may be other reasons to have such a heuristic parser. Probably doesn't make much sense to worry about initially.</div><div><br></div><div>How are re-highlights around the cursor going to feel in practice? I think there's a danger that if we highlight highlighting partially-formed expressions from a more-or-less-random point in editing, and the editor fills in the gaps, then we'll end up with basically random flashing colors on the line being edited.</div><div>We should probably wait and see how it feels after a first implementation. If this is an issue, one idea would be to attempt some low-latency highlighting of the edited section (using heuristic parsing and/or the old AST) while we wait for the AST rebuild.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 16, 2019 at 12:08 AM Jan Korous via clangd-dev <<a href="mailto:clangd-dev@lists.llvm.org">clangd-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I am starting to work on semantic highlighting in clangd.<br>
<br>
There's currently no mention of that in LSP but it seems like this proposal is on the right path to get accepted:<br>
<a href="https://github.com/Microsoft/vscode-languageserver-node/pull/367" rel="noreferrer" target="_blank">https://github.com/Microsoft/vscode-languageserver-node/pull/367</a> <br>
<br>
TLDR: the proposal introduces new capabilities and server notification.<br>
- New client boolean capability flag.<br>
- New server capability - server shares a lookup table of semantic categories with client in response.<br>
- Semantic categories are defined by TextMate scopes. <a href="https://www.sublimetext.com/docs/3/scope_naming.html" rel="noreferrer" target="_blank">https://www.sublimetext.com/docs/3/scope_naming.html</a><br>
- Server sends notifications containing line number, column number, length and semantic category (index in the lookup table).<br>
- Server is responsible for sending only delta information (not full document every time).<br>
- Server is responsible for ignoring trivial shift edits to documents (e. g. newline at the start of the document).<br></blockquote><div>I think you mean *client* is responsible for that last one.</div></div></div>