I recently migrated to use VSCode when coding in Rust, but just because the Language Service for Rust the client side is implemented for VSCode since it has the LSP specification more updated compared from other editors out there.
For other languages that I use more frequently (Python, C, Janet, Carp and Zig), I still use Atom, because it has support for native support tree-sitter highlighting. Tree-sitter is a technology that allows to have more powerful parser, commonly used, but no limited, to highlight code, it has a more performance than regex based highlight engines and can do partial update of the code Abstract Tree, so it can update fast enough to update the code highlight as the user insert more code, it also has the advantage that is easier to maintain a highlighter for a given language than a using textMate grammar
Because the the devs for the tree-sitter support for languages try to get as much close as possible on what would be the high level parser of a language, it can tokenize more stuff easily than textMate highlighters. It gets much more close to a Semantic Highlighting because of that.
My hope is that VSCode natively implements tree-sitter for highlight code, since Github uses a lot tree-sitter and now that Github belongs to Microsoft. When it happens (if it happens) I can fully migrate to VSCode like I want to.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I recently migrated to use VSCode when coding in Rust, but just because the Language Service for Rust the client side is implemented for VSCode since it has the LSP specification more updated compared from other editors out there.
For other languages that I use more frequently (Python, C, Janet, Carp and Zig), I still use Atom, because it has support for native support tree-sitter highlighting. Tree-sitter is a technology that allows to have more powerful parser, commonly used, but no limited, to highlight code, it has a more performance than regex based highlight engines and can do partial update of the code Abstract Tree, so it can update fast enough to update the code highlight as the user insert more code, it also has the advantage that is easier to maintain a highlighter for a given language than a using textMate grammar
Because the the devs for the tree-sitter support for languages try to get as much close as possible on what would be the high level parser of a language, it can tokenize more stuff easily than textMate highlighters. It gets much more close to a Semantic Highlighting because of that.
My hope is that VSCode natively implements tree-sitter for highlight code, since Github uses a lot tree-sitter and now that Github belongs to Microsoft. When it happens (if it happens) I can fully migrate to VSCode like I want to.