From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#74339: 30.0.92; CC Mode stomps C TS Mode Date: Sun, 17 Nov 2024 08:31:25 +0200 Message-ID: <86ldxiwev6.fsf@gnu.org> References: <86cyiwimlr.fsf@gnu.org> <864j47iobz.fsf@gnu.org> <86ttc7f7jo.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30708"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 74339@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 17 07:32:17 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1tCYpV-0007sH-7x for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Nov 2024 07:32:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tCYpJ-0003ck-Vt; Sun, 17 Nov 2024 01:32:06 -0500 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 1tCYpG-0003cV-NF for bug-gnu-emacs@gnu.org; Sun, 17 Nov 2024 01:32:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tCYpG-000118-Bg for bug-gnu-emacs@gnu.org; Sun, 17 Nov 2024 01:32:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=mGML0bVuJdBTR/AaqShmTAZ0y1fTl3dz2ELAUmSiSSg=; b=AbxdDqq5iSzZel9hUV6UiaCJHoYcLsM7yqW0GirTm6Nlj75T8AoWvXqIHW63XZnfD85tcCo3AAKKdhCwdHcWvafClOzCgKNZElbyr+lwdA/h6uudOFR2klKOoyQCVjptjXic0O+4dk2RQwCQvWrnJImspmaXz4GOTeMom1Z9s93jrt3ien3m4s+oU/cJrjJWyW0jrHUkvrVWyvj9P1HF9GmEyLP8jes1E1bGmfZDCG6fzgsViSgus5v71htsi53OwGuepp7F6BDz8KU1pMBLd6e352C3TbHb7ydshgpGUYZJ3pL6S+JJCic/ZDlaNFwaT0C0zBIITDln2hw2iv2Uog==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tCYpG-0008Aj-5G for bug-gnu-emacs@gnu.org; Sun, 17 Nov 2024 01:32:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2024 06:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74339 X-GNU-PR-Package: emacs Original-Received: via spool by 74339-submit@debbugs.gnu.org id=B74339.173182509631369 (code B ref 74339); Sun, 17 Nov 2024 06:32:02 +0000 Original-Received: (at 74339) by debbugs.gnu.org; 17 Nov 2024 06:31:36 +0000 Original-Received: from localhost ([127.0.0.1]:55703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCYop-00089s-Me for submit@debbugs.gnu.org; Sun, 17 Nov 2024 01:31:36 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:48344) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCYon-00089e-Np for 74339@debbugs.gnu.org; Sun, 17 Nov 2024 01:31:34 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tCYoh-0000zn-VO; Sun, 17 Nov 2024 01:31:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=mGML0bVuJdBTR/AaqShmTAZ0y1fTl3dz2ELAUmSiSSg=; b=ke+SzG86SqD+ 74lO1H0dI6fRBQrIHFMlDOnRn2OKM4zWagwl15DpuvJZGenovNyljPOu5YywEZRwJn+Gm2tXR88X2 NL91wTxE4dBCGRGQ9x7N7+rOnYhzdQA6uuXMZHTCw5CTFbQR/QDdiQnPnEwxLR8CWK1FKpw6KZaCD TzOAOmLPu/Jc3nTqHWlNXOsygkH2DdMO0j2RrNIf1X3oXHD365e47iF21KSjokf4+T+3RBYeJG/7q V5Efq5keDwaLm1INsCY1ERDKbTeEKZQGlUiSrlG6jxd0Mwi1sxu3NOtOmknfasvrxE+iFDHqkJ6mn 4GZyE2FQscVc98q/71pSDA==; In-Reply-To: (message from Alan Mackenzie on Sat, 16 Nov 2024 21:56:03 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:295510 Archived-At: > Date: Sat, 16 Nov 2024 21:56:03 +0000 > Cc: 74339@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > > > I don't and can't agree to these changes as they're currently proposed. > > > My concerns expressed over the last few days haven't been addressed; > > > they've merely been dismissed. In effect, you're proposing just > > > reverting my patch from May, without addressing the reasons for that > > > patch. > > > No, not to revert: to amend it in relatively minor ways. > > No. Nullifying it's main purpose and leaving only a toothless hulk is > not relatively minor. The purpose of the patch was to protect CC Mode's > symbols. It had unfortunate side effects, hence this bug. What kind of protection did you have in mind, and how does the current code in cc-mode provide that protection? > > Specifically, I'm asking not to add these entries to > > major-mode-remap-defaults: > > > (add-to-list 'major-mode-remap-defaults '(c++-mode . c++-ts-mode)) > > (add-to-list 'major-mode-remap-defaults '(c-mode . c-ts-mode)) > > (add-to-list 'major-mode-remap-defaults '(c-or-c++-mode . c-or-c++-ts-mode)) > > > Instead, _remove_ them from the list (if they are in the list). The > > rest, i.e. adding the elements that "remap" c-mode to itself, viz.: > > > (dolist (mode '(c-mode c++-mode c-or-c++-mode)) > > (if (and (setq entry (assq mode major-mode-remap-defaults)) > > (null (cdr entry))) > > (setq major-mode-remap-defaults > > (delq entry major-mode-remap-defaults))) > > (push (cons mode nil) major-mode-remap-defaults)))) > > > Can and should stay. (Btw, it is better to use assq-delete-all, > > because the above removes only the instances of the first element for > > each mode that it finds in the list. Btw, doing so will also avoid > > the need to add the 3 entries above, AFAIU.) > > Can you perhaps suggest another way of protecting CC Mode's symbols in > place of the patch which is to be amended/removed? I need to understand what you mean by "protection of symbols" before I can suggest anything. > > > I have proposed two ways of fixing the immediate problem, both of them > > > simple, easy to review, and easy to test. You have rejected them both. > > > It seems it is more important to release Emacs 30 soon that to get it > > > right. > > > We cannot always set everything right when the release is close. What > > is being proposed to fix this issue will make things a little bit > > better than they were in Emacs 29, and certainly no worse. We will > > need to try to find better solutions in Emacs 31. > > > By contrast the solutions you proposed are much more risky, as they > > touch areas that are not directly related to the code which caused the > > issue at hand, and because they will have a broader effect. They are > > therefore inappropriate for a release branch that is in its 2nd > > pretest. > > Why MUCH more risky? They're a little bit more risky, perhaps. Let's agree that they are "more risky". > In the time we've been discussing the matter, one of them could have > been implemented and now be under review/test. The problem is not with the time it takes to implement a solution, the problem is with the time it will take to verify it doesn't have any unintended consequences and doesn't cause regressions elsewhere. With the changes I proposed, the probability of such adverse effects is very low, because the changes are local to the code whose effect we now understand well enough, having discussed it here so extensively. By contrast, the other proposals modify other parts of Emacs, and thus their effect is less certain. Which means they will delay the release. > For that matter, the amended patch you're proposing hasn't really been > tested either. It's a minor change in code whose effect is now understood very well. And I did test something very similar in my sessions, once I discovered the issue and understood what causes it.