From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Tree-sitter api Date: Tue, 07 Sep 2021 19:16:14 +0300 Message-ID: <835yvcpdip.fsf@gnu.org> References: <83r1f7hydn.fsf@gnu.org> <95F37923-5BF9-4D81-B361-267CF119FBCA@gmail.com> <735AF34C-FD18-4A6A-A99D-E5D8EB4DE4F3@gmail.com> <40611F1F-7B5C-4885-A2CA-CE709ED8D22B@gmail.com> <4E876354-10D1-46B3-8124-CAE916261F08@gmail.com> <0A3F5464-B90D-4D47-BBDD-CCA26D877F43@gmail.com> <83tuiys1y4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35938"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, theo@thornhill.no, cpitclaudel@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, stephen_leake@stephe-leake.org To: =?utf-8?Q?Tu=E1=BA=A5n-Anh_Nguy=E1=BB=85n?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 07 18:17:15 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mNdmb-00098m-8M for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Sep 2021 18:17:13 +0200 Original-Received: from localhost ([::1]:43088 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mNdmZ-0004UA-Cd for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Sep 2021 12:17:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57448) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mNdla-0003li-Vk for emacs-devel@gnu.org; Tue, 07 Sep 2021 12:16:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55864) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mNdlX-0002Jz-Ll; Tue, 07 Sep 2021 12:16:09 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2070 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mNdlX-0007uU-8Q; Tue, 07 Sep 2021 12:16:07 -0400 In-Reply-To: (message from =?utf-8?Q?Tu=E1=BA=A5n-Anh_Nguy=E1=BB=85n?= on Tue, 7 Sep 2021 22:38:52 +0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:274261 Archived-At: > From: Tuấn-Anh Nguyễn > Date: Tue, 7 Sep 2021 22:38:52 +0700 > Cc: Yuan Fu , Theodor Thornhill , > Stephen Leake , > Clément Pit-Claudel , > Stefan Monnier , emacs-devel > > On Mon, Sep 6, 2021 at 12:33 PM Eli Zaretskii wrote: > > I understand that a language module gets compiled into a shared > > library, either as part of building TS or separately. But what should > > Emacs do to "load" the module, and when should it do that? And how do > > we intend to handle the situation where a module is needed, but is not > > available (i.e. its loading fails)? > > Emacs should "load" the module when it's asked to do so, by a function, e.g. > `tree-sitter-load-lang`. When loading fails, it should signal an error. So this has to be an explicit load initiated by a Lisp program? How would that program know which module to load for a given language? (I thought TS would load the module it needs whenever support for a language is requested.) > To locate the module, I think there are 2 possible approaches: > 1. Emacs consults a new search path variable to look for the module, which is > named `[.ext]`, and calls `dynlib_open` with the absolute path. > 2. Emacs calls `dynlib_open` with the basename `tree-sitter-[.ext]`, > relying on the module being correctly put on the system's library search path, > e.g. by the distro's package manager. > > Option 2 sounds better to me, but option 1 is how people do it at the moment. > (And no distro has packaged these AFAICT.) I think 2 is better, since we are relying on others to build and package these modules. Thanks.