Add support for vlang filetypes.
- [ ] Highlight `C` as builtin variable. This is FFI in vlang land,
where C act like extern and access c functions. The vlang parser does
some extension between C function calls and arguments but I believe
highlighting C as builtin variable is sufficient indicator for now. I
tried to use offset! but failed. Any suggestions?
- [ ] Set up parser url. the vlang parser is located within [vls] repo. Is
installing from nested repo supported? `tree_sitter_v/src/parser.c`?
[vls]: https://github.com/vlang/vls/tree/master/tree_sitter_v
cc @elianiva @theHamsta
* set highlight groups via nvim_set_hl
* define autocommands via nvim_create_autocmd
* port plugin/nvim-treesitter.vim to Lua
* port healthcheck to Lua
Removes all support (and tests) for the parser category "maintained", as
this is no longer a useful category.
BREAKING CHANGE: replace `ensure_installed='maintained'` by an explicit
list of parsers, or use `'all'` (not recommended).
After some discussion, it looks like the easiest thing to do for now is
to keep a private copy of get_node_text (just to skip the deprecation
message) and invoke that, until core provides an equivalent function
that can return the node content in a table representing the node
"lines".
Also fixes the statusline by calling the private version for
get_node_text until a change is made in core.
When a module is disabled by default in the config, running
TSBufEnable will not enable the module because the is_enabled
function will always return false, thus the module not being enabled.
Also, disabling/enabling the buffers is flaky.
This commit adds per buffer check when the module is not disabled. It
also makes the enable and disable more indempotent.
i've also renamed TS*All to TS*.
Fixes#2754
* Add slint parser
* Mark slint as experimental
* Remove filetype and add slint to the lockfile
* Update queries
* Update varibable.builtin's and repeats
* Update slint true false
* Change export back to keyword
* Change export back to include :)
BREAKING: deprecate custom_captures from highlight config.
This allows plugin authors to extend the map. It also avoids settings
user configuration specific values during the highlighter
initialization (SOC).
Not sure how much value this brings, and might potentially break a lot
of people configurations. This is questionable.
