emacs-devel
[Top][All Lists]
Advanced

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

Re: tree-sitter: Paths used for loading of language definitions


From: Yuan Fu
Subject: Re: tree-sitter: Paths used for loading of language definitions
Date: Mon, 17 Oct 2022 00:29:41 -0700


> On Oct 17, 2022, at 12:14 AM, Jostein Kjønigsen 
> <jostein@secure.kjonigsen.net> wrote:
> 
> 
> 
> On 17.10.2022 06:27, Yuan Fu wrote:
>> 
>>> That said, I've noticed something when building the feature/tree-sitter 
>>> branch, and also while testing other things tree-sitter related... If a 
>>> language-definition SO is missing... treesit.el in Emacs only reports 
>>> looking for files and folders typically found within $HOME/.emacs.d/ (that 
>>> is user-owned files).
>>> 
>>> Based on that, I'm assuming those are the only locations probed. Is that 
>>> assumption correct?
>>> 
>> It shouldn’t be. Emacs should first look in treesit-extra-load-path, then 
>> ~/.emacs.d/tree-sitter, then standard system library locations. The exact 
>> locations depend on dlopen. Could you share the error message reported when 
>> loading a non-exist language? It should print all the locations it tries (as 
>> you observed).
>> 
>> Yuan
>> 
> textmodes/mhtml-mode.el:29:2: Error: Cannot load language definition: 
> "javascript", ("/home/jostein/.emacs.d/tree-sitter/libtree-sitter-javascript: 
> cannot open shared object file: No such file or directory" 
> "/home/jostein/.emacs.d/tree-sitter/libtree-sitter-javascript.so: cannot open 
> shared object file: No such file or directory" "libtree-sitter-javascript: 
> cannot open shared object file: No such file or directory" 
> "libtree-sitter-javascript.so: cannot open shared object file: No such file 
> or directory")

Ah, I guess your system doesn’t explicitly say what path has been checked. The 
last two messages in the list is where dlopen searches the system paths.

> 
> Does that impliy it checks in the standard system library localtion? If so, I 
> guess there's no problem.
> 
> In that case, sorry for the "noise", but I just wanted to make sure this was 
> packagable and thought one check too much is better than one check too little 
> :)

Yes, false positives are always better than false negative ;-)

Yuan


reply via email to

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