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: [PATCH] Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode Date: Wed, 10 Jul 2019 17:05:20 +0100 Message-ID: References: <20190708164501.GB5244@ACM> <20190708180551.GD5244@ACM> <20190709160022.GC5230@ACM> <20190709182646.GD5230@ACM> <20190710103242.GB4109@ACM> <20190710140317.GC4109@ACM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d7a25a058d55d8f6" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="176945"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Stefan Monnier , emacs-devel To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 10 18:13:17 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 1hlFDX-000jud-Va for ged-emacs-devel@m.gmane.org; Wed, 10 Jul 2019 18:13:16 +0200 Original-Received: from localhost ([::1]:35196 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlFDV-00056i-3G for ged-emacs-devel@m.gmane.org; Wed, 10 Jul 2019 12:13:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52271) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlF69-00005z-7G for emacs-devel@gnu.org; Wed, 10 Jul 2019 12:05:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hlF67-0002fA-2l for emacs-devel@gnu.org; Wed, 10 Jul 2019 12:05:37 -0400 Original-Received: from mail-io1-xd30.google.com ([2607:f8b0:4864:20::d30]:40803) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hlF66-0002dh-T2 for emacs-devel@gnu.org; Wed, 10 Jul 2019 12:05:35 -0400 Original-Received: by mail-io1-xd30.google.com with SMTP id h6so5856834iom.7 for ; Wed, 10 Jul 2019 09:05:34 -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=82++69liE4n/LLA4gkPTcyYvooHDQKf7F0WLK3xaDpc=; b=ZS1sF+CsGRzURd3U2PfSr/GhbVGF7DrdT3fwQTYx0NVJMwSBV/HYBQdtecdmHQArRO DlmVwX0bHmzNgqeaT/M3WnwQIq4HzL+IOo5QFHJKoUsf2iu8mVbP2MPezP1HFyRes+HB gZiqAxFlfaWy/xaDH0HpttxzrMuGeE9Dawe8TAbC+QPzr15LvG3h9JSXIftEXsz2XO0j G0zptI4E6Xoe4RxcTZj/O8shNZH3uIFjPKTyiw4cjJLgZ9bbQJS2W1zLzUQM7JPxD9z1 RBM0DnWWImloYM9OeN7V0maQY5dgWhQtvxAof8FUzX7ydvZ/xWKCq+IV+jiydgIPVDoV 7Qxg== 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=82++69liE4n/LLA4gkPTcyYvooHDQKf7F0WLK3xaDpc=; b=KXI8Q2FYomWW1fYk6r1t4nWYZSSQx4I/+EBjolhLn1rzhALJ92YalAe+7P8QBNERR7 Ai4cnObGtl/mxQUmILjOhibyBwQJWwbbtuauu/221jIShj0ZXMFy65H1r4j6s4yg397t WXx5Iq6mDhT47iEMMRMv5K7i8OtQmKUylh5u618PylN7RkUYMEY/Okb4+u9y6l1wr5MJ CvhWjCWdRle2TV+T1jk11krAwuB5PCnUllyy8K+1G+/wwyu80gLZghATpmu9qc8PZ2AZ azr0i88LPrKccAJZzWKkMleWctUQHXNZfp9rRkQp+/Zf7EsCSsIpw4ynp87OD4+C+OL7 V5Tg== X-Gm-Message-State: APjAAAWCWhJH0ya4KM2r2svgFe4efi+XSEc5oH3hFFWOro++5gh2te7h hhOZyaASdB6JrYNnH077Wf/G4NFL+Gxxn+ntF8s= X-Google-Smtp-Source: APXvYqyLg31CQynsCOQJbz6KqypbrwFi1BChldU/XMxc0gBSrNbWyV2rlpGZkxkhSK+F3JFjDGnVtBywlJTscE5gRzA= X-Received: by 2002:a02:69d1:: with SMTP id e200mr36444649jac.138.1562774733298; Wed, 10 Jul 2019 09:05:33 -0700 (PDT) In-Reply-To: <20190710140317.GC4109@ACM> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d30 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:238504 Archived-At: --000000000000d7a25a058d55d8f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2019 at 3:03 PM Alan Mackenzie wrote: > I'll believe you, though I don't know what you mean by smartparens. See https://github.com/Fuco1/smartparens. > Or are we talking about fixing long standing breakage they've had to > tolerate? At least two people on this list have said they welcome the CC > Mode style of fontification of invalid strings. I wasn't talking about that, I was talking about the cc/e-p-m related bug that a user reported, and the C-M-stuff that I use. This is a behavior in emacs that probably existed since cc-mode was first created up to last year. But, we can start talking about that "tolerated breakage", by which you probably mean what has been recently described here as "blinking" a lower portion of the screen between string/non-string fontification for people that don't use a delimiter-pairing solution. And we could start by examining solutions that: 1. Don't have any drawbacks to e-p-m and C-M-navigation; 2. Fix it in all of Emacs, even in modes that _do_ have multi-line strings; We've established that your cc-mode solution does not verify 1 (and by definition it does not verify 2). > What's that got to do with it? If you don't like CC Mode's definition of > a string, propose an alternative here, a non-vague alternative, and we > can discuss it. Very well: I want the previous CC Mode's definition of a string, before you= r changes of June 2018. This is so non-vague that it's even coded up in the git repository. At the very least I want to be able to switch to it, and also think it should be the default, because it's (quite probably) the definition that has existed from cc-mode's inception in 19xx up to June 2018. > Yes. There were bugs in the interface between CC Mode and > electric-pair-mode, and half of us had to sort these out. It's a good > job that one of us was able to step up, and diagnose and fix this. That's a heartwarming comment, because it's always heartwarming that the person who fixes it was the one that broke it in the first place. Pardon, "committed actions that made it work differently than it did before, causing a bug report". > As for 2, what you want there, as I keep saying, is bogus. You want to > treat two syntactically disjoint "s as though they enclosed a string. > Although this is bogus, I have some sympathy with people who want to do > this, on the grounds that it "worked" in the past. But it is > fundamentally bogus. Two "syntactically disjoint" double quotes in C are _always_ bogus. There can be 0 such occurrences in a correct C program. The only job the compiler has is to not compile the program and presumably signal the error. The editor should do so, too. It _doesnt_ need to do it by implementing exactly the syntax of the C standard, because the editor is not not a compiler. And that's the sensible approach that Emacs has taken since a long time. Again, you may argue that with it comes a "blinking" problem for those that don't use quote-pairing solutions. I will agree. And that problem happens with comments, too, and in many many other modes. It's not exclusive to cc-mode. > Must you be like that? That patch is not "likely buggy", any more than > any other patch. You said "the enhancement is not yet bug free". That makes it a least "likely buggy". > There is one particular bug in it, a very obscure Oh, then I think that makes it 100% surely buggy! > As you acknowleged in another post, that patch took some hours to write. > Would you please, as the person clamouring for it, I thanked you for your great unsolicited efforts, but now I must solicit a final one: where exactly did I "clamour" for it? I told you from the beginning that the problem doesn't affect me in particular. I also don't remember having encouraged you to persist in that particular solution for other users sake. Indeed I hope it is never installed, because frankly, breaking the no-disparagement rule, it looks ghastly. Seriously, look at it. > > - What are the drawbacks of Stefan's solution? > It doesn't, at least without an awful lot of effort, fontify an invalid > string in the correct CC Mode fashion. It would leave an arbitrary > amount of text after the end of an invalid string fontified with > string-face. OK. Since I don't know Stefan's solution, I won't refute. But I will ask: 1. What is "the correct CC Mode fashion" these days? 2. What is the problem with the second part. Is it the "blinking" problem that I agreed to earlier? Or is it something else? Are you preoccupied that the syntax of an invalid program as shown in cc-mode is exactly like some compiler's internal view of it? > > - What are the drawbacks of my flymake-based soluion? > It's not part of CC Mode. It would involve loading another package, and > likely would be slower than CC Mode's fontification. It would not be > well integrated with CC Mode, and would possibly need a lot of work to > make it work properly. It already works properly. In many cases it does not need to be "integrated= " with the major mode at all. Also probably faster, depending on whether you launch the compiler process asynchronously (which is the default). I'd say you have to try it. It doesn't need to be flymake, you can ask folks about flycheck, too, which many people prefer (https://www.flycheck.org/en/latest= / ). Jo=C3=A3o --000000000000d7a25a058d55d8f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Jul 10, 2019 at 3:03 PM Alan Mackenzie <acm@muc.de> wrote:
> I'll belie= ve you, though I don't know what you mean by smartparens.

See https://github.com/Fuco1/sma= rtparens.

> Or are we talking about fixing long standing= breakage they've had to
> tolerate?=C2=A0 At least two people = on this list have said they welcome the CC
> Mode style of fontificat= ion of invalid strings.

I wasn't talking about that, I was talki= ng about the cc/e-p-m related bug
that a user reported, and the C-M-stuf= f that I use.=C2=A0 This is a behavior
in emacs that probably existed si= nce cc-mode was first created up
to last year.

But, we can start = talking about that "tolerated breakage", by
which you probably= mean what has been recently described here as
"blinking" a lo= wer portion of the screen between string/non-string
fontification for pe= ople that don't use a delimiter-pairing solution.
And we could start= by examining solutions that:

1. Don't have any drawbacks to e-p= -m and C-M-navigation;
2. Fix it in all of Emacs, even in modes that _do= _ have multi-line strings;

We've established that your cc-mode s= olution does not verify 1 (and by
definition it does not verify 2).
<= br>> What's that got to do with it?=C2=A0 If you don't like CC M= ode's definition of
> a string, propose an alternative here, a no= n-vague alternative, and we
> can discuss it.

Very well: I wan= t the previous CC Mode's definition of a string, before your
ch= anges of June 2018. This is so non-vague that it's even coded up in
the git repository. At the very least =C2=A0I want to be able to swi= tch to
it, and also think it should be the default, because it's (= quite probably)
the definition that has existed from cc-mode's = inception in 19xx up to
June 2018.

> Yes.=C2=A0 = There were bugs in the interface between CC Mode and
> electric-pair-= mode, and half of us had to sort these out.=C2=A0 It's a good
> j= ob that one of us was able to step up, and diagnose and fix this.

That's a heartwarming comment, because it's always heartwarming =
that the person who fixes it was the one that broke it in th= e first
place. Pardon, "committed actions that made it = work differently than
it did before, causing a bug report&qu= ot;.

> As for 2, what you want there, as I keep saying, is = bogus.=C2=A0 You want to
> treat two syntactically disjoint "s a= s though they enclosed a string.
> Although this is bogus, I have som= e sympathy with people who want to do
> this, on the grounds that it = "worked" in the past.=C2=A0 But it is
> fundamentally bogus= .

Two "syntactically disjoint" double quotes in C are _alw= ays_ bogus. There
can be 0 such occurrences in a correct C program. The = only job the compiler
has is to not compile the program and presuma= bly signal the error. The
editor should do so, too. It _does= nt_ need to do it by implementing
exactly the syntax of the = C standard, because the editor is not not
a compiler.

And that's the sensible approach that Emacs has taken since= a
long time.

Again, you may argue that wi= th it comes a "blinking" problem for those
that do= n't use quote-pairing solutions. I will agree. And that problem
happens with comments, too, and in many many other modes. It's = not
exclusive to cc-mode.

> Must you be like= that?=C2=A0 That patch is not "likely buggy", any more than
&= gt; any other patch.

You said "the enhancement is not yet= bug free". That makes it a
least "likely buggy".=
=C2=A0
> There is one particular bug in it, a very obscure=

Oh, then I think that makes it 100% surely buggy!=

> As you acknowleged in another post, that patch took= some hours to write.
> Would you please, as the pe= rson clamouring for it,

I thanked you for you= r great unsolicited efforts, but now I must solicit
a final o= ne: where exactly did I "clamour" for it? I told you from the
beginning that the problem doesn't affect me in particular.= I also don't
remember having encouraged you to persist in th= at particular
solution for other users sake.

<= /div>
Indeed I hope it is never installed, because frankly, breaking
the no-disparagement rule, it looks ghastly. Seriously, look
at it.

> > - What are the drawbacks= of Stefan's solution?
> It doesn't, at least without an awfu= l lot of effort, fontify an invalid
> string in the correct CC Mode f= ashion.=C2=A0 It would leave an arbitrary
> amount of text after the = end of an invalid string fontified with
> string-face.

OK. Since I don't know Stefan's solution, I won'= ;t refute. But I will
ask:

1. What i= s "the correct CC Mode fashion" these days?
2. Wha= t is the problem with the second part. Is it the "blinking"
<= /div>
problem that I agreed to earlier? Or is it something else? Are yo= u
preoccupied that the syntax of an invalid program as shown in <= br>
cc-mode is exactly like some compiler's internal view of = it?

> > - What are the drawbacks o= f my flymake-based soluion?
> It's not part of CC Mode.=C2=A0 It = would involve loading another package, and
> likely would be slower t= han CC Mode's fontification.=C2=A0 It would not be
> well integra= ted with CC Mode, and would possibly need a lot of work to
> mak= e it work properly.

It already works properly. In = many cases it does not need to be "integrated"
with the= major mode at all. Also probably faster, depending on whether you
launch the compiler process asynchronously (which is the default).=C2=A0 = I'd say
you have to try it. It doesn't need to be fl= ymake, you can ask folks about
flycheck, too, which many peo= ple prefer (https://www.fly= check.org/en/latest/).

Jo=C3=A3o


--000000000000d7a25a058d55d8f6--