[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: |
Fri, 1 Apr 2022 09:48:09 -0700 |
> On Mar 31, 2022, at 11:20 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Thu, 31 Mar 2022 16:00:28 -0700
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>,
>> yoavm448@gmail.com,
>> emacs-devel@gnu.org,
>> ubolonton@gmail.com
>>
>>>
>>> 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).
>>
>> Anyone have thoughts on this?
>
> What kind of thoughts? Whether or not to provide this feature (I
> think we should), or how best to implement that? Or something else?
Thoughts on what paths should we use, whether we want to allow for custom
load-paths (I think we should), and if so, the name for the load path variable
({tree-sitter/treesit/...}-language-definition-load-path?)
Yuan
- Re: Tree-sitter api, Eli Zaretskii, 2022/04/01
- Re: Tree-sitter api,
Yuan Fu <=
- Re: Tree-sitter api, Eli Zaretskii, 2022/04/01
- Re: Tree-sitter api, Yuan Fu, 2022/04/02
- Re: Tree-sitter api, Robert Pluim, 2022/04/04
- Re: Tree-sitter api, Yuan Fu, 2022/04/04
- Re: Tree-sitter api, Theodor Thornhill, 2022/04/20
- Re: Tree-sitter api, Yuan Fu, 2022/04/20
- Re: Tree-sitter api, Eli Zaretskii, 2022/04/21
- Re: Tree-sitter api, Lars Ingebrigtsen, 2022/04/21
- Re: Tree-sitter api, Theodor Thornhill, 2022/04/21
- Re: Tree-sitter api, Yuan Fu, 2022/04/21