Re: Tree-sitter api

[Yuan Fu]

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

Yes. I can do that once we figure out the namespace and new load path.

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

As Po said, there is a package already using the ts prefix and that package is 
popular enough. Maybe tsr? Anyway, I’d love a shorter prefix other than 
tree-sitter, it is a real pain to type this long prefix.

> 
> 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).

We expect end-users/maintainers to distribute language definitions. Because the 
language library must be in the same version as the tree-sitter library, and we 
expect them to distribute tree-sitter. I don’t have an opinion on where the 
load path should be.

Yuan