From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Where to place third-party C source code? Date: Sat, 28 Sep 2019 12:53:44 +0300 Message-ID: <834l0wiw5z.fsf@gnu.org> References: <1504933445.581219.1569619792280.ref@mail.yahoo.com> <1504933445.581219.1569619792280@mail.yahoo.com> <83impdhqz1.fsf@gnu.org> <87pnjklvsb.fsf@yahoo.com.mx> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="162278"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Jorge Javier Araya Navarro Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 28 11:54:31 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iE9Qs-000fzv-Eq for ged-emacs-devel@m.gmane.org; Sat, 28 Sep 2019 11:54:30 +0200 Original-Received: from localhost ([::1]:60022 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iE9Qr-0006lq-A2 for ged-emacs-devel@m.gmane.org; Sat, 28 Sep 2019 05:54:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47471) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iE9QG-0006lP-N2 for emacs-devel@gnu.org; Sat, 28 Sep 2019 05:53:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iE9QG-0004jP-76; Sat, 28 Sep 2019 05:53:52 -0400 Original-Received: from [176.228.60.248] (port=2042 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iE9QF-0004hg-Kg; Sat, 28 Sep 2019 05:53:51 -0400 In-reply-to: <87pnjklvsb.fsf@yahoo.com.mx> (message from Jorge Javier Araya Navarro on Sat, 28 Sep 2019 01:33:40 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:240365 Archived-At: > From: Jorge Javier Araya Navarro > Cc: emacs-devel@gnu.org > Date: Sat, 28 Sep 2019 01:33:40 -0600 > > > I don't see why we would need this method, since tree-sitter is a > > library, and Emacs can be linked against that library. What you quote > > is an alternative method, but why would we need such an alternative? > > Well, yes, I realized that adding an option to configure.ac would allow the compiler to find the > source code of Tree Sitter (like `--with-tree-sitter=/some/path/tree-sitter' or who knows) Why would building Emacs require access to the tree-sitter's source code, even if we decide to provide this feature in core Emacs? Isn't linking against a library good enough? > > Of course, this is all putting the wagon ahead of the horse: we should > > first discuss whether we want to have Emacs be able to link to that > > library and provide the related features. An alternative would be to > > have an unbundled module that uses the Emacs module API. > > Ah, yes. There is one project that provides tree-sitter like a dynamic module using the Emacs module > API[1], but my concern is: why should vanilla Emacs require their final users to download a bunch of > packages to make the user experience better when we could, like, literally, provide them from the > get-go? IIRC one pain-point of Emacs for (new?) users is how much configuration is needed to have a > better editing experience. There's no contradiction between better experience and having this particular feature be implemented as a module. We've added the module API precisely for cases like this one, where some feature needed access to the Emacs internals on the C level. Making this part of the Emacs core would need to write some C code in Emacs itself, and link against the library, it still won't need any access to the sources of tree-sitter. We could do that, but we need first to be sure that this is worth our while, i.e. that having that feature through an external module will somehow be insufficient, or if most Emacs users will want to have that. AFAIU, none of these reasons were brought up and justified yet. Improving the user experience is not of itself a sufficient reason, because every additional feature basically does that in some sense. We need a more serious reason, one that will justify the additional maintenance burden that will put on the Emacs project in the long run.