Nathan Ridge

> Hi, I just wanted to chime in and say that I implement this in my fork ([rolandbernard@4f2c9f3](https://github.com/rolandbernard/vscode-clangd/commit/4f2c9f3f7aa65f129b7e7b424719a7c4f4eec548)) This is really neat! It's the same high-level idea that I was...

@rolandbernard I looked through your patch. One thing I'm curious about is `replaceInactiveRanges()`: is the purpose of changing the token type to `inactiveCodeTokenTypeReplaceIndex` that we know that vscode will not...

> Yes, I choose `inactiveCodeTokenTypeReplaceIndex` to be outside the range of token types that are in `capabilities.semanticTokensProvider.legend.tokenTypes`. It seems vscode ignores them, but I have no idea if that is...

@rolandbernard I updated the PR to make use of the techniques from your patch to preserve the client-side coloring, hope that's cool (I added a comment to credit you). The...

> My conclusion is we should back up and try again: > > 1. remove inactive regions from syntax highlighting as a failed experiment. > > 2. keep the implementation...

I agree that conceptually, a separate protocol for inactive regions makes more sense. The two reasons I see as most convincing are: 1. Granularity (line vs. token), including the possibility...

> 2. The usefulness of combining the inactive style with token colors. (Maybe, in the distant future when we can get clangd to build an AST for all preprocessor branches,...

I guess, for completeness, it's worth noting that a downside of the dedicated protocol is that we lose the ability of other clients to have _some_ styling of inactive code...

> Any progress about this pr?@HighCommander4 It's on my list to implement the approach described in [this comment](https://github.com/clangd/vscode-clangd/pull/193#issuecomment-1045292152) but I haven't gotten to it yet. Hope to get to it...

Sorry folks, I haven't gotten to this, and I'm not likely to for several more weeks as I'll be travelling. If someone would like to take this over, you're very...