From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: treesit indentation "blinking" Date: Thu, 23 Mar 2023 00:51:08 -0400 Message-ID: <1870cce6690.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> References: <87h6ucik61.fsf@dancol.org> <0F406D08-56D4-4B21-B94D-A47681606911@gmail.com> <1870bcadd28.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="1870cce6f9a3b3e2829d89c077" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35548"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: AquaMail/1.43.0 (build: 104300275) Cc: To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 23 05:52:10 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 1pfCvp-0008yk-C1 for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Mar 2023 05:52:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pfCv4-0000zz-DU; Thu, 23 Mar 2023 00:51:22 -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 1pfCuy-0000zY-L9 for emacs-devel@gnu.org; Thu, 23 Mar 2023 00:51:18 -0400 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pfCuw-00051X-Hp for emacs-devel@gnu.org; Thu, 23 Mar 2023 00:51:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID: Date:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=C3u6iJA5IkbeOPrAM5XuoMxfHNh5/w/cNzY3Zcl0Ecc=; b=kjW8695+vzM4kLQJ2DNPCTNoxU S408hypjAs/NGI/Fioct/6s2IL950dbPCzLUvMVfWgYHZ0Pi1VCYf8oKuZpjDhlbxZfUlW/gtEWny oICOT55nRfxbYVzdjBVtUL/uiiqJ/xA/t9sPPkPPmUzPoIPesYu41+qEq4cZaBA+apmYV4rWWhmGa hpj23sezyxNqozWXIsa6Nqt4RpmF8WCx0hHAHfg1+dgN4Zbx+dbFC1NiEWvZXrCHsO177AH81PK9m U4vaKCRinIMPoE5w3QsTh67A9xnT+MkZzVLHC+P1dYQwDYGWayP4isXOGmWh5p63Bk9Eo+cyUGBUt kGxSujeA==; Original-Received: from 097-104-088-154.res.spectrum.com ([97.104.88.154]:41728 helo=[192.168.86.235]) by dancol.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.94.2) (envelope-from ) id 1pfCus-0001A9-5Y; Wed, 22 Mar 2023 21:51:11 -0700 In-Reply-To: Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@dancol.org; helo=dancol.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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:304730 Archived-At: This is a multi-part message in MIME format. --1870cce6f9a3b3e2829d89c077 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit On March 22, 2023 21:03:29 Yuan Fu wrote: >> On Mar 22, 2023, at 5:07 PM, Daniel Colascione wrote: >> >> >> >> On March 22, 2023 20:00:23 Yuan Fu wrote: >> >>>> On Mar 22, 2023, at 1:49 PM, Daniel Colascione wrote: >>>> >>>> Is there a general-purpose through which we can avoid line indentation >>>> oscillating as the user types when the AST is temporarily invalid, >>>> e.g. after '(' or '{'? I'm checking out the C++ tree-sitter mode, and >>>> one of the more disconcerting things is the current line's indentation >>>> changing rapidly as I type. Is it feasible to create ERROR recovery >>>> indentation rules for every conceivable situation? >>> >>> Yes, but in reality, I think all we need is a couple special case for the >>> unmatched ( and {’s. Can you think of other cases of blinking indentations? >>> >>> Yuan >> >> But TS reacts to missing closing brackets by clarifying the whole nearby >> expression as ERROR. It's not, as would be more useful, saying "here's a >> stray (, and everything else is normal and parsed as if that ( were absent” > > We can just look at the buffer text directly: if there’s an ERROR and the > previous char (after skipping whitespace chars) is ( or {, we know what to do Do we know what to do? That ERROR might be arbitrarily far up the parse tree. I don't think it's as easy as you think it might be. One strategy that might work is to see whether adding a "(" introduced an error, and, if so, temporarily replacing that "(" with whitespace, reparsing, and then using the resulting parse tree instead of the one with the "(" to do indentation and fontification. This way, I think you'd end up without the random jumping around we see today in TS modes. --1870cce6f9a3b3e2829d89c077 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On March 22, 2023 21:03:= 29 Yuan Fu <casouri@gmail.com> wrote:

On Mar 22, 2023, at 5:07 PM, Daniel Colascione <dancol= @dancol.org> wrote:



On March 22, 2023 20:00:23 Yuan Fu <casouri@gmail.com&= gt; wrote:

On Mar 22, 2023, at 1:49 PM, Daniel Colascione <dancol= @dancol.org> wrote:

Is there a general-purpose through which we can avoid lin= e indentation
oscillating as the user types when the AST is temporarily= invalid,
e.g. after '(' or '{'? I'm checking out the C++ tree-sitt= er mode, and
one of the more disconcerting things is the current line'= s indentation
changing rapidly as I type. Is it feasible to create ERRO= R recovery
indentation rules for every conceivable situation?


Yes, but in reality, I think all we need is a couple spec= ial case for the unmatched ( and {=E2=80=99s. Can you think of other cases = of blinking indentations?

Yuan

But TS reacts to missing closing brackets by clarifying t= he whole nearby expression as ERROR. It's not, as would be more useful, say= ing "here's a stray (, and everything else is normal and parsed as if that = ( were absent=E2=80=9D

We can just look at the buffer text directly: if there=E2= =80=99s an ERROR and the previous char (after skipping whitespace chars) is= ( or {, we know what to do

<= /div>
Do we know what to do? That ERROR might be arbitrari= ly far up the parse tree. I don't think it's as easy as you think it might = be. One strategy that might work is to see whether adding a "(" introduced = an error, and, if so, temporarily replacing that "(" with whitespace, repar= sing, and then using the resulting parse tree instead of the one with the "= (" to do indentation and fontification. This way, I think you'd end up with= out the random jumping around we see today in TS modes.
--1870cce6f9a3b3e2829d89c077--