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: Update on tree-sitter structure navigation Date: Sat, 09 Sep 2023 09:32:00 +0300 Message-ID: <83sf7nvov3.fsf@gnu.org> References: <5E7F2A94-4377-45C0-8541-7F59F3B54BA1@gmail.com> <8a5b3b3e-f091-3f38-09d4-c4e26bec97f9@yandex.ru> <83h6o5xj4f.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12359"; mail-complaints-to="usenet@ciao.gmane.io" 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: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 09 08:33:18 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 1qerWw-00030C-Dk for ged-emacs-devel@m.gmane-mx.org; Sat, 09 Sep 2023 08:33:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qerVu-0000MT-BK; Sat, 09 Sep 2023 02:32:14 -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 1qerVs-0000M3-ND for emacs-devel@gnu.org; Sat, 09 Sep 2023 02:32:12 -0400 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 1qerVq-0000g6-Fy; Sat, 09 Sep 2023 02:32:10 -0400 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=qAoHFhqDdIyzwOfV8HQN/3Zn4lMe7u9fxJRhHqXOeak=; b=h/Q13up+2VIj ZJFDa3oNRYzUDmS1lj9J7Md6q/Pu96Xid2/9c/arMtpAVNY91SnOtaqyzr7ITDSStI0zXZ4R/znyf NyQUD0tBkT5mB2ubgdb1j8V+2M4l1rZ+YQRbRPJQ5vSmULp4lR1MaWIGcVizGUsOM7FZSTK7Z9twV 9DHeU9s2IGPaJAyg8uEe2GUnRz9pamtFMDapXtg38XNw5W+5H8PaY7C8+Qbn4YUjEf56Yiqbk9Vyy EWzZ+XmxuLzUTiYI4fUj0zYKbBIW7vz4eDfYJpeBCPg6FuaNTSNEeV+yaNPqx9vE6CFZsiaBawljH VcNtZwyqKCGarPOKf8wJrw==; In-Reply-To: (message from Dmitry Gutov on Fri, 8 Sep 2023 23:52:48 +0300) 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:310387 Archived-At: > 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? > 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. 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. > 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). 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.