
Nvim-colorizer.lua: The fastest colorizer for neovim (and no dependencies too) - ashkankiani
https://github.com/norcalli/nvim-colorizer.lua
======
recuter
While this seems like a nice effort the roadmap for Neovim has Tree-sitter¹
integration² planned for the next release (0.5).

Tree-sitter - A New Parsing System For Programming Tools

"Developer tools that support multiple programming languages generally have
very limited, regex-based code-analysis capabilities.

Tree-sitter is a new parsing system that aims to change this paradigm. It
provides a uniform C API for parsing an ever-growing set of languages. It
features high-performance incremental parsing and robust error recovery, which
allow it to be used to parse code in real-time in a text editor.

We're in the process of integrating Tree-sitter into both GitHub.com and the
Atom text editor, which will allow us to analyze code accurately and
efficiently, paving the way for better syntax highlighting, code navigation,
and refactoring." \-- Here's an interesting talk about it:
[https://www.thestrangeloop.com/2018/tree-sitter---a-new-
pars...](https://www.thestrangeloop.com/2018/tree-sitter---a-new-parsing-
system-for-programming-tools.html)

¹ [http://tree-sitter.github.io/tree-sitter/](http://tree-
sitter.github.io/tree-sitter/)

²
[https://github.com/neovim/neovim/pull/10124](https://github.com/neovim/neovim/pull/10124)

~~~
coldtea
> _While this seems like a nice effort the roadmap for Neovim has Tree-sitter¹
> integration² planned for the next release_

Well, one is an existing syntax highlighter one can install and use now, the
other is something new, we haven't seen, that might or might not come with the
next release.

Does anybody use it atm on any editor?

~~~
jchw
Tree sitter? It can be used with an extension in VS Code:

[https://marketplace.visualstudio.com/items?itemName=georgewf...](https://marketplace.visualstudio.com/items?itemName=georgewfraser.vscode-
tree-sitter)

It works just fine, although it is not a _massive_ improvement by any means,
from the dev experience we have today.

I do not know if any editors are shipping with it yet.

~~~
Liquid_Fire
Presumably also Atom and GitHub's online editor, for which Tree-sitter was
written.

------
cosmojg
Ahh, this is why I love Neovim: plugins in virtually any language.

~~~
__rvnykk
iirc Neovim has been trying to pretty much totally supplant Vimscript with Lua

~~~
raverbashing
Which is a good thing.

Better to use a more established language than reinventing the wheel

~~~
lifthrasiir
One thing to consider is that Lua is not a programming language that honors
the seamless evolution. Essentially there are three flavors of Lua identified
by their versions (5.1, 5.2 and 5.3), almost identical to each other but
different enough that a migration is unreasonable. If it were not the case,
there is no reason that NeoVim uses Lua 5.1 [1] even though 5.3 is the latest
and 5.4 beta is on the way [2]. I think this dependency on 5.1 can become a
huge problem later.

[1]
[https://neovim.io/doc/user/if_lua.html](https://neovim.io/doc/user/if_lua.html)

[2] [http://lua-users.org/lists/lua-l/2019-10/msg00003.html](http://lua-
users.org/lists/lua-l/2019-10/msg00003.html)

~~~
coldtea
NeoVim doesn't care about Lua, they care about LuaJit, which doesn't (and
probably wont ever) support lua syntax > 5.1 (or 5.2).

> _almost identical to each other but different enough that a migration is
> unreasonable._

There's nothing unreasonable, and all versions of Lua mentioned are backwards
compatible, so there's not even a problem about migrating. Going to a new
version is as simple as installing it and running your program.

~~~
lifthrasiir
> Going to a new version is as simple as installing it and running your
> program.

Not true. Each minor version of Lua tended to inject incompatibilities that
can't be trivially resolved. Lua 5.2 had made a catastrophic change to the
environment [1], and Lua 5.3 was less severe but there are subtle issues with
integer-number conversions you won't ever want in your large codebase [2]. And
that is not a theoretical matter, we had to stick to Lua 5.1 exactly due to
the environment changes even though 64-bit integers would have made our
codebase much cleaner. And Lua 5.1 and 5.2 are no longer supported [3] (though
as you have said, LuaJit may be supported) despite of all remaining issues.

[1]
[https://www.lua.org/manual/5.2/manual.html#8](https://www.lua.org/manual/5.2/manual.html#8)

[2]
[https://www.lua.org/manual/5.3/manual.html#8](https://www.lua.org/manual/5.3/manual.html#8)

[3] [https://www.lua.org/versions.html](https://www.lua.org/versions.html)

~~~
coldtea
True, the environment change was a big one.

But otherwise many codebases do move up Lua versions (outside of LuaJit), it's
not a Python 3 "wait 10 years", Perl 6 "Wait 20 years" situation/

~~~
lifthrasiir
Python 2.7 was supported for a decade, providing a reasonable environment when
Python 3 was not really matured enough. And while it didn't work, Python 3
tried to provide the migration path.

Perl 6 requires the full p5 compatibility as far as I recall. It was designed
to coexist.

Lua only provides _some_ C preprocessor flags for partial backward
compatibility.

------
otikik
Related with this: does anyone know of a good Lua indent file for Vim? All the
ones I have tried have trouble with indenting things (writing `busted` specs
in particular tends to be really annoying, the space on the next line after
the `describe` is never right).

