emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tree-sitter api


From: Yuan Fu
Subject: Re: Tree-sitter api
Date: Sat, 11 Sep 2021 12:00:59 -0700


> On Sep 10, 2021, at 10:51 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Fri, 10 Sep 2021 12:57:22 -0700
>> Cc: Tuấn-Anh Nguyễn <ubolonton@gmail.com>,
>> Theodor Thornhill <theo@thornhill.no>,
>> Stephen Leake <stephen_leake@stephe-leake.org>,
>> Clément Pit-Claudel <cpitclaudel@gmail.com>,
>> Stefan Monnier <monnier@iro.umontreal.ca>,
>> emacs-devel@gnu.org
>> 
>>> Sure.  I guess we will have to have a database of module names for
>>> each programming language somewhere?
>> 
>> My plan is to translate lisp names to C names by default, and have an 
>> override list for irregular names that can’t be translated correctly.
> 
> What are "Lisp names" in this context?  Are you saying that the name
> of a programming language, derived from the major mode, can be used to
> produce the name of the shared library programmatically?  If so, how?

I don’t think it’s a rule, but language definitions are conventionally named 
tree-sitter-<lang>. E.g. tree-sitter-c, tree-sitter-json, tree-sitter-c-sharp. 
And the symbol they expose are tree_sitter_<lang>, e.g., tree_sitter_c, 
tree_sitter_jon, tree_sitter_c_sharp. Currently we use a symbol 
tree-sitter-<lang> to represent a language, so we can translate the symbol 
tree-sitter-<lang> to tree-sitter-<lang>.so/dylib/dll to get the shared library 
name, and to tree_sitter_<lang> to get the C symbol name.

BTW, since dynamic libraries has different extensions on different systems, 
what I want to do it to try loading the library with .so, then try .dylib, then 
try .dll, is that a good idea?

> 
>> Just realized another problem, how do we make sure the loaded library is 
>> GPL-compatible? There certainly won’t be “plugin_is_GPL_compatible” symbol 
>> in them… And IIUC Emacs cannot load GPL-incompatible dynamic libraries?
> 
> That's only needed for Emacs modules, not for external libraries that
> provide some extra functionality on the level of primitives.  For
> those, we just make sure their license is compatible with GPL.

Thanks, that’s all I need to know.

Yuan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]