See comment on struct Lisp_TS_Query for why. Previous commits adding
python and js support for tree-sitter breaks Emacs build if language
definitions aren't available at build time. This commit fixes that.
Now query object don't compile the query upon creation, but stores the
query source and language symbol, and compiles upon first use (in
treesit-query-capture).
I want ts_ensure_query_compiled to return signal symbol and data
rather than signaling itself, because it's a helper function not lisp
function. But because it calls ts_load_language, I had to update
ts_load_language to also use the signal symbol/data interface.
* src/treesit.h (struct Lisp_TS_Query): Add two new field.
* src/treesit.c (ts_load_language): Return signal symbol and data
rather than signaling itself.
(Ftreesit_langauge_available_p)
(Ftreesit_parser_create): Update usage of ts_load_language
(make_ts_query): Now returns a lisp object.
(ts_query_error_to_string): Moved because it's used by
ts_compose_query_signal_data.
(ts_compose_query_signal_data)
(ts_ensure_query_compiled): New functions.
(Ftreesit_query_compile): Delay compiling the query.
(Ftreesit_query_capture): Instead of creating a query object which
compiles the query, now goes two routes: if QUERY is a query object,
make sure it is compiled and use the TSQuery; if QUERY is a cons or
string, compile directly to TSQuery, and free it after use. Creating
a lisp query requires the language symbol, but in this function we
only have TSLanguage.