From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Update on tree-sitter structure navigation Date: Sat, 9 Sep 2023 20:04:07 +0300 Message-ID: References: <5E7F2A94-4377-45C0-8541-7F59F3B54BA1@gmail.com> <8a5b3b3e-f091-3f38-09d4-c4e26bec97f9@yandex.ru> <83h6o5xj4f.fsf@gnu.org> <83sf7nvov3.fsf@gnu.org> <580010af-7328-768d-b1c2-d80d7099a290@yandex.ru> <83a5tvvaoo.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32747"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: casouri@gmail.com, emacs-devel@gnu.org, danny@dfreeman.email, theo@thornhill.no, jostein@secure.kjonigsen.net, dev@rjt.dev, wkirschbaum@gmail.com, pedz@easesoftware.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 09 19:04:46 2023 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 1qf1Nz-0008KN-UM for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Sep 2023 19:04:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qf1Nj-00012Z-I4; Sat, 09 Sep 2023 13:04:27 -0400 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 1qf1Nh-00011Y-Vs for emacs-devel@gnu.org; Sat, 09 Sep 2023 13:04:26 -0400 Original-Received: from forward102a.mail.yandex.net ([178.154.239.85]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qf1Nc-0006uQ-Fa; Sat, 09 Sep 2023 13:04:25 -0400 Original-Received: from mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net [IPv6:2a02:6b8:c0f:5d0f:0:640:79fc:0]) by forward102a.mail.yandex.net (Yandex) with ESMTP id 4B2BE46C75; Sat, 9 Sep 2023 20:04:16 +0300 (MSK) Original-Received: by mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id C4f5adNDTa60-7Jm7wVXo; Sat, 09 Sep 2023 20:04:15 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1694279055; bh=BWJizT5HSduQeSmXXKLlp3SxjVPxTGVF5fZh7qREXZE=; h=In-Reply-To:From:Subject:Message-ID:Cc:References:Date:To; b=RAvfG8bhXisiPBN7Mz7NYqOoNLH7PcqzFNpjQPAnN83NATCYvYCcVTDUfHXt4j77u xENUDnZnRgB2KFSsVdZov1JnlgwTc9cTtTkPu/SzJgQV2JveiwwPlYJ2nzqYfeWRe/ WZrrsjW+cAEUvTDm6g8dJkn/Zg9/cSyQXiQKh1Qg= Authentication-Results: mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 4BE3527C0054; Sat, 9 Sep 2023 13:04:12 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sat, 09 Sep 2023 13:04:12 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudehledguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughguhhtohhvseihrghnuggvgidrrhhuqeenucggtffrrg htthgvrhhnpedtffeggeekleetvedtkeeltefhfedtuddvgeektdekudejhfeftdevfedt ffduveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gughhuthhovhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudeffeefleel heehvddqvdelgeejjeejjeeiqdgughhuthhovheppeihrghnuggvgidrrhhusehfrghsth hmrghilhdrtghomh X-ME-Proxy: Feedback-ID: ib1d9465d:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 9 Sep 2023 13:04:09 -0400 (EDT) Content-Language: en-US In-Reply-To: <83a5tvvaoo.fsf@gnu.org> Received-SPF: pass client-ip=178.154.239.85; envelope-from=dgutov@yandex.ru; helo=forward102a.mail.yandex.net X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.473, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:310416 Archived-At: On 09/09/2023 14:38, Eli Zaretskii wrote: >>> No, that'd be worse than what we have now: those commit hashes will >>> quickly become outdated (most grammar libraries are very actively >>> developed), and create the false impression that any later version will >>> not work. >> >> But it's not the first thing the user sees, just internal information: >> we tested with this version last, it's known to work, so if you want to >> have a known well-working configuration, you will install this one. >> Might as well install the latest and try their luck, though. > > How is it useful to ask users to use, say, 2-year old versions of > grammar libraries, especially for languages where either the language > or the library (or both) change quickly? It would be better to use a 2-year-old grammar which works with our mode than a new grammar which breaks our mode anyway. We could also take a slightly more advanced approach: first install the latest version (if the user goes for 'M-x treesit-install-language-grammar' right away), and then in case of query errors suggest the version of the grammar known to work. But that's extra complexity (and more actions on the part of the user as well), and the actual benefit is hard to foretell. >> Further, most important grammars seem to be in a reasonably complete >> state by now. > > They add features and fix problems all the time. So I disagree with > the "reasonably complete" part, and so are the developers of those > libraries, evidently. Depends on the individual language, of course. >>> The job is to track all the commits of the corresponding libraries and >>> keep the last commit known to work constantly up-to-date, with delays >>> that are at most days, not weeks or months. >> >> Consider that js-ts-mode is "broken" in Emacs 29.1 now with the latest >> grammar. If there was the last-known-working hash, we could offer the >> users a friendlier way to install it. > > How is it friendlier to downgrade to an older version (which would > require fetching it, building it with a C compiler, and installing it) > than to patch a single Lisp file? Actually, people don't even need to > patch their Emacs installations, they could instead have a fixed > version of the Lisp file in their home directories or in site-lisp. So we'll suggest they manually copy the latest version of xxx-js-mode.el from master over to their site-lisp? That will be our recommendation in case a grammar breaks? I suppose we could publish all ts grammars in "core ELPA". Then the recommendation will be "just upgrade from ELPA" (though keeping in mind the associated usability problem like the one we discussed with Eglot). "Core ELPA" also inflicts certain restrictions on how the code in the package is written (backward compatibility checks, etc).