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: Tue, 29 Mar 2022 19:40:38 +0300

> From: Yuan Fu <casouri@gmail.com>
> Date: Sat, 12 Mar 2022 22:25:11 -0800
> Cc: Yoav Marco <yoavm448@gmail.com>,
>  Clément Pit-Claudel <cpitclaudel@gmail.com>,
>  Emacs developers <emacs-devel@gnu.org>,
>  John Yates <john@yates-sheets.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Philipp <p.stephani2@gmail.com>,
>  Stephen Leake <stephen_leake@stephe-leake.org>,
>  Theodor Thornhill <theo@thornhill.no>,
>  ubolonton@gmail.com
> 
> > It has been quite a while. I added some fixes to the patch and added full 
> > changeling. Anyone would like to have a look at it?
> > 
> > Thanks,
> > Yuan
> 
> Forgot to attach the patch, here it is:

Thanks.  I skimmed this, and it looks in sufficiently good shape.  Do
you consider this feature-complete enough to make one more step
towards merging it?  If so, I'd like first to have this on a feature
branch in our repository, so that people could build it and try it.
Then we could land it on master after some time.

One thing that we should consider right now is the name-space.  You
used tree-sitter-* names for all the symbols, and I'm asking whether
we don't want something shorter, like ts-*.  This is a decision we
must make now, because once we start using the code, there will be no
way back.  Lars, WDYT?

One other thing that I don't think I have a clear idea about is the
deployment.  Do we expect end-users (or downstream package
maintainers) to download and install the language definition libraries
they need?  If so, I think we should have our own load-path for these
libraries; relying on the standard LD_LIBRARY_PATH etc. is not good
enough (although we should support that as well).  I envision that at
least in some cases users will not want to have these libraries in the
public places, or maybe even won't have the requisite access rights to
do so.  We should provide Emacs-style alternatives, like some
subdirectory of ~/.emacs.d/ and/or under ${prefix}/lib/ (similar to
*.eln files).



reply via email to

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