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: CC Mode and electric-pair "problem". Date: Thu, 31 May 2018 17:07:43 +0100 Message-ID: <87bmcvbygg.fsf@gmail.com> References: <20180531123747.GA24752@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1527782783 26368 195.159.176.226 (31 May 2018 16:06:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 31 May 2018 16:06:23 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Emacs developers , Tino Calancha To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 31 18:06:18 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 1fOQ5i-0006iG-Di for ged-emacs-devel@m.gmane.org; Thu, 31 May 2018 18:06:18 +0200 Original-Received: from localhost ([::1]:45024 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOQ7p-0005q4-IG for ged-emacs-devel@m.gmane.org; Thu, 31 May 2018 12:08:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOQ7F-0005pn-VN for emacs-devel@gnu.org; Thu, 31 May 2018 12:07:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fOQ7B-0006Ys-Sn for emacs-devel@gnu.org; Thu, 31 May 2018 12:07:53 -0400 Original-Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:55291) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fOQ7B-0006Xk-Hv for emacs-devel@gnu.org; Thu, 31 May 2018 12:07:49 -0400 Original-Received: by mail-wm0-x231.google.com with SMTP id f6-v6so54991028wmc.4 for ; Thu, 31 May 2018 09:07:49 -0700 (PDT) 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=nZd3a+jaaSgDqG6hOwlnPzXxWtVnisJ2dfN/va73Dko=; b=LyY95GGQOFZi3Wyg0AO8pbHeZ+fYzAWSmwVrr6nLA0assJ9RExEWbPGWTIvIn/qBqZ aLjlQGGlNb/jqQJmwN2TpVmVJOpUwD5Z2v82grZcGfJ5/7qKTWUDLkUcQE0uSSfndq0+ hSfEFXvhz2rv0gqAYk25Um+fUmCePLV4ZnznpeGFbgPpKD3BuXtqjxRgHECHoByR1aOZ UbR75R30obRbLCDe7DVXMy2wMvE/SFms8+++WYiJ76zX/AABIas7JRB5fF34gTtqYK3d jJQh/8fRFQe9OgI3J+mIlmPtLLmfMhKJK9cRLTJ3Gf4jpLomt9UmlsrGYiGfFUdLlYhj agog== 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=nZd3a+jaaSgDqG6hOwlnPzXxWtVnisJ2dfN/va73Dko=; b=qmWitvT9Byt4PliSJ7fgp/cajbawaWCyJmy4WGGF6a9EMGvsA1E7fBjqYbIB9J8nq+ H9DpOpppxsklBfby7y0Wd8jD0/RfOQ5l6HoFmeJY1VYBlO+B+dqNnEtv4DmFs0xhRY/j iPQNe2QwTR2ytkjrp3rAULwm4SqKhvaX88y2ExQNWzZiOHJHzrRGtleXna8sdlFxs4iG pI4By9kZZG0Nnrh/Nwl2+Q+FncWX+E9d9cqOQIbUXzvYjnDrsi9EnDdUxmZ/YA5wOQaL f/9IkTnQR/rOiBF/xzDt7qWk9BE9fakS2GLOIkovro7YsvCaH6m2QRmUcIVjUBFdWWVe TscQ== X-Gm-Message-State: ALKqPweppTTO/U3Xdasf0HNoEyV5FbpL7Thv7OMxeVtTUIk0R+DXj5nv c3d4roWYXvVU+P6s4WogAuRXsswU X-Google-Smtp-Source: ADUXVKLvQOymWmwcK4SST9D0NSaKRsVkH2hQonE/+A6U6q0vh0Nd9F+8HtqptcolSXx8EykfFeOD5A== X-Received: by 2002:a1c:7192:: with SMTP id d18-v6mr314660wmi.115.1527782867981; Thu, 31 May 2018 09:07:47 -0700 (PDT) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id s5-v6sm41694125wra.48.2018.05.31.09.07.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 31 May 2018 09:07:47 -0700 (PDT) In-Reply-To: <20180531123747.GA24752@ACM> (Alan Mackenzie's message of "Thu, 31 May 2018 12:37:47 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::231 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:225858 Archived-At: 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 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)) =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 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. 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. 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 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 Jo=C3=A3o (defun joaot/analyse (&optional int) (interactive "p") (cl-loop for p =3D (point-min) then (1+ p) while (<=3D p (point-max)) for (depth _ _ string comment _ _ _ open-parens _) =3D (syntax-p= pss p) for char =3D (char-after p) collect (list :character char :formatted (if char (format "%c" char) "EOF") :syntax (syntax-after p) :depth depth :string string :last-open-parens open-parens) into retval finally (when int (message "%s" (pp-to-string retval))) (cl-return retval)))