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: Sun, 2 Apr 2023 17:04:06 +0000 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: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14029"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuan Fu , Eli Zaretskii , theodor thornhill , geza.herman@gmail.com, Daniel Colascione , emacs-devel@gnu.org To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 02 19:05:05 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 1pj18b-0003Pj-H7 for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Apr 2023 19:05:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pj17l-00015z-IX; Sun, 02 Apr 2023 13:04:13 -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 1pj17j-00015l-LK for emacs-devel@gnu.org; Sun, 02 Apr 2023 13:04:11 -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 1pj17h-00043B-GN for emacs-devel@gnu.org; Sun, 02 Apr 2023 13:04:11 -0400 Original-Received: (qmail 65932 invoked by uid 3782); 2 Apr 2023 19:04:07 +0200 Original-Received: from acm.muc.de (pd953a231.dip0.t-ipconnect.de [217.83.162.49]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 02 Apr 2023 19:04:06 +0200 Original-Received: (qmail 16988 invoked by uid 1000); 2 Apr 2023 17:04:06 -0000 Content-Disposition: inline In-Reply-To: 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:305039 Archived-At: Hello, João. On Sun, Apr 02, 2023 at 16:48:55 +0100, João Távora wrote: > On Sun, Apr 2, 2023 at 3:26 PM Alan Mackenzie wrote: > > > I think it’s acceptable to say that users of ts-modes should enable > > > electric-pair-mode, since it’s based on a parser, after all. > > 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-chars > 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. > 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 specifically. 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 least > 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. > 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. [ .... ] > > I've had to use a proprietary editor where e-p-m couldn't be > > disabled (or at least I didn't know how to), and I hated it. Emacs > > should be better than such editors. > 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. > João -- Alan Mackenzie (Nuremberg, Germany).