From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Apropos 54f297904e0c: Temporarily comment out CC Mode from tests which are incompatible with it. Date: Fri, 18 Jan 2019 22:53:03 +0000 Message-ID: <20190118225303.GB4095@ACM> References: <20190117164350.GA18314@ACM> <20190118175437.GA4095@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1547852589 2512 195.159.176.226 (18 Jan 2019 23:03:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 18 Jan 2019 23:03:09 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 19 00:03:05 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkdAH-0000Xl-23 for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 00:03:05 +0100 Original-Received: from localhost ([127.0.0.1]:48653 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkdCN-0008Fr-TE for ged-emacs-devel@m.gmane.org; Fri, 18 Jan 2019 18:05:15 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkdBt-0007zK-Q6 for emacs-devel@gnu.org; Fri, 18 Jan 2019 18:04:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gkdBr-00081F-TU for emacs-devel@gnu.org; Fri, 18 Jan 2019 18:04:45 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:32919 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gkdBr-0007cm-H3 for emacs-devel@gnu.org; Fri, 18 Jan 2019 18:04:43 -0500 Original-Received: (qmail 92613 invoked by uid 3782); 18 Jan 2019 23:04:16 -0000 Original-Received: from acm.muc.de (p4FE15D9A.dip0.t-ipconnect.de [79.225.93.154]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 19 Jan 2019 00:04:14 +0100 Original-Received: (qmail 29356 invoked by uid 1000); 18 Jan 2019 22:53:03 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:232465 Archived-At: Hello, Joćo. I'm answering you with a top post (with no bottom) because our exchange has become so voluminous. Firstly I insist that you respect my maintainership of CC Mode; that I understand it better than you, I know its history, its tradeoffs, its problems. And that things like your patch of yesterday, which was grossly disrespectful, will not be repeated. In my turn, I will not mess with the electric-... functions. If you prefer, I will also not mess with electric-tests.el. I did not realise you felt proprietorial over it. And I request you to tone down your aggressiveness. The aggressiveness is entirely on the side of electric-.... I merely want CC Mode to continue working as it has done for several decades. You are continually attacking it. CC Mode and I are under constant siege, but just want to be left in peace. Yet I get from you continually "change CC Mode this way, introduce c-self-insert-command, change CC Mode the other way", on and on and on, ceaselessly. All for your convenience. c-electric-brace and friends depend for their proper working on knowing or controlling every character that is inserted into or deleted from the buffer. When random functionality (from the point of view of c-electric-brace) is added to self-insert-command, these functions cannot work. That is why it is essential to bind post-self-insert-hook to nil in c-electric-brace. It is why c-electric-brace is incompatible with the (ab)use of post-self-insert-hook by certain electric-... functions. I insist you respect the need for the correct functioning of c-electric-brace and friends. And that you cease false insinuations such as c-auto-newline being merely a "corner case" - it is an integral part of CC Mode's functionality, and it will remain supported, and it will remain. Beatrix Klebe's bug was about c-auto-newline. It was not about electric-layout-mode. It is now fixed. You want electric-layout etc., to be the same for every major mode? Then please create interfaces to them which are usable by every mode, including CC Mode (see above). I'm not happy with your response to my request for recipes which show how CC Mode supposedly doesn't work with electric-pair-mode. That around 80 tests fail shows nothing - (at least some of) the tests are broken. You suggest that I should put in the hard work of extracting recipes from your tests myself. Sorry, that's a lot of work and I've got other things to do. The successful uses of electric-pair-mode I reported earlier were on the Emacs after my patch but without your patch. As far as I'm concerned, electric-pair-mode works just fine in CC Mode, until I see a coherent recipe that breaks it. Then I will fix it. The false assumption that these tests make is that they can rely on certain settings in post-self-insert-hook. Any major mode is at liberty to bind or set this hook, and as pointed out above, CC Mode _must_ bind this to nil in c-electric-brace, etc.. Would you please amend these tests to take this into account. And I ask you, have you tried using c-auto-newline? It is easy to set up (a single line in your c-mode-common-hook, or interactively C-c C-a). The CC Mode style system takes care of the rest of the setup most of the time. If not, why not? I do not attack electric-layout-mode. I merely note that it would be less good (if it could work) than CC Mode's own features in the context of CC Mode. For example, c-auto-newline handles different braces differently, depending on their syntactic context. electric-layout-mode does not. electric-layout-mode is not needed in CC Mode. You say that things you've had working since Emacs 24.4 are now not working. Do you mean electric-layout-mode? If so, that "working" was an illusion, not reality. I hope I've said enough to explain why that minor mode can't work in CC Mode, and that a better alternative exists. Sometime in the next few days, I'm going to revert your patch to cc-cmds.el. I earnestly request you to modify electric-tests.el to take account of this. -- Alan Mackenzie (Nuremberg, Germany).