Syntax highlighting is a waste of an information channel

[clankill3r]

I noticed when using zls in VSCode that there was suddenly syntax highlighting. Not sure if zls was responsible or the vscode extension for zls, but I'm hoping it was zls itself cause then the issue I raise up spans a wider dimension.

I readed this article and I founded it very interesting, and before continueing to read my post, I ask you to read this article:

https://buttondown.email/hillelwayne/archive/syntax-highlighting-is-a-waste-of-an-information/

I was thinking, it might be interesting to see what the ideas of the article could mean for zig. I would love to hear others people thoughts on this, and if zls could indeed provide some of the functionality described.

[faraazahmad]

That seems like a great set of ideas! And I think it's more of a specialised usecase. Like a superpowered grep. I could imagine adding these features to the find command of a text editor

[matu3ba]

Lets go through all proposals step by step to see what should be done in the 1. lsp (global semantic information) vs what can be done in 2. treesitter (local scoped information) or what has 3. simpler workarounds:

I do assume all stuff should also work with comptime for a given input configuration (later to be extended). I do also assume that the lsp has a query format for exposing the data (which as of today it has not).

1. Rainbow parenthesis (https://github.com/p00f/nvim-ts-rainbow) works today with treesitter, but is too slow on smooth scrolling due to sheer amount of queries (you get lags). => treesitter
2. Context Highlighting (https://github.com/polarmutex/contextprint.nvim) works today with treesitter and it only shows syntax differences (no global information) => treesitter
3. Import highlighting Comptime conditional imports must be resolved => lsp
4. Argument Highlighting A variable that is not in scope is global (or bears a compile error). Aliases require caching, but are not too complex. => treesitter
5. Type Highlighting Comptime stuff can not be resolved without lsp => lsp
6. Variations (fns with try-blocks, user-defined errors, raise/catch specific error) global information => lsp
7. Metadata highlighing (fns with and without precondition ?or verification tag?, which are part of certain stacktrace, in current branch but not master) erecondition and verification tag is a scope-local syntax information => treesitter, stacktraces => ambiguous what is meant, not in master branch => git information + simple algorithm is sufficient (https://github.com/lewis6991/gitsigns.nvim)
8. Random ideas Transitive calls involves reachability analysis which may become arbitrary slow (alot and uncached information). The other things are either for 1. a linter, 2. can be implemented as treesitter queries or are 3. git-specific.

What remains are

1. comptime resolving import highlighting and type highlighting (showing inlay hints etc),
2. error handling (errors can be inherited, so must be globally analysed): specification of query format or of the indexing format for exposing the error data (errors describe the control-flow graph, which is complex and better to analyse in another plugin?)

Personally I think there should also be a program that indicates in the unsaved buffer if and if not incremental compilation will break on changes. This program would likely need to query global semantic information from the lsp via editor, but I am unsure how complex this would be.