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: CC Mode and electric-pair "problem". Date: Thu, 31 May 2018 17:28:41 +0000 Message-ID: <20180531172841.GB24752@ACM> References: <20180531123747.GA24752@ACM> <87bmcvbygg.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 1527789171 31079 195.159.176.226 (31 May 2018 17:52:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 31 May 2018 17:52:51 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) Cc: Emacs developers , Tino Calancha To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 31 19:52:46 2018 Return-path: Envelope-to: ged-emacs-devel@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 1fORki-0007xa-6p for ged-emacs-devel@m.gmane.org; Thu, 31 May 2018 19:52:44 +0200 Original-Received: from localhost ([::1]:45485 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fORmp-0002dI-4O for ged-emacs-devel@m.gmane.org; Thu, 31 May 2018 13:54:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fORQj-00029B-NM for emacs-devel@gnu.org; Thu, 31 May 2018 13:32:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fORQe-0003mA-PJ for emacs-devel@gnu.org; Thu, 31 May 2018 13:32:05 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:43499 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fORQe-0003k9-DK for emacs-devel@gnu.org; Thu, 31 May 2018 13:32:00 -0400 Original-Received: (qmail 19733 invoked by uid 3782); 31 May 2018 17:31:58 -0000 Original-Received: from acm.muc.de (p5B146B9D.dip0.t-ipconnect.de [91.20.107.157]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 31 May 2018 19:31:57 +0200 Original-Received: (qmail 5276 invoked by uid 1000); 31 May 2018 17:28:41 -0000 Content-Disposition: inline In-Reply-To: <87bmcvbygg.fsf@gmail.com> 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:225865 Archived-At: Hello, Joćo On Thu, May 31, 2018 at 17:07:43 +0100, Joćo Tįvora wrote: > Hi again, Alan > Alan Mackenzie writes: > > " ( > > > > ) " > > > > . With point just after the (, type a ). The expected result is that > > everything up to and including the existing ) gets "chomped", leaving > > the buffer looking like: > > > > " () " > > > > . This no longer happens in C++ mode, and it is not clear that it > > should. In the original buffer, ( and ) are not in the same string, > > since the opening string ends at EOL, there being no backslash to > > continue it. > > > > If there were escaped newlines in the buffer, I don't think the "chomp" > > would work, because elec-pair.el doesn't recognise escaped newlines as > > whitespace. > > > > Comments? > I can reproduce this, even without turning "chomping" on: 26.1 skips to > the closing parens, master doesn't. > But it's tricky. From elec-pair.el's perspective, skipping whitespace > means skipping whitespace characters *and* not crossing string/comment > boundaries. To analyse a test case very similar to yours I wrote a > simple function (attached after my sig) to analyse just 5 characters and > an end-of-file. > ( " \n " ) EOF I think you mean " ( \n ) " EOF. :-) > In Emacs 26.1 I get > ((:character 34 :formatted "\"" :syntax > (7) > :depth 0 :string nil :last-open-parens nil) > (:character 40 :formatted "(" :syntax > (4 . 41) > :depth 0 :string 34 :last-open-parens 1) > (:character 10 :formatted "\n" :syntax > (0) > :depth 0 :string 34 :last-open-parens 1) > (:character 41 :formatted ")" :syntax > (5 . 40) > :depth 0 :string 34 :last-open-parens 1) > (:character 34 :formatted "\"" :syntax > (7) > :depth 0 :string 34 :last-open-parens 1) > (:character nil :formatted "EOF" :syntax nil :depth 0 :string nil > :last-open-parens nil)) > In Emacs master, I get > ((:character 34 :formatted "\"" :syntax > (15) > :depth 0 :string nil :last-open-parens nil) > (:character 40 :formatted "(" :syntax > (4 . 41) > :depth 0 :string t :last-open-parens 1) > (:character 10 :formatted "\n" :syntax > (15) > :depth 0 :string t :last-open-parens 1) > (:character 41 :formatted ")" :syntax > (5 . 40) > :depth 0 :string nil :last-open-parens nil) > (:character 34 :formatted "\"" :syntax > (15) > :depth -1 :string nil :last-open-parens nil) > (:character nil :formatted "EOF" :syntax nil :depth -1 :string t > :last-open-parens 5)) > Note that the newline character changed its syntax from (0), which is > whitespace, to (15) which is generic string. But more importantly, the > closing paren after it no longer declares to be inside a string > according to syntax-ppss. > Is this what you and (the majority of) cc-mode users expect? If it is, > then this test (and probably many other ones) must be changed to reflect > that. Yes. A string in C(++) mode extending over several lines is only valid when the newlines are escaped. The generic string syntax is partly an artifice to get font-lock-warning-face, but is also deliberately intended to cut the opener of the invalid string off from any subsequent double quote. > As a data-point, as an occasional c++- mode user, I'd much rather have > Emacs 26's behaviour. When faced with such admittedly invalid C, I at > most expect M-x compile or Flymake to tell me about it, but would like > Emacs to treat it as whitespace so electric-pair keeps functioning > correctly. That is, I expect Emacs to not choke my editing tools > because I've temporarily produced syntactically incorrect code while > editing, particularly tools designed to correct such situations. OK. I'll need to mull this over. > I've also noted that whitespace-fixing tools aren't tripped by your > change. But that's because they don't care about comment and string > boundaries, although they could/should. This suggests we could make > elec-pair.el also not care about them in c++ mode, but it would only > take us so far, because I fear worse problems would come in more basic > elec-pair.el funtionality. > In general, I think you should review the recent c++-mode changes. To > illustrate, here's a new bug report without any newlines. > 1. emacs-master/src/emacs -Q > 2. M-x erase-buffer RET ! > 3. M-x c++-mode > 4. M-x electric-pair-mode > 5. insert a double quote (this inserts a closer) > 6. insert an opening parens (this inserts a closer) > 7. insert a double quote (this inserts a closer, but...) > ... it additionally popups up an error: > c-append-to-state-cache: Scan error: "Unbalanced parentheses", 5, 1 I don't see this at all. For me, that sequence of actions simply works, without signalling an error. This was on the master branch as I committed my change today. > The last quote becomes red. If I erase the buffer again and do the whole > thing again, no error happens and no red quote, which is what I expect > it to do (and Emacs 26 behaviour). > Actually, electric-pair-mode doesn't even need to be on: > 1. emacs-master/src/emacs -Q > 2. M-x erase-buffer RET ! > 3. M-x c++-mode > 5a. insert a double quote > 5b. insert the closer quote > 5.c go back one char > 6a. insert an opening parens > 6b. insert the closer, go back one char > 7a. insert a double quote > 7b. try to insert the closer quote > You get the same c-append-to-state-cache error I don't see this either. And we both started with -Q, so it's not something in .emacs. Are you sure you've downloaded and build that latest patch of mine? > Joćo [ .... ] -- Alan Mackenzie (Nuremberg, Germany).