modularity for the developer
This article will focus on some of its benefits, which, in my opinion, are the most important for the end user.
Native LSP client
Language Server Protocol
LSP — a protocol for interaction between a code editor (most often) with a programming language server, which allows to implement such functions as auto-completion, jump to definition, call hierarchy, and much more.
In 1798, the US government contracts Eli Whitney, private tutor and inventor of the cotton gin, the first efficient cotton-refining machine, to make 10,000 muskets.
It is worth noting that Eli never made muskets in his life, nevertheless, in January 1798, he received a contract for the delivery of 10-15 thousand muskets in 1800
Despite the fact that Mr. Whitney was smart, he never made a weapon, but he had an advantage: he saw a problem – a lack of standardization. It’s hard to imagine, but then each copy of the weapon was unique, the gunsmiths simply did not have any clear standards or patterns. Whitney found this method of making weapons ineffective and managed to change it. Already in 1801, the inventor presented 10 identical guns to the US Congress, disassembling them, he reshuffled the constituent parts. They fit, they were interchangeable… Congress, by the way, liked the idea, and ordered to standardize all the equipment of the US troops.
About the contract
He completed the order only in 1809.
I don’t think I need to say how successful this idea was.
We are transported into the not so distant past. Most often, when working in a code editor, you would like to see code completion or diagnostics. Previously, in order to ensure the independence of the utility that would deal with this, it was necessary to do something like this:
-
Write the utility itself, which will be responsible for the necessary interactions with the code.
-
Write adapters for every popular code editor or IDE.
And you do it, simply because you want to popularize your utility.
In 2015, Microsoft invents the LSP for its Visual Studio Code editor, which would later become an open standard.
Now, if you write a cool autocomplete utility, there is no need to support a large number of editors, because there is standard… Users also benefit as they will no longer suffer from the quality of the interlayers.
This is how standardization and interoperability came into the world of code editors.
Tree-sitter support
About the tree-sitter itself
Tree-sitter provides a parsing system for many programming languages that is efficient enough for on-the-fly parsing. Also has a built-in library for syntax highlighting.
How do you feel about syntax highlighting? I’m good, it’s convenient when writing, for navigation, however, I don’t think it requires an explanation. Therefore, syntax highlighting is as important as its quality. The problem is that it is very difficult to develop well the syntax highlighting of most programming languages within the development of a code editor, too laborious.
The solution is to shift this task to a separate library.
Syntax highlighting tools should be developed separately from the code editor and should be universal, this will provide first-class syntax highlighting even in less popular editors.
By the way, tree-sitter is also used for syntax highlighting by GitHub and in the Atom editor.
Lua
Historically, Vim has supported (de facto was a kind of interpreter) its own programming language like Vim Script. But the fact is that it is quite difficult to maintain and develop a separate language as part of a code editor project.
Lua, on the other hand, is a small and fast embeddable language, which is just enough for configuring the editor and writing plugins.
Bottom line — modularity
The result is a remarkably extensible editor, whose developers can focus on developing the editor itself rather than just another programming language or maintaining rulesets for syntax highlighting. Users also received an editor that supports modern development tools.
