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: Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode Date: Tue, 2 Jul 2019 18:22:34 +0100 Message-ID: References: <20190702131632.GA30597@ACM> <20190702160410.GB30597@ACM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000043fc2d058cb5fe11" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="159811"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36474@debbugs.gnu.org To: Alan Mackenzie , emacs-devel , spacibba@aol.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 02 20:44:18 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 1hiNlK-000fUW-4Z for ged-emacs-devel@m.gmane.org; Tue, 02 Jul 2019 20:44:18 +0200 Original-Received: from localhost ([::1]:56260 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiNlJ-0003NU-4o for ged-emacs-devel@m.gmane.org; Tue, 02 Jul 2019 14:44:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60818) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiMUY-0002AP-Fn for emacs-devel@gnu.org; Tue, 02 Jul 2019 13:22:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hiMUU-0006QB-48 for emacs-devel@gnu.org; Tue, 02 Jul 2019 13:22:52 -0400 Original-Received: from mail-io1-xd42.google.com ([2607:f8b0:4864:20::d42]:45928) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hiMUR-0006OY-4y for emacs-devel@gnu.org; Tue, 02 Jul 2019 13:22:47 -0400 Original-Received: by mail-io1-xd42.google.com with SMTP id e3so38772025ioc.12 for ; Tue, 02 Jul 2019 10:22:47 -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=ek3lqFxvelltYUSB4CzR04L4X3EG5KvIhM5NJVtYmnaLaaDD4NMTzbhURG4O2x5IKb drohuW0Ei2Z0kcYiwv4AYfE6uw5Hzb/ASZa0//SHPLGkQZILKbwbUR3AfEEa1TqlVizF V0ZRBiJn3BgvQjBwGc+heI8NlMdeqmYDoS9l2pdvswUoHZtaq4sEULTzRLO7dim4rybP tmca+4sMtRYJQJcITUb4Glzg+s8f6SYIwoWla1fNVS+Po3JGBla6mnznck4SiMRPLC5R a6DRAsG5+rjVH8a1DpN5RlY3SxJ+/GVei1ZYgzdhnGX2NpSZrfkRXef/3mCjhol/wqU0 65hA== X-Gm-Message-State: APjAAAVSUXAMy9LLpqVV7YhDi7w3ZqvCx/Vk1e3gzuUNBNoeck4Yk6Dt yTMZadA22MLcLcdUW8jJeLW7B0Fwa9BOwD3TD0s= 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) In-Reply-To: <20190702160410.GB30597@ACM> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d42 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:238302 Archived-At: --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--