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 13:24:46 +0300 Message-ID: <580010af-7328-768d-b1c2-d80d7099a290@yandex.ru> References: <5E7F2A94-4377-45C0-8541-7F59F3B54BA1@gmail.com> <8a5b3b3e-f091-3f38-09d4-c4e26bec97f9@yandex.ru> <83h6o5xj4f.fsf@gnu.org> <83sf7nvov3.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="7401"; 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 12:26:07 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 1qevAE-0001g8-FO for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Sep 2023 12:26:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qev9V-0005mP-GI; Sat, 09 Sep 2023 06:25:21 -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 1qev9R-0005ls-TE for emacs-devel@gnu.org; Sat, 09 Sep 2023 06:25:17 -0400 Original-Received: from forward501b.mail.yandex.net ([178.154.239.145]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qev9I-0003Z0-34; Sat, 09 Sep 2023 06:25:16 -0400 Original-Received: from mail-nwsmtp-smtp-production-main-46.myt.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-46.myt.yp-c.yandex.net [IPv6:2a02:6b8:c12:3b27:0:640:a9e4:0]) by forward501b.mail.yandex.net (Yandex) with ESMTP id 16BD35EC23; Sat, 9 Sep 2023 13:25:02 +0300 (MSK) Original-Received: by mail-nwsmtp-smtp-production-main-46.myt.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id pOYJ6IKWliE0-rrK12GGJ; Sat, 09 Sep 2023 13:25:00 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1694255101; bh=v+odI/iRRtn5WCGrXCl5EyBqwAmKiR6n0yENNRte2n8=; h=In-Reply-To:From:Subject:Message-ID:Cc:References:Date:To; b=sC/+8bPVGfgN2wNJUVpgswVsBHwIyXopkJ9doHXznxwS4WNJJshGrzsQtSgbibS/h vmcK7XqpxdURtMq5GLSsZZOqlG2UZxEVr2bvq+oNiiElBhvBiFOaDXy1fcM5QW6dH2 FD2RoNihoAd/ndhWQLDU1MY043vaekEfGu/XjGZw= Authentication-Results: mail-nwsmtp-smtp-production-main-46.myt.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 40BF027C0054; Sat, 9 Sep 2023 06:24:51 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sat, 09 Sep 2023 06:24:51 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudehledgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegughhuthhovheshigrnhguvgigrdhruheqnecuggftrfgrth htvghrnheptdffgeegkeelteevtdekleethfeftdduvdegkedtkedujefhfedtveeftdff udevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hguhhtohhvodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqddufeeffeelleeh hedvqddvleegjeejjeejiedqughguhhtohhvpeephigrnhguvgigrdhruhesfhgrshhtmh grihhlrdgtohhm X-ME-Proxy: Feedback-ID: ib1d9465d:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 9 Sep 2023 06:24:48 -0400 (EDT) Content-Language: en-US In-Reply-To: <83sf7nvov3.fsf@gnu.org> Received-SPF: pass client-ip=178.154.239.145; envelope-from=dgutov@yandex.ru; helo=forward501b.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:310395 Archived-At: On 09/09/2023 09:32, Eli Zaretskii wrote: >> Date: Fri, 8 Sep 2023 23:52:48 +0300 >> Cc: emacs-devel@gnu.org, danny@dfreeman.email, theo@thornhill.no, >> jostein@secure.kjonigsen.net, dev@rjt.dev, wkirschbaum@gmail.com, >> pedz@easesoftware.com >> From: Dmitry Gutov >> >>> FTR, I have nothing against this technique, I just said that it will >>> need volunteers to assume this non-trivial job for each major mode, >>> and therefore I personally don't believe this to be a reliable >>> solution in practice. But if volunteers step forward to do this, I >>> don't object. >> >> I don't see a way around it, if the grammars continue to add breaking >> changes. > > If the only way we see is impractical, this doesn't help, does it? Is it definitely impractical if it's known to work for NeoVim? >> We already have volunteers: when somebody works on a ts mode (adds a new >> feature or verifies that the current font-lock and indentation work >> fine), might as well put in the last-known-good commit hash. Or update >> it, if needed (e.g. the new feature requires that). > > 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. Further, most important grammars seem to be in a reasonably complete state by now. So installing the known-to-work version shouldn't generally result in obvious omissions in language features supported. And, well, when a grammar adds support for new ones, we would likely have to update the major mode anyway (together with the hash). > 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. >> What I'm saying is in this case not doing this job well (e.g. updating >> the commit hashes and font-lock/indent rules very rarely) might still be >> better than not doing it at all. > > I strongly disagree. I think that doing this job not well is _worse_ > than not doing it. It takes just a few days, sometimes a couple of > weeks, from submission of the report about a breakage till a fix is > available, so people could install it soon enough and be done (since > these modes are not preloaded). But the ts modes in an Emacs release (now in 29.1, later in 29.2, etc) remain incompatible with any future grammar changes, right? > And we always strive to fix these > breakages in a way that makes the code more immune to further changes, > so there's hope that with time the frequency of these problems will > become lower. We can continue with this approach too (it's not incompatible with saving the last-known-hash anyway), and it could also be of benefit later if grammars grow proper versions, but it's also a bit of maintenance headache on its own.