Re: cc-mode fontification feels random

[Jim Porter <jporterbugs@gmail.com>]

On 6/5/2021 5:27 AM, Eli Zaretskii wrote:
>> Cc: joaotavora@gmail.com, jporterbugs@gmail.com, ubolonton@gmail.com,
>>   theo@thornhill.no, emacs-devel@gnu.org
>> From: Daniel Colascione <dancol@dancol.org>
>> Date: Sat, 5 Jun 2021 04:55:21 -0700
>>
>> Fewer than running a remote Emacs: you don't interact with Tramp on each
>> keystroke. There are tons of advantages to Tramp; it's a first-class
>> feature and it's worth making language server support work properly with it.
> 
> No argument that we need to support that properly.  This sub-thread
> started when someone said it would probably be slow with Tramp in the
> loop.

Just to clarify: it may turn out that communicating with a remote LSP 
server is fast enough for this purpose. However, if performance issues 
do crop up, they'll be more severe with TRAMP. Having used Eglot over 
TRAMP on a fast connection (within a LAN), nothing jumps out as 
annoyingly slow, although the things I use LSP for aren't 
latency-sensitive. It might be worth collecting some numbers on this to 
see how slow it really is.

(As mentioned elsewhere in the thread, I'm very happy with how Eglot 
works with remote files currently, since it means that my dev tools for 
a particular environment can live on the same system as my source code. 
Having to run the appropriate LSP server locally to edit remote files 
would be inconvenient, although I suppose I could tolerate it.)

Looking into this a bit more, I'm not actually 100% sure how much VSCode 
(or other LSP-aware editors) use LSP for syntax highlighting today. 
Semantic tokens are only available in the most recent specification of 
LSP (3.16)[1], so many LSP clients/servers likely wouldn't be using this 
yet. It might be helpful to see what they were doing prior to this; 
there may be some relatively non-invasive changes that could improve things.

Perhaps there's a way to use something like tree-sitter (or even cc-mode 
as it currently stands) to get 90% of the way there and then augment 
that with results from the LSP server. For example, to address the 
original post, it seems the main issue is that cc-mode doesn't know 
what's a type and what isn't. If we could get type information from the 
LSP server, then cc-mode could take that into account. In the example, 
we could even rely on the fact that `std::variant' takes types as 
arguments, so we know that the arguments are types (or the code is 
incorrect).

- Jim

[1] 
https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_semanticTokens