From unknown Sat Jun 14 03:57:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36474: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Jul 2019 13:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 36474 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: joaotavora@gmail.com, 36474@debbugs.gnu.org X-Debbugs-Original-To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.156207340818492 (code B ref -1); Tue, 02 Jul 2019 13:17:01 +0000 Received: (at submit) by debbugs.gnu.org; 2 Jul 2019 13:16:48 +0000 Received: from localhost ([127.0.0.1]:46657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiIeN-0004oB-H0 for submit@debbugs.gnu.org; Tue, 02 Jul 2019 09:16:48 -0400 Received: from lists.gnu.org ([209.51.188.17]:52331) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiIeL-0004o3-42 for submit@debbugs.gnu.org; Tue, 02 Jul 2019 09:16:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58156) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiIeJ-0005To-Tq for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 09:16:45 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hiIeI-00054T-Ut for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 09:16:43 -0400 Received: from colin.muc.de ([193.149.48.1]:64382 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hiIeH-00050A-9C for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 09:16:42 -0400 Received: (qmail 38769 invoked by uid 3782); 2 Jul 2019 13:16:33 -0000 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 15:16:32 +0200 Received: (qmail 30708 invoked by uid 1000); 2 Jul 2019 13:16:32 -0000 Date: Tue, 2 Jul 2019 13:16:32 +0000 Message-ID: <20190702131632.GA30597@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie 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-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) Hello Joćo and Emacs. This is a follow up bug to bug #36423: 27.0.50; electric-pair-mode not working properly depending of file content. 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. 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. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sat Jun 14 03:57:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36474: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode 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 X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 36474@debbugs.gnu.org Received: via spool by 36474-submit@debbugs.gnu.org id=B36474.156208346010738 (code B ref 36474); Tue, 02 Jul 2019 16:05:01 +0000 Received: (at 36474) by debbugs.gnu.org; 2 Jul 2019 16:04:20 +0000 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 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 Received: (qmail 40183 invoked by uid 3782); 2 Jul 2019 16:04:11 -0000 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 Received: (qmail 21033 invoked by uid 1000); 2 Jul 2019 16:04:10 -0000 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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). From unknown Sat Jun 14 03:57:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36474: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Jul 2019 17:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36474 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie , emacs-devel , spacibba@aol.com Cc: 36474@debbugs.gnu.org Received: via spool by 36474-submit@debbugs.gnu.org id=B36474.156208817428357 (code B ref 36474); Tue, 02 Jul 2019 17:23:02 +0000 Received: (at 36474) by debbugs.gnu.org; 2 Jul 2019 17:22:54 +0000 Received: from localhost ([127.0.0.1]:47832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiMUY-0007NG-1y for submit@debbugs.gnu.org; Tue, 02 Jul 2019 13:22:54 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:41773) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiMUW-0007Mt-5r for 36474@debbugs.gnu.org; Tue, 02 Jul 2019 13:22:52 -0400 Received: by mail-io1-f66.google.com with SMTP id w25so38807205ioc.8 for <36474@debbugs.gnu.org>; Tue, 02 Jul 2019 10:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z7cOoHww92u9njkDpHG3l7T9Lk/qNhJlq4dwOqVcjG0=; b=lgtqu2l8fZNuJ+JI4l6xTsbJGJ1Als6aymPMssFOslZy4ktWzMKu0TRMKlVOpl6Fjp 1kjUMCZQ5a5rlnHCHl5bOQg4BRCCk1xGDJmntrR0WkKgjIAFCdx/luGKLVuGDknnFiyv 0lRPI2BGqfQPKPjsB9w9YCDDa5FhhU6/zolRH6YQm8wJ9AoqQS6btdzFRaqUPjqidj+E g7NIVanfNaJwyupOcjxHxKvhfCrkzGMERSmlhAURVlg70t13GsvPQ466sehXZAcdcZdo xCLNZmaKWZFB3u3J82RYamtkAYhoM44KY08+9cLaa40owJLwgUzl/7clbPhtTG4lyK9J Q+bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z7cOoHww92u9njkDpHG3l7T9Lk/qNhJlq4dwOqVcjG0=; b=KjeR/6/aqtnmNdBrqvDGUM5x57En4xh7M3/QLEcEdRctSQmuCtGtuIynVqOGfEX8Qy uZrYbiB1kpgr2jHu/xGtxMfM/+pQeNbBEC+4IlpL3xOGQ6Txaz8AX/pzxyIahRQQ/dmo SP++Mzc2YkV+kpQ+MtBfhro8wHfqdLI3BD9gO0wTNE2SQ26GSzKm5PwCv9hKubmoJRaF pt6i57t/lsP8OIoUUj9Zbpfv1IavvkRe0ZOAyhNUa4bWSUSqgvuZZM/6uXVCGsrt8X18 rdVU73MxD6VnPZ1RPlR8nPXmxPLcPxI/+JwrifuFu2tZTCgt0aB77JSpbh05q8LUnATA l65Q== X-Gm-Message-State: APjAAAWFqJ78XF8MKU/N7wE8/WRHii08WWtUjm2/Jhq28NoEfEol8RYA gAjTzysRNjXBFAbXto+q4etRYgbnNeC/gXsSWbI= X-Google-Smtp-Source: APXvYqyGosR5Jp9PPSHM9qVzkskkz3XedneQG8KkRiJLFO2evMKZvPsRdCKvrgPmxc248MbFw9MMV8oIFSdA5gka5GM= X-Received: by 2002:a6b:b257:: with SMTP id b84mr36105180iof.137.1562088166389; Tue, 02 Jul 2019 10:22:46 -0700 (PDT) MIME-Version: 1.0 References: <20190702131632.GA30597@ACM> <20190702160410.GB30597@ACM> In-Reply-To: <20190702160410.GB30597@ACM> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Tue, 2 Jul 2019 18:22:34 +0100 Message-ID: Content-Type: multipart/alternative; boundary="00000000000043fc2d058cb5fe11" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000043fc2d058cb5fe11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 2, 2019 at 5:04 PM Alan Mackenzie wrote: > > [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. You should use the X-Debbugs-CC feature then (and why not continue in the existing bug 36423?) Anyway, I insist this matter be brought to emacs-devel because it's a followup to a discussion that started there but never reached a suitable conclusion. For that reason, and because I provide a workaround for the bug at the end of this message, I'm cross-posting this one mail to both the bug list and emacs-devel. > > 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. What "isn't true"? Have those features broken or not? They worked before the fe06f643b commit and don't work after the commit. It sounds quite unrefutable to me. > If those other feature no longer work with an up to > date Emacs, they should be fixed. I've stated this repeatedly in the life of this discussion: it's not just about electric-pair-mode. If you try to M-x up-list from a multi-line string in emacs 26.1 it works just as well in js-mode and c++-mode. In emacs master it does not in c++-mode. Same with forward-sexp on the starting delimiter, etc. > The fontification that CC Mode does is natural and helpful, and users > haven't complained about it (except when there've been bugs). Yes, users haven't complained except when users have complained. > 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. That's because providing this annotation is perfectly fine. The problem is providing it _at the expense of other features_. And _that's_ what they've complained about: an average user has no obvious way of telling that the particular implementation of the red annotation thingy is guilty of breaking his C-M-u or his electric-pair-mode. He/she might even judge the latter more vital than said red thingy , an annotation which he/she will get by other means if using very popular packages such as flycheck, or flymake, or eglot, or lsp-mode, etc. These normally call the compiler directly on the source code and highlight those and many other errors. On the other hand, if what you want is the red annotation, are you absolutely sure there isn't a better way to get it? And if you are, are you also absolutely sure you need to put it in the code and and not provide an easy way to turn it off? > For this, I think we would both rather that you amend elec-pair.el rather > than me. I'll be "mulling this over". There are potentially many other points of breakage that would need such an indirection, and doing that to serve just a particular cc-mode quirk doesn't sound priority to me. In the meantime, let others chime in. Also, in the meantime, for a user that is bothered by this bug, I'd recomend to put something like this in his/her .emacs file: (defun c-unescaped-nls-in-string-p (&optional quote-pos) t) I had something more elaborate in my setup but just this seems to fix it in my testing. There is a also a very promising variable, c-multiline-string-start-char, that I think would be a good candidate for customizing this, but I haven't messed with it enough. Just setting it from .emacs doesn't do the trick. Perhaps in a mode hook? -- Jo=C3=A3o T=C3=A1vora --00000000000043fc2d058cb5fe11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Jul 2, 2019 at 5:04 PM Alan Mackenzie <acm@muc.de> wrote:
> > [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, there= fore I submitted a bug report.

You shou= ld use the X-Debbugs-CC feature then (and why not continue
i= n the existing bug 36423?)

Anyway, I insist t= his matter be brought to emacs-devel because it's a
foll= owup to a discussion that started there but never reached a
= suitable conclusion. For that reason, and because I provide a=C2=A0
workaround for the bug=C2=A0 at the end of=C2=A0 this message, I= 9;m cross-posting
this one mail to both the bug list and ema= cs-devel.

> > The arguments _against_ = NL-terminated strings is that they (1) break
> > longstanding feat= ures such as sexp-based navigation (e.g. `up-list`
> > and friends= ) for modes such say, `js-mode` and (2) break features
> > that ex= pect this to work, most notably electric-pair-mode.
>
> Th= is isn't true.=C2=A0

What "isn't= true"? Have those features broken or not? They worked
befor= e the fe06f643b commit and don't work after the commit. It
sounds quite unrefutable to me.

= > If those other feature no longer work with an up to
> dat= e Emacs, they should be fixed.

I've stated thi= s repeatedly in the life of this discussion: it's not just about
<= div>electric-pair-mode. If you try to M-x up-list from a multi-line string = in
emacs 26.1 it works just as well in js-mode and c++-mode.= =C2=A0 In emacs
master it does not in c++-mode. Same with fo= rward-sexp on the starting
delimiter, etc.

> The fontification that CC Mode does is natural and helpful, and use= rs
> haven't complained about it (except when there've b= een bugs).=C2=A0

Yes, users haven't compl= ained except when users have complained.

> There have
> certainly been no complaints about using font-l= ock-warning-face for the
> invalid string delimiters, and font-l= ock-string-face for valid ones.

That's because= providing this annotation is perfectly fine.=C2=A0 The problem
i= s providing it _at the expense of other features_. And _that's_ what
they've complained about: an average user has no obvious w= ay of
telling that the particular implementation of the red = annotation thingy
is guilty of breaking his C-M-u or his ele= ctric-pair-mode.

He/she might even judge the l= atter more vital than said red thingy
, an annotation wh= ich he/she will get by other means if using
very popular pac= kages such as flycheck, or flymake, or eglot, or
lsp-mode, e= tc. These normally call the compiler directly on the
source = code and highlight those and many other errors.

On the other hand, if what you want is the red annotation, are you
absolutely sure there isn't a better way to get it? And if you= are,
are you also absolutely sure you need to put it in the= code and
and not provide an easy way to turn it off?

> For this, I think we would both rather that you amend ele= c-pair.el rather
> than me.

I'll be= "mulling this over". There are potentially many other points of =
breakage that would need such an indirection, and doing that= to serve
just a particular cc-mode quirk doesn't sound = priority to me.

In the meantime, let others chime = in.

Also, in the meantime, for a user that is both= ered by this bug,
I'd recomend to put something like thi= s in his/her .emacs file:

=C2=A0 (defun c-unescape= d-nls-in-string-p (&optional quote-pos) t)

I h= ad something more elaborate in my setup but just this
seems t= o fix it in my testing.

There is a also a very= promising variable, c-multiline-string-start-char,
that I think = would be a good candidate for customizing this, but I
haven&= #39;t messed with it enough. Just setting it from .emacs doesn't
<= div>do the trick. Perhaps in a mode hook?

--
Jo=C3=A3o T=C3=A1vora
--00000000000043fc2d058cb5fe11-- From unknown Sat Jun 14 03:57:49 2025 X-Loop: help-debbugs@gnu.org Subject: bug#36474: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Jul 2019 18:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36474 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: spacibba@aol.com, 36474@debbugs.gnu.org, emacs-devel Received: via spool by 36474-submit@debbugs.gnu.org id=B36474.15620921023231 (code B ref 36474); Tue, 02 Jul 2019 18:29:01 +0000 Received: (at 36474) by debbugs.gnu.org; 2 Jul 2019 18:28:22 +0000 Received: from localhost ([127.0.0.1]:47922 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiNVs-0000q1-0D for submit@debbugs.gnu.org; Tue, 02 Jul 2019 14:28:20 -0400 Received: from colin.muc.de ([193.149.48.1]:52775 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hiNVq-0000pr-1G for 36474@debbugs.gnu.org; Tue, 02 Jul 2019 14:28:18 -0400 Received: (qmail 66150 invoked by uid 3782); 2 Jul 2019 18:28:11 -0000 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 20:28:11 +0200 Received: (qmail 21605 invoked by uid 1000); 2 Jul 2019 18:28:11 -0000 Date: Tue, 2 Jul 2019 18:28:11 +0000 Message-ID: <20190702182811.GC30597@ACM> References: <20190702131632.GA30597@ACM> <20190702160410.GB30597@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Joćo. On Tue, Jul 02, 2019 at 18:22:34 +0100, Joćo Tįvora wrote: > On Tue, Jul 2, 2019 at 5:04 PM Alan Mackenzie wrote: > > > [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. > You should use the X-Debbugs-CC feature then (and why not continue > in the existing bug 36423?) I didn't know about the former, and as for the bug, it is a different bug with differenct causes from #36423. > Anyway, I insist this matter be brought to emacs-devel because it's a > followup to a discussion that started there but never reached a > suitable conclusion. For that reason, and because I provide a > workaround for the bug at the end of this message, I'm cross-posting > this one mail to both the bug list and emacs-devel. > > > 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. > What "isn't true"? Have those features broken or not? They may well be broken. CC Mode hasn't broken them. They made invalid assumptions, which turned out to be unjustified. > They worked before the fe06f643b commit and don't work after the > commit. It sounds quite unrefutable to me. I don't know what you're talking about. > > If those other feature no longer work with an up to date Emacs, they > > should be fixed. > I've stated this repeatedly in the life of this discussion: it's not > just about electric-pair-mode. If you try to M-x up-list from a > multi-line string in emacs 26.1 it works just as well in js-mode and > c++-mode. In emacs master it does not in c++-mode. Same with > forward-sexp on the starting delimiter, etc. I've just tried these in a multiline string in C++ Mode. Both up-list and forward-sexp work just fine. I don't know what you're doing. > > The fontification that CC Mode does is natural and helpful, and users > > haven't complained about it (except when there've been bugs). > Yes, users haven't complained except when users have complained. > > 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. > That's because providing this annotation is perfectly fine. The problem > is providing it _at the expense of other features_. If other features are broken (and your list of other broken features, so far, is empty), they should be fixed. > And _that's_ what they've complained about: an average user has no > obvious way of telling that the particular implementation of the red > annotation thingy is guilty of breaking his C-M-u or his > electric-pair-mode. That's groundless disparagement. C-M-u works, and electric-pair-mode is broken because it's broken. In one place it's using scan-sexps to move forward over whitespace, totally oblivious to the possibility of syntax-table text properties (which have been in use since Emacs-21). That's broken code. > He/she might even judge the latter more vital than said red thingy > , an annotation which he/she will get by other means if using > very popular packages such as flycheck, or flymake, or eglot, or > lsp-mode, etc. These normally call the compiler directly on the > source code and highlight those and many other errors. Irrelevant. > On the other hand, if what you want is the red annotation, are you > absolutely sure there isn't a better way to get it? No, I'm not. That's why I invited you to come up with a better way, if you can. > And if you are, are you also absolutely sure you need to put it in the > code and and not provide an easy way to turn it off? It's a core feature of the mode, not an option. > > For this, I think we would both rather that you amend elec-pair.el rather > > than me. > I'll be "mulling this over". There are potentially many other points > of breakage "Potentially" many? So far, there is precisely one, in electric-pair--unbalanced-strings-p. I thought I was doing you a favour by diagnosing the trouble. If I'd known I'd get the reaction from you I've just got, I wouldn't have bothered. > that would need such an indirection, and doing that to serve just a > particular cc-mode quirk doesn't sound priority to me. No, you'd be cleaning up your code, to conform with the reality that in 2019 major modes use syntax-table text properties. Features from CC Mode have a habit of migrating to the Emacs core. > In the meantime, let others chime in. > Also, in the meantime, for a user that is bothered by this bug, > I'd recomend to put something like this in his/her .emacs file: > (defun c-unescaped-nls-in-string-p (&optional quote-pos) t) It's free software, but that's a stupid thing to do. > I had something more elaborate in my setup but just this > seems to fix it in my testing. > There is a also a very promising variable, c-multiline-string-start-char, > that I think would be a good candidate for customizing this, .... It is not a customisation variable. It is a language definition variable. > .... but I haven't messed with it enough. Just setting it from .emacs > doesn't do the trick. Perhaps in a mode hook? Or, alternatively, actually fix the problems which have been festering for years or decades, and are just now revealing themselves. Thus far, there's exactly one such problem in electric-pair--unbalanced-strings-p. > -- > Joćo Tįvora -- Alan Mackenzie (Nuremberg, Germany). From unknown Sat Jun 14 03:57:49 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Alan Mackenzie Subject: bug#36474: closed (Re: bug#36474: Acknowledgement (Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode)) Message-ID: References: <20190708093627.GB4529@ACM> <20190702131632.GA30597@ACM> X-Gnu-PR-Message: they-closed 36474 X-Gnu-PR-Package: emacs Reply-To: 36474@debbugs.gnu.org Date: Mon, 08 Jul 2019 09:37:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1562578622-16267-1" This is a multi-part message in MIME format... ------------=_1562578622-16267-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #36474: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC = Mode which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 36474@debbugs.gnu.org. --=20 36474: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D36474 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1562578622-16267-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 36474-done) by debbugs.gnu.org; 8 Jul 2019 09:36:38 +0000 Received: from localhost ([127.0.0.1]:57743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hkQ4c-0004Do-64 for submit@debbugs.gnu.org; Mon, 08 Jul 2019 05:36:38 -0400 Received: from colin.muc.de ([193.149.48.1]:27051 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hkQ4Z-0004Dd-Lc for 36474-done@debbugs.gnu.org; Mon, 08 Jul 2019 05:36:36 -0400 Received: (qmail 20992 invoked by uid 3782); 8 Jul 2019 09:36:28 -0000 Received: from acm.muc.de (p4FE15FEC.dip0.t-ipconnect.de [79.225.95.236]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 08 Jul 2019 11:36:27 +0200 Received: (qmail 25258 invoked by uid 1000); 8 Jul 2019 09:36:27 -0000 Date: Mon, 8 Jul 2019 09:36:27 +0000 To: 36474-done@debbugs.gnu.org Subject: Re: bug#36474: Acknowledgement (Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode) Message-ID: <20190708093627.GB4529@ACM> References: <20190702131632.GA30597@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36474-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) The bug has been fixed in CC Mode. On Tue, Jul 02, 2019 at 13:17:01 +0000, GNU bug Tracking System wrote: > Thank you for filing a new bug report with debbugs.gnu.org. > This is an automatically generated reply to let you know your message > has been received. > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > Your message has been sent to the package maintainer(s): > bug-gnu-emacs@gnu.org > If you wish to submit further information on this problem, please > send it to 36474@debbugs.gnu.org. > Please do not send mail to help-debbugs@gnu.org unless you wish > to report a problem with the Bug-tracking system. > -- > 36474: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36474 > GNU Bug Tracking System > Contact help-debbugs@gnu.org with problems -- Alan Mackenzie (Nuremberg, Germany). ------------=_1562578622-16267-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 2 Jul 2019 13:16:48 +0000 Received: from localhost ([127.0.0.1]:46657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiIeN-0004oB-H0 for submit@debbugs.gnu.org; Tue, 02 Jul 2019 09:16:48 -0400 Received: from lists.gnu.org ([209.51.188.17]:52331) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiIeL-0004o3-42 for submit@debbugs.gnu.org; Tue, 02 Jul 2019 09:16:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58156) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiIeJ-0005To-Tq for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 09:16:45 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hiIeI-00054T-Ut for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 09:16:43 -0400 Received: from colin.muc.de ([193.149.48.1]:64382 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hiIeH-00050A-9C for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 09:16:42 -0400 Received: (qmail 38769 invoked by uid 3782); 2 Jul 2019 13:16:33 -0000 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 15:16:32 +0200 Received: (qmail 30708 invoked by uid 1000); 2 Jul 2019 13:16:32 -0000 Date: Tue, 2 Jul 2019 13:16:32 +0000 To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= , bug-gnu-emacs@gnu.org Subject: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode Message-ID: <20190702131632.GA30597@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie 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-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) Hello Joćo and Emacs. This is a follow up bug to bug #36423: 27.0.50; electric-pair-mode not working properly depending of file content. 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. 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. -- Alan Mackenzie (Nuremberg, Germany). ------------=_1562578622-16267-1--