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: Sun, 2 Apr 2023 18:23:57 +0100 Message-ID: References: <83mt3u65vw.fsf@gnu.org> <87y1newqus.fsf@gmail.com> <83bkka5z7w.fsf@gnu.org> <871ql6a4d4.fsf@gmail.com> <83jzyy4776.fsf@gnu.org> <9F152CAA-6326-459F-84FF-87988B3A92B6@gmail.com> 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="17043"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuan Fu , Eli Zaretskii , theodor thornhill , geza.herman@gmail.com, Daniel Colascione , emacs-devel@gnu.org, Dmitry Gutov To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 02 19:22:48 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 1pj1Pk-0004HV-3m for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Apr 2023 19:22:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pj1PA-0005by-Ad; Sun, 02 Apr 2023 13:22:12 -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 1pj1P8-0005bm-Ng for emacs-devel@gnu.org; Sun, 02 Apr 2023 13:22:10 -0400 Original-Received: from mail-oa1-x32.google.com ([2001:4860:4864:20::32]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pj1P6-0006y2-Pg; Sun, 02 Apr 2023 13:22:10 -0400 Original-Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-17fcc07d6c4so14386766fac.8; Sun, 02 Apr 2023 10:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680456127; 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=Bez/Il6Q69yIhJQi4Km6D4kKhSaO1Y8CnwHcOfxVOqY=; b=e3LVC6LIk3povUlQBSlsi9arK5g8fNTrVs1S85SZ7uGaFyq69XmDVXEFa8Uj7th8pj UjTBzRLTV5F79hucyvX0DFhNUmiGJJzKyM49sXqyhfExUt76u9RziAYMHvB4+itcDPwO HRpnuXBjmaiKytkqTAJ5RjWCt4WjE2Ptywnxaj58E56WzdxfL0yOS96IikdsPB7/h0lX UbD4ENtL3oMu/vBJkEAeDWA2H7AcAwVtL9ipz7BChWTOklcOMKBwR8yQtAX287qW4cmL pYY8T/OfhkDV4F8lCFyo/rGkuRvyAZAmexmCB88ySzqp6BEfGpr4hQZRwznRJo3w6mrX ijKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680456127; 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=Bez/Il6Q69yIhJQi4Km6D4kKhSaO1Y8CnwHcOfxVOqY=; b=rNfftukHdNgdTifOYihKNUg88B+74JNkxhavDyO+Dyg3ve2m59+Nuf1LCWUmPA9mSp fNLS/AAtgBNPuddAEkPpgilTdUhL1lh0DLtoPOk1EEIKTJ5sg7JKeTFQ3N6Ih/TXqVnr m5dLGRJNhNKXjhJAhRK+C7Qsp9j9LDvDWI/Q+ZxhteNvsX2WXHjVP/y/ZS7SAbBTLUrL awV7lICWudgt6fYRhsIYj742/f9TZ5Ij9FUlMuY2sldoJLGQtdCO5ar7mt6R5ZgzHNWo C2h9j44MbDtMQ46M2YacfWdg586QtMv0sSN3xPrqNw95WKvlmaBs0ev9gD3fHnCV2Nqc 1uww== X-Gm-Message-State: AAQBX9d0bMMGRbuSaeTFexkmBAPuA8xyaToGFYCvBaKeg+Sgg6BWJpoz qsRNrli9bGvKKcS71CHa1CBa4DPRB2DS/JPU920= X-Google-Smtp-Source: AKy350bnJqv4keXRufWlWdd8AHSO3WcL/Aq+WBb9oVKmuSNi4nRx4gWpoICNS0tTsswMRrldra3RAHq2mk8+IaBUXoA= X-Received: by 2002:a05:6870:f915:b0:176:3897:6928 with SMTP id ao21-20020a056870f91500b0017638976928mr11389865oac.5.1680456127032; Sun, 02 Apr 2023 10:22:07 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2001:4860:4864:20::32; envelope-from=joaotavora@gmail.com; helo=mail-oa1-x32.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:305042 Archived-At: On Sun, Apr 2, 2023 at 6:04=E2=80=AFPM Alan Mackenzie wrote: > > > electric-pair-mode is a user option. We shouldn't be mandating such > > > things to users, they should be individual choices. > > > Fair enough. But so is electric-indent-mode and its electric-indent-ch= ars > > which are problematic in c++-ts-mode and they _are_ enabled by default. > > Yes. Users should be able to chose from amongst these options. They > shouldn't be "problematic", and that was the point of my last post. And my point was underlying that electric-indent-chars and electric-indent mode is currently being "mandated", so to be consistent with your principle we might as well "mandate" neither of them. > > electric-pair-mode not only is unproblematic in c++-ts-mode (at least, = as > > far as we know) but is proven to be a good (though not perfect) defense > > against the real problems posed by the default value of electric-indent= -mode > > and the default value of electric-indent-chars in c++-ts-mode specifica= lly. > > It's not a "good defense" for somebody, like me, who doesn't like it. > It's not good for Emacs for options only to work when distinct other > options are also enabled. > > > So it makes sense to either have both e-p-m and e-i-m or none (or at le= ast > > less of the second as has been suggested). > > Not from a user's point of view. These two modes are wholly independent > of each other (from that user's point of view), and she should be able > to enable either or both, as desired, and have them work properly. But they don't, at least not at the moment. That's a fact. Of the two modes, one of them is working wholly inaccurately and not doing any good, and that mode is electric-indent-mode. Because of a combination of the ambitious value of electric-indent-chars _and_ the underlying indentation rules problems. 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. > > At least until the presumed indentation bugs (if in fact they are bugs > > at all) are fixed (if in fact there is an easy fix for them). > > I think it is clear there are bugs here. Electric indentation isn't > working. Yes. If we take c++-mode to be the absolute reference, no it isn't, and it's unlikely that it ever will. If we take a more modest stance and think of other editors that don't indent exactly like c++-mode, then the issue is more subtle. It's important to state that AFAIK when the buffer is correctly balanced, c++-ts-mode's indentation is flawless. We're talking about invalid situations here, and there it's harder to know what the "good" indentation is, but a nice rule-of-thumb could be "don't do anything". Another rule would be: do exactly what c++-mode does, but that's a taller order and I don't think we should be aiming for it. > > This comparison doesn't make sense to me because in Emacs it's easy to > > disable it. > > But disabling it hits the bugs in electric indentation. Yes! :-) So you'd tone down electric-indent-chars, but that's been turned down. So options are disable electric-indent-mode entirely in c++-ts-mode, enable electric-pair-mode, or live with poor ergonomics in emacs-29 until the bugs are fixed. Jo=C3=A3o