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: Mon, 03 Apr 2023 17:59:30 -0400 Message-ID: <1874921e1d0.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> References: <83bkka5z7w.fsf@gnu.org> <871ql6a4d4.fsf@gmail.com> <83jzyy4776.fsf@gnu.org> <9F152CAA-6326-459F-84FF-87988B3A92B6@gmail.com> <6bf0322b-1151-129a-e26f-61cf4f232d17@yandex.ru> <6efb9f84-211d-560e-3196-95d7f0b8be19@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="1874921e49a6122282938a3339" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15526"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: AquaMail/1.43.0 (build: 104300275) Cc: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Yuan Fu , Eli Zaretskii , theodor thornhill , , To: Dmitry Gutov , Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 04 00:02:13 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 1pjSFg-0003jo-CE for ged-emacs-devel@m.gmane-mx.org; Tue, 04 Apr 2023 00:02:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pjSEm-0003QL-Ar; Mon, 03 Apr 2023 18:01:16 -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 1pjSEi-0003P6-36 for emacs-devel@gnu.org; Mon, 03 Apr 2023 18:01:12 -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 1pjSDP-0007ca-Ch; Mon, 03 Apr 2023 18:01:11 -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=fqLV6XtFdqhHVc1SgYF7EbBFkOXodexgfDBjMpAaKww=; b=fVD2ZW9p8UQP418OumImJ0vXk4 S6WdZuflgR/mUalRiQVogYRqkemngClM3qTrrzb2R2xi45uabXB8iCPTf9/gKm6zPa6XfbqsSlJiJ moqBLtr4pYaTGtYfbI2kod0CObLBuuGZgwuX/c1ECA3ZSKkXeXriR3/MCSGTvPxqO9uhe4wgo9reH qPYD3+ePDA1263MfyT/+x04nk0mhPVeARHLc9fY6HJ7eNe1dN7QBlLLlZrB0nk+FbEPyk/1wXBl7v x4f7O2Y7+jjiVrqZ4/HrzO+hHAGdIULicuojqZBRhxFmvVWZey8o2kt6QkXYjwtAHKuNxiB/WpuyF lnAptK1g==; Original-Received: from 128.sub-174-228-174.myvzw.com ([174.228.174.128]:2008 helo=[100.106.210.128]) by dancol.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.94.2) (envelope-from ) id 1pjSD7-0004Xg-K4; Mon, 03 Apr 2023 14:59:34 -0700 In-Reply-To: <6efb9f84-211d-560e-3196-95d7f0b8be19@yandex.ru> 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:305088 Archived-At: This is a multi-part message in MIME format. --1874921e49a6122282938a3339 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit On April 3, 2023 08:07:17 Dmitry Gutov wrote: > On 03/04/2023 12:59, Alan Mackenzie wrote: >> Hello, Dmitry. >> >> On Mon, Apr 03, 2023 at 00:21:18 +0300, Dmitry Gutov wrote: >>> On 02/04/2023 20:23, João Távora wrote: >>>> So my initial idea was to tone down electric-indent-chars, at least >>>> for the moment. And Dmitry's idea was to make electric-indent-chars >>>> be ambitious_only_ if electric-pair-mode is enabled (by the user). >>>> Maybe we should bring back that idea, and it seems the least bad of the >>>> bunch right now. >> >>> Alternatively, we only perform "electric indent" (aside from after RET) >>> when the parse tree does not contain errors. >> >> That is NOT electric indentation. The whole point about electric >> indentation is for it to take effect whilst point is still on the line >> being edited. Thus, for example, you can see whether or not the line >> needs breaking, or whether there's room for a short comment at the end >> of the line. > > Wouldn't you know whether the line needs breaking, as long as the line > was indented correctly when you opened it with RET? > >> What you're proposing is something which would almost never trigger, >> since a line being edited will not have a parse tree without errors (if >> I've understood that properly). If it did trigger at some point, that >> would likely cause annoyance and puzzlement. > > That's a fair assessment, but it's going to trigger in a lot of cases > still: after ;, or after a paren or brace being closed. Silly question: can't we make a mode with c++-mode's indentation (and folding etc.) and c++-ts-mode's fontification? Such a thing would also preserve compatibility with the numerous ad hoc c++-mode styles out there. --1874921e49a6122282938a3339 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On April 3, 2023 08:07:1= 7 Dmitry Gutov <dgutov@yandex.ru> wrote:

On 03/04/2023 12:59, Alan Mackenzie wrote:
Hello, Dmitry.

On Mon, Apr 03, 2023 at 00:21:18 +0300, Dmitry Gutov wrot= e:
On 02/04/2023 20:23, Jo=C3=A3o T=C3=A1vora wrote:
So my initial idea was to tone down electric-indent-chars= , at least
for the moment.  And Dmitry's idea was to make elect= ric-indent-chars
be ambitious_only_  if electric-pair-mode is enabled= (by the user).
Maybe we should bring back that idea, and it seems the le= ast bad of the
bunch right now.

Alternatively, we only perform "electric indent" (aside f= rom after RET)
when the parse tree does not contain errors.

That is NOT electric indentation.  The whole point a= bout electric
indentation is for it to take effect whilst point is stil= l on the line
being edited.  Thus, for example, you can see whethe= r or not the line
needs breaking, or whether there's room for a short comme= nt at the end
of the line.

Wouldn't you know whether the line needs breaking, as lon= g as the line 
was indented correctly when you opened it with RET?

What you're proposing is something which would almost nev= er trigger,
since a line being edited will not have a parse tree with= out errors (if
I've understood that properly).  If it did trigger a= t some point, that
would likely cause annoyance and puzzlement.

That's a fair assessment, but it's going to trigger in a = lot of cases 
still: after ;, or after a paren or brace being closed.

Silly ques= tion: can't we make a mode with c++-mode's indentation (and folding etc.) a= nd c++-ts-mode's fontification? Such a thing would also preserve compatibil= ity with the numerous ad hoc c++-mode styles out there.
--1874921e49a6122282938a3339--