From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#33794: 26.1; electric-pair-mode breaks auto-newline minor mode of cc-mode Date: Sat, 22 Dec 2018 10:20:11 +0000 Message-ID: <20181222102011.GA3935@ACM> References: <20181221134829.29135.qmail@mail.muc.de> <20181221201106.GB16032@ACM> <87y38iqti7.fsf@gmail.com> 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 1545474327 25555 195.159.176.226 (22 Dec 2018 10:25:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 22 Dec 2018 10:25:27 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: bea@klebe.blog, Stefan Monnier , 33794@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 22 11:25:23 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gaeTB-0006Ug-7m for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Dec 2018 11:25:21 +0100 Original-Received: from localhost ([::1]:43580 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gaeVH-0003NQ-NE for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Dec 2018 05:27:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gaeUt-0003Ee-6C for bug-gnu-emacs@gnu.org; Sat, 22 Dec 2018 05:27:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gaeUp-0002h4-3s for bug-gnu-emacs@gnu.org; Sat, 22 Dec 2018 05:27:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54925) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gaeUo-0002gC-FC; Sat, 22 Dec 2018 05:27:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gaeUo-0007Ii-BE; Sat, 22 Dec 2018 05:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sat, 22 Dec 2018 10:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33794 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 33794-submit@debbugs.gnu.org id=B33794.154547441628045 (code B ref 33794); Sat, 22 Dec 2018 10:27:02 +0000 Original-Received: (at 33794) by debbugs.gnu.org; 22 Dec 2018 10:26:56 +0000 Original-Received: from localhost ([127.0.0.1]:59182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gaeUi-0007IH-EX for submit@debbugs.gnu.org; Sat, 22 Dec 2018 05:26:56 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:22792 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gaeUg-0007I8-FH for 33794@debbugs.gnu.org; Sat, 22 Dec 2018 05:26:55 -0500 Original-Received: (qmail 93407 invoked by uid 3782); 22 Dec 2018 10:26:53 -0000 Original-Received: from acm.muc.de (p2E5D5238.dip0.t-ipconnect.de [46.93.82.56]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 22 Dec 2018 11:26:51 +0100 Original-Received: (qmail 4323 invoked by uid 1000); 22 Dec 2018 10:20:11 -0000 Content-Disposition: inline In-Reply-To: <87y38iqti7.fsf@gmail.com> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:153727 Archived-At: Hello, Joćo On Sat, Dec 22, 2018 at 00:45:20 +0000, Joćo Tįvora wrote: > Hi Alan, > I will be replying to the two emails you sent me in this single message. > Alan Mackenzie writes: > > No, not at all. CC Mode has been working for several decades, and works > > well. electric-pair-mode is the new kid on the block, just a few years > > old, and was apparently hacked together without regard to some well > > established conventions. It should have provided interfaces to allow > > existing software to connect to it - for example a variable to contain a > > function to insert the electric character, or something like that. > > Maybe. It should have been considered, but apparently wasn't. > First, I think you'll agree that antiquity is a poor measure of the > merits of software. Here we have antiquity, combined with software actually being used combined with a lack of bugs. (I'm talking about CC Mode's auto-newline facility, here). This SW is good. > Here's a characteristic of electric-pair-mode that I think is an > actual merit: it works for every mode in Emacs.. This clearly isn't true at the moment. Have you tested it with, for example, Cperl Mode, or Vera Mode? That characteristic is an aspiration, which is laudable. > Also, I don't know if you understand the history of electric-pair-mode. > It has two generations: One, before 24.4, which I believe Stefan wrote, > where it was a simpler mode to automatically insert parenthesis and > quotes as described in electric-pair-pairs. Then, in 24.4, I borrowed > code from my reasonably popular autopair.el extension and e-p-m became a > mode that automatically infers what characters to pair from the syntax > table of each mode. Furthermore, in the new version, it also makes > educated guesses about when to pair or when not to pair based, again on > the information collected from the buffer and its syntax table by > syntax-ppss. I think that what is missing from this history is the stage where the idea with proposed solution is first discussed on emacs-devel, where conceptual problems can be identified and resolved. As a result, e-p-m is only compatible with some major modes; it is incompatible with those that explicitly call self-insert-function as part of a command bound to a key which is usually self-inserting. There are quite a few such modes. > The use of post-self-insert-hook was a requirement at the time, since > that is how the pre-24.4 electric-pair-mode, electric-indent-mode and > electric-layout-mode already worked. I welcomed this requirement, and > it was what encouraged me to kill autopair.el and migrate to the new > framework, since in autopair.el I had to rebind the parenthesis keys, > which is akward (much like c-electric-brace and c-electric-paren are > akward IMO). This simplified the code tremendously. Have a look at the doc string for self-insert-command, and ask yourself what should happen on this call: (self-insert-command 1 &{) . The answer is, of course, that "{" should be inserted into the buffer. With electric-pair-mode-enabled, what actually happens is that "{}" gets inserted instead. This is broken. I ask you to consider this paragraph very carefully rather than reacting emotionally against it. self-insert-command is broken, and this is the cause of the current bug. What you seem to be suggesting is that rather than fix this breakage, major modes like CC Mode (and there are quite a few) should have to work around it. > So these "well established conventions" are, with all due respect, > nothing more than personal opinions based on a narrow experience with a > subset of modes (maybe "mode" singular), tried and tested as it may be. > If I abandon the post-self-insert-hook convention for e-p-m, I'll > probably be breaking the e-p-m interaction with electric-indent-mode, > electric-layout-mode, etc. If there are existing problems with these > interactions they should be fixed, but I will not fix e-p-m for > interaction a specific part of cc-mode, unless you provide > retro-compatible fix that guarantees existing behaviour outside cc-mode. Again, you're much more familiar with electric-indent-mode, and friends. Do they also break self-insert-command? > I would rather declare e-p-m incompatible with that part of cc-mode and > invest some time in providing alternatives based on > electric-layout-mode, fixing Beatrix's problem by replacing bits of > cc-mode-specific initialization in her init file with bits that works > for all modes, including cc-mode. You're trying to replace core CC Mode functionality. Trying to do that with a few quick hacks can only lead to frustration all round, and to tears. electric-layout-mode is incompatible with CC Mode. This would have come up in the discussion on emacs-devel and a resolution found if that discussion had taken place. Sadly it didn't, hence the incompatibility. The same applies to electric-pair-mode. We're having that discussion now, sort of. In CC Mode (and Cperl Mode, and Vera Mode,....), on insertion of a {, the processing associated with the insertion needs to be allowed to complete before the insertion of the mating }. Above all, self-insert-command needs to behave correctly, according to its documentation. It is surely not beyond us to fix these problems. > Joćo -- Alan Mackenzie (Nuremberg, Germany).