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 introduction documentation Date: Tue, 27 Dec 2022 15:38:07 +0200 Message-ID: <83pmc50xxc.fsf@gnu.org> References: <83edszjslp.fsf@gnu.org> <87tu1vxs3a.fsf@ledu-giraud.fr> <831qozjob7.fsf@gnu.org> <87cz8jxoat.fsf@ledu-giraud.fr> <83wn6ri7pn.fsf@gnu.org> <5e0a3185-de82-b339-0fa2-956779e63d6f@cornell.edu> <868rj6vfep.fsf@gmail.com> <4895891b-e5ea-9c37-f51b-df2e479ee758@yandex.ru> <83y1qt11xq.fsf@gnu.org> <9eb013da-d0fc-8e17-c6e3-1e8f913aebfa@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27125"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, theophilusx@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 27 14:38:40 2022 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 1pAAAB-0006oq-Pa for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Dec 2022 14:38:40 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pAA9h-0006zr-9k; Tue, 27 Dec 2022 08:38:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pAA9a-0006xy-Nq for emacs-devel@gnu.org; Tue, 27 Dec 2022 08:38:06 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pAA9Z-0004ip-Kw; Tue, 27 Dec 2022 08:38:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=892CRJDsUQd1gQq/COctgxY6lOWAhbZvTJ3k0TeNvTo=; b=Kme6MyLd5Vdi BMWcVJz1Yvut74Gh+Y0Qqtx8aPNMBrSWmbA9yRKJrhXol9mBZXf57pzcDpQ/hNsGkv6HBeOFXkhzP vtVRfjqxo1mdp1sR+f6HvBZ2Nyzp7XspjwP1vCiyMIyGqjfRTwvt12ro5kBiQa5Y5FikvlxQI/d84 SqCmMA+PtF7B8SY+no36ZnbN1hc/8Q29wBJygE8NkA2s7hbBLi3lujrraSA0RUBcGWNbA6z065Yql 6U06FhoFpvsgGa87QSmrMIKwKSTAw1up8oZ2MBYRZdtV5y1dn5lMgHSS/VWphRqkD5hZJBlWL/O2t Zv08pwF/FJLqB1wKQMaFig==; Original-Received: from [87.69.77.57] (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 1pAA9Z-0008LO-2K; Tue, 27 Dec 2022 08:38:01 -0500 In-Reply-To: <9eb013da-d0fc-8e17-c6e3-1e8f913aebfa@yandex.ru> (message from Dmitry Gutov on Tue, 27 Dec 2022 14:43:06 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:301958 Archived-At: > Date: Tue, 27 Dec 2022 14:43:06 +0200 > Cc: monnier@iro.umontreal.ca, theophilusx@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov > > > WDYT about what we have in NEWS about this? > > Those instructions seem to be written foremost with distro maintainers > in mind. Or users who build and install Emacs by themselves. Frankly, I don't see why we, the upstream project, need to worry about anyone else. It isn't our job. That's what distros are there for. > Definitely better to have them than not, but I'd hate to present > them to the average user. "Hate"? That's a strong word. The questions that the NEWS entries answer were asked here and elsewhere several times, so presumably that information has some non-trivial value. > Do we expect all (most?) distros to compile all the popular grammars? I honestly don't know. On the one hand, there aren't many Emacs modes which use tree-sitter, but OTOH they could start growing like mushrooms once Emacs 29 hits the streets. I do expect them to offer the ones they consider useful/needed, for some value of that. I really don't see any significant difference in this regard between grammar libraries and, say, librsvg. Both are used in Emacs, and the lack of either disables useful Emacs features. So it's a no-brainer for me. But then I'm not a distro maintainer, and never have been. > That would still leave out the users of the less popular languages whose > grammars were not included. Or grammars which saw updates since the > distro-distributed version (so it's useful to install the newer version). What's the solution? All the "solutions" I saw until now require a working and well-configured C/C++ compiler (sometimes both C and C++), linker, and C/C++ runtimes. A user who has them already installed can easily build a grammar library with two simple commands. A user who doesn't have a C/C++ development environment will not find those "solutions" useful at all. And asking us to distribute binaries for half a dozen popular systems is IMNSHO unreasonable. > > It sounds like a non-trivial maintenance burden to keep this kind of > > DB up-to-date. So I'm not sure we should do this in the upstream > > project. > > > > But if Someone(TM) wants to provide Emacs commands to download, > > compile, and install a grammar library, I see no reason not to add > > that to Emacs. This could be part of treesit.el, for example. > > I wouldn't worry too much about the maintenance burden (keeping the list > of urls up-to-date?), especially since we could refer to such lists by > other projects. I cannot disagree more. Look at this from my POV: once the list becomes even semi-official, people will expect it to be of the same high quality as all the rest of Emacs, and they _will_ complain and report inaccuracies. It's a nuisance, especially for such a "hot" feature set. And which "other projects"? who can track those and know which ones have the most accurate, up-to-date, and comprehensive list? I'm a bit interested in this (and have several dozens of grammar libraries built locally), and I discover another project with a useful list of grammars almost every day. These things are highly dynamic: I see some of the grammars get updates every couple of days. Some languages have more than one grammar library maintained by different people -- who will figure out which one is better for us and keep that information up-to-date? > I think ELPA is a better place for this feature, though. Because we > always want the user to get the latest version of the recipes. That solves only part of the problem. (And not an important part: our Git repository is public, so people can track it and download updates for files as easily as they track ELPA.) The hard part -- keeping the information accurate and up-to-date -- still needs a motivated volunteer. And we hardly have resources to work on our code and docs, let alone help people install external software. (Of course, if such a motivated volunteer steps forward, he or she will be most welcome.)