From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: treesit indentation "blinking" Date: Thu, 30 Mar 2023 18:14:19 +0100 Message-ID: References: <87h6ucik61.fsf@dancol.org> <0F406D08-56D4-4B21-B94D-A47681606911@gmail.com> <1870bcadd28.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <1870cce6690.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <35A837A9-59B4-4F1F-A5FA-8483C8024D76@gmail.com> <187104f6b48.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <21d018e5-a730-12e3-f97c-fffa4f646ccf@yandex.ru> <83v8ioc2ou.fsf@gnu.org> <87sfdsx0r2.fsf@gmail.com> <87lejgsf0m.fsf@gmail.com> <83pm8s70o3.fsf@gnu.org> <83mt3u65vw.fsf@gnu.org> <87y1newqus.fsf@gmail.com> <6987b4f9-bb90-07cf-b64c-612574dff29e@yandex.ru> <87tty2wpt8.fsf@gmail.com> <4d8df485-adcb-64f3-742f-37c9a9a40f65@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5679"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , dancol@dancol.org, casouri@gmail.com, emacs-devel@gnu.org, theo@thornhill.no To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 30 19:15:37 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 1phvs8-0001HF-Lj for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Mar 2023 19:15:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1phvrB-0005eU-8S; Thu, 30 Mar 2023 13:14:37 -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 1phvr8-0005Qe-Qj for emacs-devel@gnu.org; Thu, 30 Mar 2023 13:14:34 -0400 Original-Received: from mail-il1-x12d.google.com ([2607:f8b0:4864:20::12d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1phvr6-0006qi-RL; Thu, 30 Mar 2023 13:14:34 -0400 Original-Received: by mail-il1-x12d.google.com with SMTP id h11so10140948ild.11; Thu, 30 Mar 2023 10:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680196471; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JeUvOYwDOkm3raWK/8mhSaFQbJbvLI+ViCOxwsxE5oE=; b=EFmpJrMdcJRY9EyNcX6r68T3N0nJ0yKquqiLL7nwpeop+5GW1H7V2erycVtEFKfO3O dpa+NzCt0tmuipZLSiMCnQNt7zCG2ddivO4jfUNcmiyNYZKC5DEdIM/NiuBjybVwuwHP D50Oyr5ZgRAcCaET35zj8guuc644yp5hrpdWC7Zb5W0oN54RwLZdJZItEMh34y4/kvRr DYwu1EkVXVpOQUvyyitYT1BNH7pur5Yc7anDE/D0h4FvX8TRj0HTdkKMYMG8pKebuvGL H9Kf3Q1h+zQ96pkqdec71zzEWcnzpwpXpWVrX7i//oda1BR8ikGNq6aJb9bycrS4FW/n JXNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680196471; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JeUvOYwDOkm3raWK/8mhSaFQbJbvLI+ViCOxwsxE5oE=; b=J+4yki+unIVjN/kGi2J/r/+WocOFka+EbWEF6ZlOa9/FCJpVPx0NQHA96d5CYlqUDo QFRQ5GjfERudfRGC4uNpr+uYA/jnA4N+dGDZOpZyOzT/pmGtUAhl9VSPhCx9Cr0yJoUo q7uDLD0Zgl7RlJPkPVM7y1LJDwe08XnoEA1tai4vSx3qvxrxBeQqkvX16UKVVP9+J3Jt fO6DqhW7jw6rL+sqPLplGbGE99xN9cNEm0LcRU1wP6qTtP6z4e0sqKCGXDq5CXz7i6YB MyYKMNj8zy84b6be3EkKToN/AEcIx6VYxJl2I5nE3ERpRVeLrbPkz6us+SBFErveoYKO YO7g== X-Gm-Message-State: AAQBX9dD2tuHHGuTIb2svUbZKJA0cMvbG88wWGj7lh2Vyz47y1tsAzV5 PahQyq5jYJKqLIglWSM1XJSXzbr+z4bxDNOWsHU= X-Google-Smtp-Source: AKy350Z1IuEFoc1P9KIIfJm4Xmg8KoSaJ8VVZ0jCjANeNglQCzKXiNIPBpivfQwl8MVyMU95VvAGXDK69mCTlPKRoZo= X-Received: by 2002:a92:8e0a:0:b0:324:5b4c:7087 with SMTP id c10-20020a928e0a000000b003245b4c7087mr11540478ild.0.1680196470840; Thu, 30 Mar 2023 10:14:30 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::12d; envelope-from=joaotavora@gmail.com; helo=mail-il1-x12d.google.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:304878 Archived-At: On Thu, Mar 30, 2023 at 5:29=E2=80=AFPM Dmitry Gutov wro= te: > In this instance, removing chars off electric-indent-chars won't conceal > the problem: the user can still type RET or press TAB and see unexpected > indentation where Emacs should have been able to guess the correct one. electric-indent-chars exacerbates an existing problem. IOW, it's much easier to live with incorrect indentation for temporarily invalid programs if it's not shuffling the ground under your feed as you type, which I think is exactly what was reported here. It's perfectly analogous with electric-pair-mode. It only makes sense to turn it on if the syntax code counting openers and closers is doing its job. Else it's just a nuisance. So it only makes sense to have an ambitious electric-indent-chars or even electric-indent-mode at all if the indentatio= n rules are solid and predictable. Which they are to a certain extent in c+ +-mode and to much lesser extent in c++-ts-mode. And even if c++-ts-mode's could be made easily predictable, making them match c++-mode's exactly probably still another job. One that I personally wouldn't bother with. I don't know if that's the goal. > > What counts as "broken" indentation is also arguable though. When deali= ng > > with invalid programs, there is really no "right" or "wrong" indentatio= n. > > See my message https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D62412#14= where > > I show cases where c++-ts-mode's answer to indenting an invalid program > > makes more sense than c++-mode's answer. > > It's not cut-and-dried indeed, but historically, with the "native" major > modes we, wittingly or not, have used the principle that code fully > typed until point is considered "decidable", even if some missing code > after point makes the it incomplete. Even though, on rare occasions, > continuing to type might change the indentation again (e.g. for "case > labels", if the indent style dedents them). Yes, true. But as Stefan once pointed out, that's just an arbitrary decision. Though I agree it's a fairly consistent one. Probably because I'm also used to it. It could be the other way around and look backwards leaning towards facilitating editing of code instead of typing new code. > > Whatever the indentation rules, the current bouncing is so jarring > > that it really doesn't encourage people to try switching to > > c++-ts-mode, get used to its set of indentation rules, and then perhaps > > experience its other benefits like, say, performance or simplicity. > > > > At least it didn't for me. I'm back to c++-mode atm. > > > > In my opinion electric-indent-char should be reduced to the default > > and should be added criteriously as the indentation rules they trigger > > are fixed. > > We should probably revisit this after an honest attempt to fix these two > cases. Works for me. My point is that I won't be using much c++-ts-mode in the meantime. My guess is many users may be silently switching to it and then back away to c++-mode in part due to this misbehaving electricity. My point is that the mode should be more inviting to try out. Jo=C3=A3o