From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#36474: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode Date: Tue, 2 Jul 2019 16:04:10 +0000 Message-ID: <20190702160410.GB30597@ACM> References: <20190702131632.GA30597@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="55842"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: 36474@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 Tue Jul 02 19:15:52 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hiMNh-000EKY-Ty for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Jul 2019 19:15:50 +0200 Original-Received: from localhost ([::1]:55506 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiMNb-0006Ac-VS for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Jul 2019 13:15:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44422) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiLHH-00034M-4y for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 12:05:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hiLHD-0000p9-P0 for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 12:05:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38916) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hiLHC-0000nf-0u for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 12:05:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hiLHB-0002o6-Ow for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 12:05:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Jul 2019 16:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36474 X-GNU-PR-Package: emacs Original-Received: via spool by 36474-submit@debbugs.gnu.org id=B36474.156208346010738 (code B ref 36474); Tue, 02 Jul 2019 16:05:01 +0000 Original-Received: (at 36474) by debbugs.gnu.org; 2 Jul 2019 16:04:20 +0000 Original-Received: from localhost ([127.0.0.1]:47737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiLGV-0002n8-FV for submit@debbugs.gnu.org; Tue, 02 Jul 2019 12:04:19 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:26103 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hiLGS-0002mw-MY for 36474@debbugs.gnu.org; Tue, 02 Jul 2019 12:04:17 -0400 Original-Received: (qmail 40183 invoked by uid 3782); 2 Jul 2019 16:04:11 -0000 Original-Received: from acm.muc.de (p4FE15D94.dip0.t-ipconnect.de [79.225.93.148]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 02 Jul 2019 18:04:10 +0200 Original-Received: (qmail 21033 invoked by uid 1000); 2 Jul 2019 16:04:10 -0000 Content-Disposition: inline In-Reply-To: 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: 209.51.188.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:161965 Archived-At: On Tue, Jul 02, 2019 at 15:13:35 +0100, Joćo Tįvora wrote: > > Hello Joćo and Emacs. > Hello Alan and Emacs, > On Tue, Jul 2, 2019 at 2:16 PM Alan Mackenzie wrote: > > This is a follow up bug to bug #36423: 27.0.50; electric-pair-mode not > > working properly depending of file content. > [did you mean to copy bug-gnu-emacs@gnu.org, or emacs-devel@gnu.org? > I'm assuming the latter and correcting] No, it's a bug, therefore I submitted a bug report. > > Start the Emacs master (up to date state as of 2019-07-02T14:30 +0000) > > with emacs -Q, put the following in a C++ Mode buffer and enable > > electric-pair-mode: > > "foo\n > > . Type a " at the end of foo. electric-pair-mode wrongly inserts two > > "s. > > Diagnosis: electric-pair--unbalanced-strings-p works after the (single) > > newly typed " has been stripped from the buffer. It attempts to > > determine whether there are any open strings after the point of > > insertion. It does this by using parse-partial-sexp, and checks (nth 3 > > ) as evidence of an open string. > I'm afraid this is a (another?) direct consequence of the NL-terminated > strings feature that you introduced more than one year ago. If you > remember, this had various consequences vis-a-vis balancing, > broke a test (one that I disabled in the expectation that a fix would be > made available, which I don't think happened). Here are some points of > that thread: > https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00551.html > https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00580.html > I think I made my views clear back then: NL-terminated strings are a > misfeature. The only argument _for) them, that they mimic what some > compilers do, is very weak because (1) the code is invalid in both > situations (not in any way "slightly less" invalid in any of them) and > (2) compilers don't edit code and so have different requirements. > The arguments _against_ NL-terminated strings is that they (1) break > longstanding features such as sexp-based navigation (e.g. `up-list` > and friends) for modes such say, `js-mode` and (2) break features > that expect this to work, most notably electric-pair-mode. This isn't true. If those other feature no longer work with an up to date Emacs, they should be fixed. The fontification that CC Mode does is natural and helpful, and users haven't complained about it (except when there've been bugs). There have certainly been no complaints about using font-lock-warning-face for the invalid string delimiters, and font-lock-string-face for valid ones. > Moving forward: > 1. We can consider that electric-pair-mode is doing the right thing. > Indeed if NL is indeed terminating a string, then quote balance has been > maintained after the double quote insertion, i.e. it has not worsened. > That is the general contract of `electric-pair-preserve-balance`. There is a bug: on typing a " to close a string, two "s are inserted into the buffer, the second one being invalid. This make absolutely no sense from a user point of view. > 2.The NL-terminated string feature is removed (or, if you prefer, is > made disableable). This would restore the behaviour that most users > would expect coming over, from say python-mode or js-mode. Perhaps > it can already be disabled with a couple of lines of emacs-lisp tweaking > the syntax-table. The invalid string feature is here to stay. It is a positive user feature. CC Mode has often been a pioneer in inventing Emacs features, and this is just such a feature. > 3. Someone comes up with a suitable indirection that doesn't involve > hardcoding `cc-mode` in elec-pair.el. That indirection would > presumably do what you want for modes `cc-mode` derived > from cc-mode. There is already a great deal of such indirection in electric-pair-mode. (Look for "(funcall electric-pair-....)" in elec-pair.el.) Maybe there is enough there already to accomodate CC Mode, maybe an extra function variable would need introducing. For this, I think we would both rather that you amend elec-pair.el rather than me. > 4. Someone reinvents electric-pair-mode in cc-model.el. > Let's not do this. No, let's not do that! :-) > I prefer 2. That isn't an option. Unless you can come up with another workable strategy that achieves the same effect. > Thanks, > Joćo > > This does not work in CC Mode, since although there is an open string > > marker (with a string fence syntax-table property on it) this is > > "closed" (from parse-partial-sexp's point of view) by the string fence > > property on the newline at the end of the line. > > electric-pair--unbalanced-strings-p thus returns the wrong result. > > A more suitable algorithm might look something like this: check whether > > the newly inserted " has a string fence syntax-table text property. > > (Its insertion will have already triggered the before- and > > after-change-functions which set this property.) If so, there is an > > open string. Of course, this only applies to CC Mode modes. > -- > Joćo Tįvora -- Alan Mackenzie (Nuremberg, Germany).