emacs-devel
[Top][All Lists]
Advanced

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

Re: Tree-sitter api


From: Eli Zaretskii
Subject: Re: Tree-sitter api
Date: Sat, 11 Sep 2021 22:14:26 +0300

> From: Yuan Fu <casouri@gmail.com>
> Date: Sat, 11 Sep 2021 12:00:59 -0700
> Cc: Tuấn-Anh Nguyễn <ubolonton@gmail.com>,
>  theo@thornhill.no,
>  stephen_leake@stephe-leake.org,
>  cpitclaudel@gmail.com,
>  monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> 
> >> 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.

But the <lang> part is still needed to be concocted somehow.  E.g.,
the conversion from "C#" to "c-sharp" isn't trivial.

> 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?

We can do better, see load-suffixes.



reply via email to

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