Re: Tree-sitter api

[Tuấn-Anh Nguyễn]

On Mon, Sep 6, 2021 at 12:33 PM Eli Zaretskii <eliz@gnu.org> wrote:
> I understand that a language module gets compiled into a shared
> library, either as part of building TS or separately.  But what should
> Emacs do to "load" the module, and when should it do that?  And how do
> we intend to handle the situation where a module is needed, but is not
> available (i.e. its loading fails)?

Emacs should "load" the module when it's asked to do so, by a function, e.g.
`tree-sitter-load-lang`. When loading fails, it should signal an error.

To locate the module, I think there are 2 possible approaches:
1. Emacs consults a new search path variable to look for the module, which is
  named `<lang>[.ext]`, and calls `dynlib_open` with the absolute path.
2. Emacs calls `dynlib_open` with the basename `tree-sitter-<lang>[.ext]`,
  relying on the module being correctly put on the system's library search path,
  e.g. by the distro's package manager.

Option 2 sounds better to me, but option 1 is how people do it at the moment.
(And no distro has packaged these AFAICT.)

> Emacs has a load-on-demand infrastructure for shared libraries, but it
> only exists on MS-Windows, where we support installations of Emacs
> binaries without some of the optional libraries, and want to handle
> that gracefully.  However, this doesn't seem to be a similar
> situation; for starters, load-on-demand needs to know at Emacs build
> time the names of entry points (functions and variables) we need to
> import from each shared library.  So I guess we are talking about some
> (slightly) different mechanism here?

For each language, the entry point is a single function `TSLanguage
(*tree_sitter_<lang>) ()`,
where `lang` is the name declared in the grammar's DSL source. It's ensured by
the parser generator (the `tree-sitter` CLI program).

-- 
Tuấn-Anh Nguyễn
Software Engineer