This PR doesn't actually do anything useful for the end user, all it does is just expose the treesitter C API through vimscript, which is what Neovim does except they use Lua. I suppose the end game plan is to create a vim9 script pack plugin that uses the API to actually do useful things.
To expose the treesitter API to vimscript, I created a new type called "opaque", which is similar to Lua's userdata if you know what that is. All they do is just bring reference counting to a block of memory + I also added properties to them (which are essentially the same as class members). They have full type checking at both runtime and compile time (for vim9 script), including the properties.
I haven't added tests yet so be mindful that it may be a little buggy/segfaulty.
Here's a demo script that highlights string literals using the C parser (just run g:RunParse(<buffer number>), also ignore the red highlighting on the function names, the syntax files have not been updated):
vim9script ts_load("c", "/usr/lib/tree_sitter/c.so") # Update to where the parser library is var parser: opaque<TSParser> = tsparser_new() tsparser_set_language(parser, "c") prop_type_add('literal', {'highlight': 'ErrorMsg'}) def g:RunParse(buf: number): opaque<TSQueryCursor> var res: opaque<TSTree> # There is a timeout limit for parsing (here 3 milliseconds), meaning we can implement async parsing: while true var tree: opaque<TSTree> = tsparser_parse_buf(parser, buf, 3) if tree == null_opaque continue endif res = tree break endwhile var node: opaque<TSNode> = tstree_root_node(res) var querystr: list<string> =<< trim END (string_literal) @string END var query: opaque<TSQuery> = tsquery_new("c", join(querystr, "\n")) var cursor: opaque<TSQueryCursor> = tsquerycursor_new() tsquerycursor_exec(cursor, query, node) while tsquerycursor_next_match(cursor) for i in range(0, len(cursor.match_captures) - 1) var capture: opaque<TSNode> = cursor.match_captures[i][0] var start: tuple<number, number> = capture.start_point var end: tuple<number, number> = capture.end_point prop_add(start[0] + 1, start[1] + 1, { type: 'literal', end_lnum: end[0] + 1, end_col: end[1] + 1 }) endfor endwhile return cursor enddef
TODO:
https://github.com/vim/vim/pull/18869
(41 files)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@DominiquePelle-TomTom commented on this pull request.
In src/vim9expr.c:
> + */
+ static int
+compile_opaque_index(cctx_T *cctx, char_u **arg, type_T *type)
+{
+ opaque_type_T *ot;
+ opaque_property_T *prop;
+ char_u *name;
+ char_u *name_end;
+ size_t len;
+ int idx;
+
+ if (VIM_ISWHITE((*arg)[1]))
+ {
+ semsg(_(e_no_white_space_allowed_after_str_str), ".", *arg);
+ return FAIL;
+ }
Indentation does not look right.
The same remark applies to several other places in this file and other files.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman commented on this pull request.
In src/vim9expr.c:
> + */
+ static int
+compile_opaque_index(cctx_T *cctx, char_u **arg, type_T *type)
+{
+ opaque_type_T *ot;
+ opaque_property_T *prop;
+ char_u *name;
+ char_u *name_end;
+ size_t len;
+ int idx;
+
+ if (VIM_ISWHITE((*arg)[1]))
+ {
+ semsg(_(e_no_white_space_allowed_after_str_str), ".", *arg);
+ return FAIL;
+ }
That is just github being weird with displaying code. It looks fine viewed otherwise
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 2 commits.
You are receiving this because you are subscribed to this thread.![]()
So far I remember there have been discussions around treesitter and if I remember correctly it was a no-no. But I am aging badly and I may remember it wrongly.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
So far I remember there have been discussions around treesitter and if I remember correctly it was a no-no. But I am aging badly and I may remember it wrongly.
Treesitter has improved greatly since then.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 2 commits.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@chrisbra Would you agree to adding the treesitter library as a submodule? Treesitter packages for non rolling linux distros are too old (treesitter development moves fast) and we would have to statically link it for Windows I'm pretty sure. Or we could include the treesitter source code directly in the repo, but I don't think that is the best way. Thanks.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I could say something about tree-sitter development but will refrain from doing so here. My unsolicited (but hard-won) advice would be to
@chrisbra In case you want to proceed with this; feel free to ping me with questions. I have some experience with the tree-sitter ecosystem...
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I'll take any advice I can 🙇♂️
I'd like to avoid submodules if possible, and your suggestions to link treesitter statically sounds good to me. Other than that, I am expecting a lot of issues from packaging side, especially on Windows systems and more exotic ones (like OpenVMS).
But I am basically blank with regard to tree-sitter. So any other suggestions from the other maintainers and power users are more than welcome!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Tree-sitter is battle-tested on Windows (although you may need CMake for that -- a fate worse than death; maybe Zig would be a more palatable approach due to its strong C interop). More "exotic" platforms are an issue, though; these are not officially supported, and no promises about the compiler requirements.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Treesitter has improved greatly since then.
Can you elaborate this?
I am expecting a lot of issues from packaging side, especially on Windows systems and more exotic ones (like OpenVMS).
Treesitter is a C library with no external deps. They officially have a makefile that does amalgamated build. I suppose it's not very difficult to integrate.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I don't agree with the "disadvantages" skywind3000 gave at the first place. Some of them are objectively false.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 25 commits.
You are receiving this because you are subscribed to this thread.![]()
Edit: Treesitter is build with
std=c11and vim is c99. But it still compiles under c99 with some warnings.% make -B cc -O3 -Wall -Wextra -Wshadow -Wpedantic -Werror=incompatible-pointer-types -std=c99 -fPIC -fvisibility=hidden -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -D_DARWIN_C_SOURCE -Ilib/src -Ilib/src/wasm -Ilib/include -c -o lib/src/alloc.o lib/src/alloc.c cc -O3 -Wall -Wextra -Wshadow -Wpedantic -Werror=incompatible-pointer-types -std=c99 -fPIC -fvisibility=hidden -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -D_DARWIN_C_SOURCE -Ilib/src -Ilib/src/wasm -Ilib/include -c -o lib/src/get_changed_ranges.o lib/src/get_changed_ranges.c In file included from lib/src/././tree_cursor.h:4, from lib/src/./get_changed_ranges.h:8, from lib/src/get_changed_ranges.c:1: lib/src/./././subtree.h:35:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 35 | }; | ^ lib/src/./././subtree.h:146:6: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 146 | }; | ^ lib/src/./././subtree.h:153:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 153 | }; | ^ cc -O3 -Wall -Wextra -Wshadow -Wpedantic -Werror=incompatible-pointer-types -std=c99 -fPIC -fvisibility=hidden -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -D_DARWIN_C_SOURCE -Ilib/src -Ilib/src/wasm -Ilib/include -c -o lib/src/language.o lib/src/language.c In file included from lib/src/./language.h:8, from lib/src/language.c:1: lib/src/././subtree.h:35:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 35 | }; | ^ lib/src/././subtree.h:146:6: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 146 | }; | ^ lib/src/././subtree.h:153:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 153 | }; | ^ cc -O3 -Wall -Wextra -Wshadow -Wpedantic -Werror=incompatible-pointer-types -std=c99 -fPIC -fvisibility=hidden -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -D_DARWIN_C_SOURCE -Ilib/src -Ilib/src/wasm -Ilib/include -c -o lib/src/lexer.o lib/src/lexer.c In file included from lib/src/./lexer.h:9, from lib/src/lexer.c:2: lib/src/././subtree.h:35:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 35 | }; | ^ lib/src/././subtree.h:146:6: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 146 | }; | ^ lib/src/././subtree.h:153:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 153 | }; | ^ cc -O3 -Wall -Wextra -Wshadow -Wpedantic -Werror=incompatible-pointer-types -std=c99 -fPIC -fvisibility=hidden -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -D_DARWIN_C_SOURCE -Ilib/src -Ilib/src/wasm -Ilib/include -c -o lib/src/node.o lib/src/node.c In file included from lib/src/node.c:3: lib/src/./subtree.h:35:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 35 | }; | ^ lib/src/./subtree.h:146:6: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 146 | }; | ^ lib/src/./subtree.h:153:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 153 | }; | ^ cc -O3 -Wall -Wextra -Wshadow -Wpedantic -Werror=incompatible-pointer-types -std=c99 -fPIC -fvisibility=hidden -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -D_DARWIN_C_SOURCE -Ilib/src -Ilib/src/wasm -Ilib/include -c -o lib/src/parser.o lib/src/parser.c In file included from lib/src/././tree_cursor.h:4, from lib/src/./get_changed_ranges.h:8, from lib/src/parser.c:9: lib/src/./././subtree.h:35:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 35 | }; | ^ lib/src/./././subtree.h:146:6: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 146 | }; | ^ lib/src/./././subtree.h:153:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 153 | }; | ^ cc -O3 -Wall -Wextra -Wshadow -Wpedantic -Werror=incompatible-pointer-types -std=c99 -fPIC -fvisibility=hidden -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -D_DARWIN_C_SOURCE -Ilib/src -Ilib/src/wasm -Ilib/include -c -o lib/src/point.o lib/src/point.c cc -O3 -Wall -Wextra -Wshadow -Wpedantic -Werror=incompatible-pointer-types -std=c99 -fPIC -fvisibility=hidden -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -D_DARWIN_C_SOURCE -Ilib/src -Ilib/src/wasm -Ilib/include -c -o lib/src/query.o lib/src/query.c In file included from lib/src/./language.h:8, from lib/src/query.c:13: lib/src/././subtree.h:35:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 35 | }; | ^ lib/src/././subtree.h:146:6: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 146 | }; | ^ lib/src/././subtree.h:153:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 153 | }; | ^ cc -O3 -Wall -Wextra -Wshadow -Wpedantic -Werror=incompatible-pointer-types -std=c99 -fPIC -fvisibility=hidden -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -D_DARWIN_C_SOURCE -Ilib/src -Ilib/src/wasm -Ilib/include -c -o lib/src/stack.o lib/src/stack.c In file included from lib/src/./language.h:8, from lib/src/stack.c:2: lib/src/././subtree.h:35:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 35 | }; | ^ lib/src/././subtree.h:146:6: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 146 | }; | ^ lib/src/././subtree.h:153:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 153 | }; | ^ cc -O3 -Wall -Wextra -Wshadow -Wpedantic -Werror=incompatible-pointer-types -std=c99 -fPIC -fvisibility=hidden -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -D_DARWIN_C_SOURCE -Ilib/src -Ilib/src/wasm -Ilib/include -c -o lib/src/subtree.o lib/src/subtree.c In file included from lib/src/subtree.c:9: lib/src/./subtree.h:35:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 35 | }; | ^ lib/src/./subtree.h:146:6: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 146 | }; | ^ lib/src/./subtree.h:153:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 153 | }; | ^ cc -O3 -Wall -Wextra -Wshadow -Wpedantic -Werror=incompatible-pointer-types -std=c99 -fPIC -fvisibility=hidden -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -D_DARWIN_C_SOURCE -Ilib/src -Ilib/src/wasm -Ilib/include -c -o lib/src/tree.o lib/src/tree.c In file included from lib/src/././tree_cursor.h:4, from lib/src/./get_changed_ranges.h:8, from lib/src/tree.c:3: lib/src/./././subtree.h:35:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 35 | }; | ^ lib/src/./././subtree.h:146:6: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 146 | }; | ^ lib/src/./././subtree.h:153:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 153 | }; | ^ cc -O3 -Wall -Wextra -Wshadow -Wpedantic -Werror=incompatible-pointer-types -std=c99 -fPIC -fvisibility=hidden -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -D_DARWIN_C_SOURCE -Ilib/src -Ilib/src/wasm -Ilib/include -c -o lib/src/tree_cursor.o lib/src/tree_cursor.c In file included from lib/src/./tree_cursor.h:4, from lib/src/tree_cursor.c:2: lib/src/././subtree.h:35:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 35 | }; | ^ lib/src/././subtree.h:146:6: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 146 | }; | ^ lib/src/././subtree.h:153:4: warning: ISO C99 doesn’t support unnamed structs/unions [-Wpedantic] 153 | }; | ^ cc -O3 -Wall -Wextra -Wshadow -Wpedantic -Werror=incompatible-pointer-types -std=c99 -fPIC -fvisibility=hidden -D_POSIX_C_SOURCE=200112L -D_DEFAULT_SOURCE -D_DARWIN_C_SOURCE -Ilib/src -Ilib/src/wasm -Ilib/include -c -o lib/src/wasm_store.o lib/src/wasm_store.c ar rcs libtree-sitter.a lib/src/alloc.o lib/src/get_changed_ranges.o lib/src/language.o lib/src/lexer.o lib/src/node.o lib/src/parser.o lib/src/point.o lib/src/query.o lib/src/stack.o lib/src/subtree.o lib/src/tree.o lib/src/tree_cursor.o lib/src/wasm_store.o cc -shared -Wl,-soname,libtree-sitter.so.0.26 lib/src/alloc.o lib/src/get_changed_ranges.o lib/src/language.o lib/src/lexer.o lib/src/node.o lib/src/parser.o lib/src/point.o lib/src/query.o lib/src/stack.o lib/src/subtree.o lib/src/tree.o lib/src/tree_cursor.o lib/src/wasm_store.o -o libtree-sitter.so sed -e 's|@PROJECT_VERSION@|0.26.2|' \ -e 's|@CMAKE_INSTALL_LIBDIR@|lib|' \ -e 's|@CMAKE_INSTALL_INCLUDEDIR@|include|' \ -e 's|@PROJECT_DESCRIPTION@|An incremental parsing system for programming tools|' \ -e 's|@PROJECT_HOMEPAGE_URL@|https://tree-sitter.github.io/tree-sitter/|' \ -e 's|@CMAKE_INSTALL_PREFIX@|/usr/local|' lib/tree-sitter.pc.in > tree-sitter.pc
That looks like a problem, I guess we just disable the treesitter feature on non C11 compliant compilers?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
It still compiles in C99. The only feature they use is unnamed structs/unions in a few structs. We can give them names to suppress warnings.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I'm quite confused on how to go forward with statically linking Vim with Treesitter. The only thing I can think of is copying the Treesitter library files into src/treesitter/, and modifying our src/Makefile to build the library.
However, if we want to include WASM support, then it looks like we need rust (cargo) installed? I couldn't find any packages containing wasmtime development files on Arch Linux + how would this be done on Windows or MacOS? I'm not sure how accessible this wasmtime library is other then getting it through Cargo using this crate (from what I could find).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
Or we could use the Treesitter provided Makefile, but not sure if that is the best way.
Yes, that would be the best way. The lib itself is a fairly simple project, and so is the makefile (make static, and then include that in the linker step). Of course, if this is your first external dependency, this will require significant changes to your build process. (That's not something I can much help with; I can only say that the tree-sitter makefile is relatively footgun-free.)
However, if we want to include WASM support, then it looks like we need rust (cargo) installed?
Yes, for WASM parsers you (currently) need wasmtime-c-api, which is a rust dependency; see https://github.com/neovim/neovim/blob/master/cmake.deps/cmake/BuildWasmtime.cmake
However, we pretty much abandoned this for Neovim, not least because wasmtime is a fast-moving target (monthly major releases). I don't want to spoil things, but there may be a lighter-weight wasm runtime in Zig coming...
For now, I'd recommend ignoring WASM parsers and require native parsers.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 27 commits.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
I think @ubaldot was thinking of #9087. I do think we still have to have some kind of plan to address concerns raised in that discussion about the build process for language parsers that need compilation. It doesn't have to be perfect, but I think we need at least some notion of a vision/goal for how this will come together.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
I think @ubaldot was thinking of #9087. I do think we still have to have some kind of plan to address concerns raised in that discussion about the build process for language parsers that need compilation. It doesn't have to be perfect, but I think we need at least some notion of a vision/goal for how this will come together.
I believe all language parsers need compilation? As for the problem on how users will somehow get these parsers, I guess that can be implemented in community plugins? I don't think some users would like Vim having a builtin plugin that accesses the internet. We already offload actual LSP support onto community plugins, so this sounds reasonable as well.
As for needing a compiler, that is straightforward on Linux (just install the distro's devel package whatever) and I'm guessing other Unix OSes too, but I'm not sure about Windows.
The solution to this would be precompiled parsers, but looking the parser repo's of major programming languages, all they seem to provide is the source code in their releases. I read somewhere that nvim-treesitter provides precompiled artifacts of parsers and uses those, but that is sorta an official plugin which I'm not sure is feasible with Vim's ecosystem.
I think we should start simple for the initial builtin Treesitter plugin. Maybe the first iteration should have:
foldexpr, indentexprPerformance optimizations/other stuff can come later. This should be enough for most users
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
I read somewhere that nvim-treesitter provides precompiled artifacts of parsers and uses those
You read that wrong. Long-term, the answer is WASM, but that is not yet feasible today. (Again, it's not like other editors haven't been working on this for 5+ years.)
I think we should start simple for the initial builtin Treesitter plugin. Maybe the first iteration should have:
I think you need to focus first and foremost on (efficiently) handling "language trees", i.e., injections (which is arguably the biggest selling point for tree-sitter over other highlighting solutions.)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 2 commits.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 32 commits.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 3 commits.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
Can we make tree-sitter a submodule? That might simplify vendoring changes (and makes it easier to verify this PR isn't sneaking in a close-but-not-actually tree-sitter source file that turns out to be some kind of backdoor or whatever).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Have you looked at the tree-sitter repository? Let that man cook, sheesh.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Have you looked at the tree-sitter repository? Let that man cook, sheesh.
I don't follow: I assume this was in reply to my comment, but I'm not sure what I'm supposed to get from this.
A brief glance at tree-sitter/tree-sitter didn't cause anything to jump out, except maybe that we're only taking the relevant part of the tree-sitter code (which is admittedly hard to do in an easy-to-verify way with Git).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
Can we make tree-sitter a submodule? That might simplify vendoring changes (and makes it easier to verify this PR isn't sneaking in a close-but-not-actually tree-sitter source file that turns out to be some kind of backdoor or whatever).
The same could be said for the xdiff dependency we have. I don't think a submodule is necessary, since its just a matter of copying the library source files from a Tree-sitter release tar into the src/treesitter. Additionally, the Tree-sitter Makefile doesn't seem to work with BSD make, so I had to use our src/Makefile
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 2 commits.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 0 commits.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 0 commits.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
Note that there are version compatibility constraints between the tree-sitter library and the tree-sitter CLI used to generate the individual parsers. This effectively prevents you from fully vendoring the code. And compared to xdiff, tree-sitter is still under heavy development and will see breaking changes.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Would you agree to bundling the treesitter library in repo? Treesitter packages for non rolling linux distros are too old (treesitter development moves fast)
I don't see how "treesitter packages on old distro releases are old" leads to "bundle treesitter in Vim's repo". Vim packages are also old on old distro releases. If someone wants to build a newer Vim there, then they can do the work to also build the new Vim's dependencies.
Bundling a third-party dependency shouldn't be a light decision. It's fine to say "Vim depends on this specific range of versions for dependency X" and let packagers figure out how to do that. Don't try to solve their problem for them by bundling the code in Vim.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@chrisbra What do you think? I'm fine with either way
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
Maybe we can handle it the same way as libsodium. For Linux user, they can use liblibtree-sitter.so from package manager. And for Windows user, we bundle it in https://github.com/vim/vim-win32-installer.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
If possible, we should avoid vendoring tree-sitter into Vim. It is a lot of code, and I do not want to take on responsibility for maintaining it here - especially from a security perspective, since it is a fast-moving target and I already have plenty to do for Vim. Instead, we should keep this modular and have the configure script detect (or point) and link against an installed tree-sitter.
I guess we have to find out how to do this for Windows, but we had to do the same for libsodium back then. We don't have to solve everything at once.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 2 commits.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
(PS: I know most PRs get squashed here, so what I'm about to say is largely moot for the final result. It might be helpful for 64-bitman and collaborators as they develop anyway.
Reverting the vendor commit still requires Git to keep around all the object files corresponding to that code. By contrast, if the branch is rewritten so that the vendor commit never appears in the first place, Git can throw those objects away from local copies and they won't be present in new fetches or clones. It also keeps history cleaner for projects that don't squash.)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 43 commits.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 43 commits.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 2 commits.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()
@64-bitman pushed 1 commit.
You are receiving this because you are subscribed to this thread.![]()