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.devel Subject: Re: treesit indentation "blinking" Date: Thu, 30 Mar 2023 19:29:44 +0300 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; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12806"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Cc: Eli Zaretskii , dancol@dancol.org, casouri@gmail.com, emacs-devel@gnu.org, theo@thornhill.no To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 30 18:30:39 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 1phvAd-00037x-0B for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Mar 2023 18:30:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1phv9s-0000Hh-Qz; Thu, 30 Mar 2023 12:29:52 -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 1phv9r-0000GP-3O for emacs-devel@gnu.org; Thu, 30 Mar 2023 12:29:51 -0400 Original-Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1phv9p-0003Ar-3T; Thu, 30 Mar 2023 12:29:50 -0400 Original-Received: by mail-wm1-x32e.google.com with SMTP id s13so11281647wmr.4; Thu, 30 Mar 2023 09:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680193787; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=XO2NIBV40Y7imZGINJ5b28/n6zP64XQvEb/p3QpU3Jc=; b=aBkYb2YvUW1Ow7Ip3yXzSSqqBGAZQfmAhgtEfcrmKRDq6O8F9kMwCZypuk3i6Fp1vK zOSICyDfLFx7U+qWmN5CiJvE0AaQwRtZJSHi6ulUq9ummwbfWvmlroOZV1N6qxo80tIi 9U3B1xx3eUqAAd/RR4cOHk/twhbqQvFjAbwfmlZH+9xATFCUgBzzvgV+u7r4MKQEIG9+ eUN6ywustoEjRiqg0W2jfNMAE6YChALR4vFS7VF6SNyRKNdUP+KFtVwE5G4uwtw/ZR60 n76pUlUAjINWNGt45LKJpNf35MukhDnWE38RJ/Yg08+2xSkU8z54eNZRfkb01Vf+YCLe EUnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680193787; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XO2NIBV40Y7imZGINJ5b28/n6zP64XQvEb/p3QpU3Jc=; b=cuso644eSI5Zm/CV/iTdw5ecQmBPmiiYDHhqyPJrg4n63JAuDkgwcu15mGBnFVWQgr V3X5gD/yq5Soxyx9WW6k6J6TzK/WEBwmDpCUYdkHD3/psAwmwtk7cXmS6GyZcRt2qsFL aEm6CEI2jSsIPeTnL7Q7/1NzrYD1Jjd6S8qwaXocmcbyE3SZyQDPcqnIMzJiEWgkJh/Z L+cm030mjBbOUi7EeH07jn1yxmyCpbnxxyNgJ42sUBQyZ+3WDwflQZsAgZlnvHT9cqKr +YSEAPVxt9MKGsC/jTnlyeNnOlGZfnPAZkklnPcLExdVqLZDC970IzH51CYroaQ6c/ni pxNw== X-Gm-Message-State: AO0yUKUI8QsvbIYAWUUske8yJNIxt1EThR9v25yYts9OSoRhHOw/5FKU 8o/rye4KO/g+/QRhYIi158mjBT18ucpWqA== X-Google-Smtp-Source: AK7set9qTfLF43BX2UVBWl/kRU9FOhh9VHq2sXVrTR6jvJnX0OGeWpnqePXYvM9gzCTNfMGILSduJA== X-Received: by 2002:a7b:cb92:0:b0:3ed:88f5:160a with SMTP id m18-20020a7bcb92000000b003ed88f5160amr18543377wmi.11.1680193786602; Thu, 30 Mar 2023 09:29:46 -0700 (PDT) Original-Received: from [192.168.1.2] ([31.216.80.60]) by smtp.googlemail.com with ESMTPSA id ip21-20020a05600ca69500b003edf2ae2432sm6296269wmb.7.2023.03.30.09.29.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Mar 2023 09:29:45 -0700 (PDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::32e; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32e.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:304875 Archived-At: On 30/03/2023 13:00, João Távora wrote: > On Thu, Mar 30, 2023 at 10:36 AM Dmitry Gutov wrote: >> >> On 30/03/2023 12:28, João Távora wrote: >>> This problematic already counts as "bouncing" to me, for some meaning of >>> "bouncing". c++-mode doesn't behave like that because indentation is >>> already where it is supposed to be if you type that sequence of >>> keystrokes. >> >> Okay, if that's what you meant. >> >> I think this one (indentation after RET in an incomplete function >> definition) should be fixed in the indentation rules. The contents of >> electric-indent-chars won't fix it either way. > > This is all down to indentation rules, that's how electric-indent-mode > decides what to do. My point is that having electric-indent-chars be > this ambitious with "broken" indentation rules isn't a good place to > be. 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. > What counts as "broken" indentation is also arguable though. When dealing > with invalid programs, there is really no "right" or "wrong" indentation. > See my message https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62412#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). > 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.