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: Sun, 5 Sep 2021 13:19:09 -0700


> On Sep 5, 2021, at 9:45 AM, Tuấn-Anh Nguyễn <ubolonton@gmail.com> wrote:
> 
> On Sat, Sep 4, 2021 at 10:31 PM Yuan Fu <casouri@gmail.com> wrote:
>> I packaged language definitions into dynamic modules: the system is there, 
>> why not take advantage of it? Do you think this approach can be improved in 
>> some way?
> 
> The language definitions just need to come from dynamically-loadable shared
> libraries. They don't have to be Emacs dynamic modules, which bring additional
> unnecessary complications, e.g. build difficulty, load path pollution, or
> inability to load grammar binaries from other sources like distro's package
> repos. It's better to just load the shared libs directly without going through
> module machinery. Use the functions in `dynlib.h`.
> 

Dynamic modules comes with nice things, for example Emacs looks for them 
automatically in load-path; Emacs reports errors with it has problem loading 
one; I can package some additional information with the module; I could maybe 
distribute them through ordinary package.el facility, etc etc. If I load the 
shared library directly, I need to reinvent the wheels for loading, error 
reporting, searching in load-path, and others. On the other hand, dynamic 
modules don’t come with much complications. Yes, you need additional 
emacs-modules.h and tree-sitter-<lang>.c to build it, but that’s about it. And 
I was hoping to distribute pre-built modules anyway, so if all went well, 
ordinary users don’t need to compile the modules. WDYT?

P.S. what do you mean by “load path pollution”?
P.P.S. My impression is that other applications distribute language definitions 
by themselves, and it is not common for distort to package language 
definitions, is that correct?

Yuan


reply via email to

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