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.bugs Subject: bug#26217: bug#2910: 23.0.60; Shell-script coloring bug Date: Sat, 14 Oct 2023 22:49:18 +0300 Message-ID: References: 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="39464"; 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: Martin Vath , Mauro Aranda , 26217@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 14 21:49:51 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qrkdy-000A78-Ee for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Oct 2023 21:49:50 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qrkdn-0002Vm-Qn; Sat, 14 Oct 2023 15:49:39 -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 1qrkdm-0002VX-Iv for bug-gnu-emacs@gnu.org; Sat, 14 Oct 2023 15:49:38 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qrkdm-0003Aw-96 for bug-gnu-emacs@gnu.org; Sat, 14 Oct 2023 15:49:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qrke9-0008FA-Q5 for bug-gnu-emacs@gnu.org; Sat, 14 Oct 2023 15:50:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Oct 2023 19:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26217 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed patch Original-Received: via spool by 26217-submit@debbugs.gnu.org id=B26217.169731300031677 (code B ref 26217); Sat, 14 Oct 2023 19:50:01 +0000 Original-Received: (at 26217) by debbugs.gnu.org; 14 Oct 2023 19:50:00 +0000 Original-Received: from localhost ([127.0.0.1]:50589 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qrke7-0008Er-Oj for submit@debbugs.gnu.org; Sat, 14 Oct 2023 15:50:00 -0400 Original-Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:49149) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qrke2-0008EZ-Bj for 26217@debbugs.gnu.org; Sat, 14 Oct 2023 15:49:57 -0400 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 36C0D32009F7; Sat, 14 Oct 2023 15:49:23 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sat, 14 Oct 2023 15:49:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1697312962; x=1697399362; bh=kvfZ22V5oihN3dcT6+TqW7SK3XhF//hn7hv eka14Vqg=; b=GHtbPIZ0ZHhVaEED4GYOIecNgLZ8OCLkTo5qxrHf+D9FkTmjd87 n7BFJlc4etaDhIvn5eCPyiFvwEGvUeI15hlFEFBR6/6OkbH6XWqwNGksSQwClo6X FQFYR9y3axvh0zJJb4u44J81tjieOvIUzxQkLkqikuubcr4RHUqBeHqrDr/Xj/P5 UNpqLxXLbj0ihrkjlAzDkbZRYTq1Rr4siQQolvI8Mzn/CjIXHd6Q9JIb7Guq5K2P 3N33vRW5Q05X2MnFMXhmmKrsKX/EG1iWIwKdX/WwtV3n67JBBaEhci87jlwSIQyB cJz6cKeH8K+ZhhFkYyzdH4QQacAzzs0D/ZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1697312962; x=1697399362; bh=kvfZ22V5oihN3dcT6+TqW7SK3XhF//hn7hv eka14Vqg=; b=T6vljFkiPQAjPMOZhhhtab1gBkq7ZJi5wz2ZUnpNy1vygwYngOf kvqp876VCyu8wFp0LuhwXafJsd0BytJCsGUmLSqgo6qY8P0UbupFV2HRh1YiNmiM QfJu8+aSdJ3jSRwTGKnLiwQm4JLPUplBdWd7foLRclKuvzIrW+wqQpge0Jj2yxTe JUfBMtHcxqRhrk/rkrdyW+Gl2GI2NwyooBBDUtJOuiT23h8uUCZls831ITtuz/s6 qehjHh7KAkq03sK7fb8VbXAvs5w3zbjudlN+vgfHv4pcGxFcFON7JPFH3whotXxM 3rwyzSog0UqHz7vW1/bE84GaSgMZ4EwkaLA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrieehgddugedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteeujeduudehkefhveekleetffevudefheffuddvleeglefgteekjedugeeu veffnecuffhomhgrihhnpegtohguvghmihhrrhhorhdrnhgvthenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdr uggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 14 Oct 2023 15:49:21 -0400 (EDT) Content-Language: en-US In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:272467 Archived-At: On 14/10/2023 22:07, Stefan Monnier wrote: >>> FWIW, it's not clear at all what such a layer would look like, so we're >>> pretty far from it. I'd welcome people start thinking about it, maybe >>> by looking at existing alternatives like our own `wisi` (in GNU ELPA), >>> SMIE, maybe LSP (assuming there are servers out there which can provide >>> that kind of functionality), etc... >> I don't know how feasible that would be, > > That's the wrong way to look at it. There is no doubt that it > is feasible. What is under question is what it would take. And whether it would be in any way more economical than just waiting for the next comparable solution to come along and writing either compatibility shims inside each ts mode, or copying code and adapting into the next set of *-ts-mode modes. So for now we could be better off just coming up with an easier way to migrate user configurations across major modes for a given language than what we have now. >> given that the ts major modes we write have to reference fairly low >> level concerns (such as node names, different across all grammars). > > That just means that a given set of highlighting/indentation rules would > not necessarily work with all possible parser-backends. But maybe we > could bridge the gap by allowing some intermediate layer that could do > things like translate node names (could be useful even within the > tree-sitter context to deal with evolving grammars). That's not impossible, but IME the sets of rules are fairly uniformly lower-level. > I'm not saying this is the way to go, mind you. I don't know how it > could/should work. > > But I do think we could do worse than start thinking about it, because > tree-sitter is the kind of technology that's on the "treadmill", whereas > Emacs' evolution has a different pace: how well will Emacs-29's TS modes > work with 2028's tree-sitter grammars? 1. That's why I'm sure we'll start using some grammar pinning - either to the commit hash, or to the version range. 2. Overall it's a solid point: either tree-sitter "stabilizes" after a while, or goes off the map. >> Maybe porting Lezer (https://lezer.codemirror.net/) could become > > Interesting, thanks. > >> a replacement in such a scenario, but then we're back to maintaining >> our own grammars again, and with lower performance by an order of >> a magnitude. > > We could look into Lezer support just to help us guide the design of an > intermediate layer API. No need to maintain lots of our own grammars or > take the performance impact :-) It's as good an approach as any, though we have no guarantee that the "next tree-sitter" will have a similar enough shape to either of TS or Lezer, for an easy future migration.