From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Fwd: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode Date: Tue, 2 Jul 2019 16:27:06 +0100 Message-ID: References: <20190702131632.GA30597@ACM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000048d9b0058cb4619f" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="19864"; mail-complaints-to="usenet@blaine.gmane.org" To: Alan Mackenzie , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 02 18:03:16 2019 Return-path: Envelope-to: ged-emacs-devel@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 1hiLFT-0004rq-KK for ged-emacs-devel@m.gmane.org; Tue, 02 Jul 2019 18:03:15 +0200 Original-Received: from localhost ([::1]:54774 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiL9Y-0004Ti-Bb for ged-emacs-devel@m.gmane.org; Tue, 02 Jul 2019 11:57:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35308) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiKgp-0002Dy-Eq for emacs-devel@gnu.org; Tue, 02 Jul 2019 11:27:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hiKgm-00069h-4e for emacs-devel@gnu.org; Tue, 02 Jul 2019 11:27:26 -0400 Original-Received: from mail-io1-xd2c.google.com ([2607:f8b0:4864:20::d2c]:37855) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hiKgh-00061a-Fs for emacs-devel@gnu.org; Tue, 02 Jul 2019 11:27:23 -0400 Original-Received: by mail-io1-xd2c.google.com with SMTP id e5so37909467iok.4 for ; Tue, 02 Jul 2019 08:27:18 -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; bh=ETN4Gkou8TH1K9ZG2dFH60Es9xYLi1Iwp0OJqbL2aKw=; b=R9RU1u5oiwweh50VKmAZQyT9AVVGe1TAQPvtQGGxiXftPh8f9bkryVxnfhIHjD0P10 hdBme5hqpKuG0RVPsmk0168T+WO1uVsQBfzAoVFqWWwnt5kqHtr+cZK2cP91YJir6ME8 Moftt+Pq5dtko57spSQUry0dhuuEzcaOfXYfFGg8NT35RHv6pOMnP1Pz2lNwq3YiWIWW Z4VkbYiIZmSRtfF07OyqS2sTcDWt1tp2MQgme83vJ4I15ZanQI7v2Gi9Ne+x+x5WwdM/ 6BGN1T4pmIora22a0a4exyNKQH9Sh9WH9RM+25anKt85pA8AJSTAE2all4jQ6GxvtA23 vT+w== 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; bh=ETN4Gkou8TH1K9ZG2dFH60Es9xYLi1Iwp0OJqbL2aKw=; b=oi8FQeUawGVWkgyAwQpwS+pSC1eM2r48gUrMSNH/dEwWypZ43NLMz0kd44oIVkSj0U 6o7cbSDvLRZUC01pA7cFupXI8S532uLsQ3LnfLMY7Yswgs35FroGiNXBvDjjES47DL2C la9+slEDDa2m4R0NkCRX2d+5weEia8eiJzc5J6a1qdpXWJjBym3Fy5TbOb7WYdF2xkI8 MaFZfMqrc4/fQIe+ROCFew9oZxMDu4VjYg31EO5KaPXROPvRTQyBrBsC7EqBqpo+7au6 cn+Na9lp+RK0WetQeY3TojEHreuM5KEfOTAy6MF972Rq/sYWUxyP0ZXOmv3SGfL+7fVk wIxA== X-Gm-Message-State: APjAAAW5dvbXbdZfC+LdT6OysaqtUwmCVFvH4c2YeNfpQJGxoGRzbxHv XLmyZXk7Eo4pvKiZpyL+hlTR9ykrVNNq0+AxdJGvkVC7+Hk= X-Google-Smtp-Source: APXvYqxivIFB6toFL99jV8d8WI3cFwSULUfCuQwlWo+E98bfTwsUiKdy53CMnYBsYNew2QkxJ2KCQXfwzajvWzAA0bI= X-Received: by 2002:a02:ce52:: with SMTP id y18mr34753001jar.78.1562081237718; Tue, 02 Jul 2019 08:27:17 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d2c X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:238298 Archived-At: --00000000000048d9b0058cb4619f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 2, 2019 at 2:16 PM Alan Mackenzie wrote: > Hello Jo=C3=A3o and Emacs. Hello Alan and Emacs, > 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. And sorry for the duplicate reply Alan.] > 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. 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`. 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. 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. 4. Someone reinvents electric-pair-mode in cc-model.el. Let's not do this. I prefer 2. Thanks, Jo=C3=A3o > > > 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). -- Jo=C3=A3o T=C3=A1vora --00000000000048d9b0058cb4619f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Jul 2, 2019 at 2:16 PM Alan Mackenzie <acm@muc.de> wrote:

> Hello Jo=C3=A3o and Emacs.

Hello Alan and Ema= cs,

> 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 assumin= g the latter and correcting. And sorry for the duplicate reply Alan.]

> 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
>
> .=C2= =A0 Type a " at the end of foo. =C2=A0electric-pair-mode wrongly inser= ts two
> "s.
>
> Diagnosis: electric-pair--unbalance= d-strings-p works after the (single)
> newly typed " has been st= ripped from the buffer.=C2=A0 It attempts to
> determine whether ther= e are any open strings after the point of
> insertion.=C2=A0 It does = this by using parse-partial-sexp, and checks (nth 3
> <result>)= 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.= =C2=A0 If you
remember, this had various consequences vis-a-vis bal= ancing,
broke a test (one that I disabled in the expectation that= a fix would be
made available, which I don't think happ= ened). Here are some points of
that thread:

= 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 mi= mic what some
compilers do, is very weak because (1) the cod= e is invalid in both
situations (not in any way "slight= ly less" invalid in any of them) and
(2) compilers don&= #39;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. `u= p-list`
and friends) for modes such say, `js-mode` and (2) b= reak features
that expect this to work, most notably electri= c-pair-mode.

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 ba= lance has been
maintained after the double quote insertion, = i.e. it has not worsened.=C2=A0
That is the general contract= of=C2=A0 `electric-pair-preserve-balance`.

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. Perha= ps
it can already be disabled with a couple of lines of emac= s-lisp tweaking
the syntax-table.

3. Someone = comes up with a suitable indirection that doesn't involve
hardc= oding `cc-mode` in elec-pair.el.=C2=A0 That indirection would
presumably do what you want for modes `cc-mode` derived
fr= om cc-mode.

4. Someone reinvents electric-pair= -mode in cc-model.el.
Let's not do this.
=

I prefer 2.

Thanks,<= br>
Jo=C3=A3o



>


>
> T= his 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 str= ing fence
> property on the newline at the end of the line.
> e= lectric-pair--unbalanced-strings-p thus returns the wrong result.
>> A more suitable algorithm might look something like this: check whet= her
> the newly inserted " has a string fence syntax-table text = property.
> (Its insertion will have already triggered the before- an= d
> after-change-functions which set this property.) =C2=A0If so, the= re is an
> open string.=C2=A0 Of course, this only applies to CC Mode= modes.
>
> --
> Alan Mackenzie (Nuremberg, Germany).
=


--
Jo=C3=A3o T=C3=A1vora
--00000000000048d9b0058cb4619f--