From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: treesit indentation "blinking" Date: Mon, 3 Apr 2023 12:56:51 +0000 Message-ID: References: <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: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30744"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= , Yuan Fu , Eli Zaretskii , theodor thornhill , geza.herman@gmail.com, Daniel Colascione , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 03 14:57:52 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 1pjJku-0007s2-Fi for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Apr 2023 14:57:52 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pjJk4-0004p9-RD; Mon, 03 Apr 2023 08:57:00 -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 1pjJk2-0004nW-Q0 for emacs-devel@gnu.org; Mon, 03 Apr 2023 08:56:58 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pjJjz-000489-HX for emacs-devel@gnu.org; Mon, 03 Apr 2023 08:56:58 -0400 Original-Received: (qmail 73758 invoked by uid 3782); 3 Apr 2023 14:56:52 +0200 Original-Received: from acm.muc.de (pd953abee.dip0.t-ipconnect.de [217.83.171.238]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 03 Apr 2023 14:56:52 +0200 Original-Received: (qmail 7188 invoked by uid 1000); 3 Apr 2023 12:56:51 -0000 Content-Disposition: inline In-Reply-To: <6efb9f84-211d-560e-3196-95d7f0b8be19@yandex.ru> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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:305073 Archived-At: Hello, Dmitry. On Mon, Apr 03, 2023 at 15:07:11 +0300, 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? Maybe sometimes, but often not. > > 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. OK. > This is not a substitute for enabling electric-pair-mode, alas. As you've no doubt gathered, I particularly dislike electric-pair-mode. I'm likely far from rare in that respect. I think we'll be doing our users a disservice if indentation only works when e-p-m is enabled. > Just a less hackish way to check the same thing rather than check for > this particular mode being enabled. > I would also prefer c++-ts-mode supported indentation with closing > braces missing, but we're really limited by what the parser provides. > E.g. for this code > int foo() { > for (;;) { > we get this parse tree: > (ERROR (primitive_type) > (function_declarator declarator: (identifier) > parameters: (parameter_list ( ))) > { for ( ; ; ) {) > where the "for" statement isn't even present (the separate tokens are > parsed as leaf nodes, and that's it). It's difficult to write meaningful > indentation rules that would match this. Why do we get a parse tree with ERROR in it when the source isn't erroneous? It is merely incomplete. Tree sitter was surely designed for editors, where source code being entered is typically incomplete, not just for things like code formatters. Why do we not get a full valid parse tree indicating the current (incomplete) state? -- Alan Mackenzie (Nuremberg, Germany).