From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Apropos 54f297904e0c: Temporarily comment out CC Mode from tests which are incompatible with it. Date: Sun, 20 Jan 2019 21:18:35 +0000 Message-ID: <87ef979ges.fsf@gmail.com> References: <20190117164350.GA18314@ACM> <20190118175437.GA4095@ACM> <20190118225303.GB4095@ACM> <87fttppc7o.fsf@gmail.com> <20190119110729.GA4644@ACM> <875zukpxe2.fsf@gmail.com> NNTP-Posting-Host: ciao.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ciao.gmane.org 1548019165 58940 195.159.176.228 (20 Jan 2019 21:19:25 GMT) X-Complaints-To: usenet@ciao.gmane.org NNTP-Posting-Date: Sun, 20 Jan 2019 21:19:25 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: acm@muc.de, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 20 22:19:22 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1glKUz-000FEl-1B for ged-emacs-devel@m.gmane.org; Sun, 20 Jan 2019 22:19:21 +0100 Original-Received: from localhost ([127.0.0.1]:44428 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glKV8-0005G6-50 for ged-emacs-devel@m.gmane.org; Sun, 20 Jan 2019 16:19:30 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44674) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glKUR-0005DT-EU for emacs-devel@gnu.org; Sun, 20 Jan 2019 16:18:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1glKUM-0004Fe-SJ for emacs-devel@gnu.org; Sun, 20 Jan 2019 16:18:47 -0500 Original-Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:53619) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1glKUK-0004Ej-WD; Sun, 20 Jan 2019 16:18:41 -0500 Original-Received: by mail-wm1-x330.google.com with SMTP id d15so9013648wmb.3; Sun, 20 Jan 2019 13:18:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=aOAem8E6CRe+7X030HEIl+rGREcBZbZj5LVR8y2asTk=; b=eWT3wm7AbAMRcP7tA+83EEmJ5wLINJAAP309BZlJE3uYFgwIXU3AnuBJodVMxGP8r5 fSuDJ834hY/1EK6FQ91Qbpv10lMxlvtLRIKAfXBLIf4eZG7PTmzVzAfDK/8k605iaw/j xPs+1TVhbBc5MK8auD/Bs6rtd6jHyEWDiCpJDACZfM9LFJcwhJOWI2VyrWwaXTqJLk7j QPAD6jBXruMvlnsbF4svqrQhD/bPQa8FIwXOmefSSdvSezkPNC21/ynr7hk7QHk0d69z UYkaN4i+0uql8iNolI9T5JSdpyakFCs+BHPleAz765bql6yieqO67uLUOek6UfOEixSx VUsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=aOAem8E6CRe+7X030HEIl+rGREcBZbZj5LVR8y2asTk=; b=NhEDO+bYl/PizRf9aEuDHFi8y50uHxtrxsmFsQILUriQW4IPClBN0aq0UBMLf6lpdM fvbTVhx40GeY6OX1vPsk8rSerJZ07R/+oEBjUSbskRuMpUZQTP6WLI7hYS/kxCOfLFXS 4czA004veroRy3NVLdC8dz/5UyexYTfDuawoVqBH22d2Nk4sATIeV7AyZUPXjnx6HNYv 2KcSGWLISYmzOSufxtIQxDiyTe3QFE19pD6XvYJma+peQI8Zvf7xrXhIm1xJ6oPUsxRn 1sv2GHkdLbLntWDU86JNfgUnbqYaR2WjKAfBvB4QvVyULt6ftgEyetM+uz3oCebT8yLs V/hA== X-Gm-Message-State: AJcUukdAMmRuhFXwkZX7ySywad6L4LtYk9d+wcMZmpY7y7QRf1TDRGb+ UVV4DkwEcf9QaTbx3hb1PycUiDYU X-Google-Smtp-Source: ALg8bN4zk6dhL5mHhU27zmLwyuelEzoE56o+/pV+yXoHpN4Y2nFOLxjbTKU9IhrHZ9NZdHjgTGHQOg== X-Received: by 2002:a1c:1b4f:: with SMTP id b76mr22707357wmb.147.1548019118537; Sun, 20 Jan 2019 13:18:38 -0800 (PST) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id p12sm50831393wmi.5.2019.01.20.13.18.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 20 Jan 2019 13:18:37 -0800 (PST) In-Reply-To: (Richard Stallman's message of "Sun, 20 Jan 2019 14:05:52 -0500") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::330 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:232556 Archived-At: Richard Stallman writes: > When you state disagreement with someone, please don't use a harsh > tone. We are all working together here. So let's be kind to each > other. Hello Richard, Richard, I fully understand that. But I must remind you, at this point, that it was Alan who used the words "stupid", "histrionic", "in denial", "silly" and "low quality" to characterize my position. Earlier I myself used the term "atrocity" to characterize his, but I later abandoned this language, because these are not objective ways to characterize someone's viewpoint. I will of course accept that insults aren't the only way to be harsh, so I must now proceed to explain why I behaved so. Alan repeatedly misstates a "fact" without providing evidence. This is very exasperating. Because saying that itself requires justification, I must present my it as abbreviated as I can: Alan says that the Emacs minor modes 'electric-pair-mode' (hereafter abbreviated e-p-m) and 'electric-layout-mode' (abbrev. e-l-m) are incompatible with cc-mode. This is strictly true _now_, at the current state of the Emacs source tree, but it was _not_ so before Alan's change 223e7b8787 of pushed in 2019-01-15. In fact, I presented a short section of code (which I should like to improve and install in the future), which demonstrates this. But Alan refuses to acknowledge it. (a variation on this snippet is still installed in the Emacs source tree under test/lisp/electric-tests.el but it is not activated to the user, while an updated version of the snippet I sent to Alan is attached after my signature). I encouraged Alan to roll back the code to before his change and try that very simple piece of code. With it, he could either directly point to a misbehaviour I'm not aware of, thereby partly justfying his claim. In that purely hypothetical case I could either fix the misbehaviour or accept that there is indeed a fundamental incompatibility and give up. But Alan consistently refuses to do, leaving me with no evidence of his claim. Instead, Alan points to bug#33794. In that bug, a user states the following: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D33794#1 > When using cc-mode, turning on electric-pair-mode causes the > auto-newline minor mode to stop inserting newlines where expected. > [...] She mentions a true, never disputed, incompatibility in the combination 'cc-mode', 'e-p-m', and 'auto-newline' (the latter also known as 'c-auto-newline'), which is notably not the same combination as cc-mode, e-p-m, and e-l-m. If you read through that bug, you will read efforts from my part to encourage the user to try e-l-m *instead* of 'c-auto-newline', paired with efforts to improve 'e-l-m' so that the user's wishes can be fulfilled. Those efforts are reviewed by Stefan Monnier, installes in Emacs' e-l-m (not touching any of cc-mode) and after some confusion those efforts succeed and the user eventually understands she has an alternative in the combination cc-mode, e-p-m and e-l-m: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D33794#83 Beatrix>> Things such as c-toggle-auto-newline, for example, almost seem = in this >> case that they might be better delegated to electric-layout-mode, >> with cc-mode specifying different electric-layout constraints for >> its different formatting styles. It seems this is close to what >> Jo=C3=A3o was suggesting? >=20 JT> Yes, that is precisely what I am suggesting. I am happy that this JT> point made it across. At this point, the incompatibility between the original combination cc-mode, e-p-m, and auto-newline remained, and Alan decided, quite legitimately, to address it: there is no reason why the original bug reported shouldn't be fixed. However, he chose a way of doing so that denies the alternative I had provided earlier (additionally, it opened many other new bugs in simpler usage combinations that he is only now addressing). At first, I thought it was an oversight. After complaining of the new bugs, I suggested further alternatives so that *both* combinations can be available to the user. I presented actual, very simple, working code that does this. Code that would even very slightly reduce the line-of-count count in C++ mode. But Alan rejects this: he wants the keep the current status quo that his combination works but the alternative I presented earlier user doesn't, effectively shutting the user out of using 'electric-layout-mode' in CC-mode, something he deems "silly". There are, of course, technical ways around this blockade, but they are, at the moment, too technical for users to try. More importantly, they didn't need to exist at all if Alan just didn't needlessly block e-l-m. I would like to think that you, Richard, of all people, are sensitive to one of the issues here, which is about shutting out users out of software. Perhaps you have learned in your life to argue this less harshly, and more effectively, than I did. Best, Jo=C3=A3o (setq electric-layout-rules '(electric-layout-for-c-style-du-jour)) (defun electric-layout-brace-for-c-style-du-jour (inserted) (when (and (derived-mode-p 'c-mode 'c++-mode) (memq inserted '(?{ ?}))) (save-excursion ;; seem to need this extra call before the one we're interested in (backward-char) (c-point-syntax) (forward-char) (backward-char) (c-brace-newlines (c-point-syntax))))) (electric-pair-mode 1) (electric-layout-mode 1)