Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's a very high percentage for syntax highlighting itself (which is most of Vim's focus) if you include the deep extension library. The primary tokenizer VS Code uses for syntax highlighting is based on the TextMate Grammar format [1], which is a pretty wide industry standard of sorts today. A lot of grammars have already been expressed in TextMate Grammar format at least somewhere. The TextMate Grammar format is conceptually very similar to vim's: it mostly keys off of simple regular expressions to define token boundaries. The biggest difference is that TextMate Grammars are expressed as declarative JSON files and vim syntax grammars are expressed in vimscript. The vast majority of vim syntax grammars are very easily convertible to TextMate, though vimscript is Turing complete and there are some strange ones out there.

Today VS Code also allows for Language Server processes to entirely delegate syntax highlighting as well, if you do need a very custom turing-complete tokenizer. (More accurately, it is included so that Language Servers can share the tokenizer work they are already doing as part of their parsing and processing efforts rather than duplicate that effort in a TextMate Grammar.)

Wrapping a TextMate Grammar in a VS Code extension is one of the easiest types of extension to build for VS Code, it's just the grammar JSON file and a couple lines added to an appropriate package.json file added to a ZIP file that then ostensibly resembles an npm package.

Deeper projects such as Language Servers start to get complicated quickly, but also are where a lot of power that VS Code has that vim is starting to import the other direction: many neovim users rely on Language Servers ostensibly built for VS Code first for an increasing number of language features.

[1] https://code.visualstudio.com/api/language-extensions/syntax...



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: