tree-sitter VS gitsigns.nvim

I learned from a google search that these days upstream tree-sitter provides WebAssembly bindings.

Source: https://github.com/tree-sitter/tree-sitter/tree/master/lib/b...

NPM: https://www.npmjs.com/package/web-tree-sitter

Download from the latest Github release: js file (https://github.com/tree-sitter/tree-sitter/releases/download...) and wasm file (https://github.com/tree-sitter/tree-sitter/releases/download...)

Tree-sitter optimizes for performance (to use in editors), not for correctness. In fact even TS' core developers advocate for not bothering too much with correctness of grammars[1]. I imagine this constraint would be a deal-breaker for GitHub or anyone else in their position.

[1] https://github.com/tree-sitter/tree-sitter/issues/130#issuec...

This is a plugin that provides a simple way to use the tree-sitter in Neovim and also provides functionalities like highlighting, etc.

From the tree-sitter side, I am tracking https://github.com/tree-sitter/tree-sitter/issues/1942

Is tree-sitter really slower than TextMate grammars? Some benchmarks indicate that this isn't really the case [1]. On the other hand, breaking parse trees is a real issue, because the error-recovery in tree-sitter is pretty rudimentary [2][3], but as you said, it's not an issue for Shiki.

Several TextMate grammars suffer from inaccuracy bugs, and issues of maintainability. Perhaps the biggest hindrance in the adoption of tree-sitter, is that the most popular editor, VSCode, still doesn't support it.

[1]: https://github.com/microsoft/vscode/pull/161479

[2]: https://github.com/tree-sitter/tree-sitter/issues/1870

[3]: https://github.com/tree-sitter/tree-sitter/issues/224

u/lewis6991 I think the biggest performance gain was made by tree-sitter itself: https://github.com/tree-sitter/tree-sitter/pull/2085

I asked on the repo's discussions but responses are limited and not explanatory (I'm not shaming anyone here, discussions aren't a place for detailed how-tos and documentations anyway).

The following discussion here. TS query cannot be incremental, that is why I regard it as design fault.

Hi, so I've recently decided to give Neovim yet another try, this time using some predefined plugins with kickstart.nvim, for syntax it uses tree-sitter.

those are gitsigns. read :h gitsigns-highlight-groups. i think the first 3 ones (gitsignsadd, gitsignschange, gitsignsdelete) would need their background cleared.

I have installed Gitsigns in a Windows machine and when I execute the method diffthis it thinks that the new lines are differences.

Lack of tooling/LSP support compared to Lua. A rather popular neovim plugin, gitsigns, recently switched from teal to regular lua for (among other reasons) the tooling.

https://github.com/lewis6991/gitsigns.nvim/commit/4d63d996b0...

gitsigns.nvim

The closest one would be gitsigns

you can use gitsigns

https://github.com/lewis6991/satellite.nvim absolutely amazing choices, visual economy, integration with gitsigns and builtin vim features (marks).

It's also nice to ask him directly.

For a long time, I have been searching for solutions for asynchrony in Neovim, but what interested me the most was the one provided by gitsigns.nvim. Therefore, I decided to turn it into a separate module to make it easier to use async in Neovim. I have already created some usage examples.

Oh, the symbols are provided by gitsigns.nvim and I have set :h statuscolumn so that they appear to the right of the line numbers. The settings are done in plugin/statuscolumn.lua. I put custom single-file scripts under plugin and ftplugin, where they serve as light-weighted mini plugins, you can even find the prototype of deadcolumn.nvim there :)