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: Wed, 3 Jul 2019 10:28:11 +0100 Message-ID: References: <20190702131632.GA30597@ACM> <20190702160410.GB30597@ACM> <20190702182811.GC30597@ACM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008d0032058cc37b19" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="221410"; mail-complaints-to="usenet@blaine.gmane.org" Cc: spacibba@aol.com, emacs-devel To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 03 11:34:52 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 1hibf8-000vS8-PZ for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2019 11:34:50 +0200 Original-Received: from localhost ([::1]:34258 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hibf7-0001mK-Pr for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2019 05:34:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36725) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hibYz-0006qJ-DX for emacs-devel@gnu.org; Wed, 03 Jul 2019 05:28:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hibYw-0007lP-BT for emacs-devel@gnu.org; Wed, 03 Jul 2019 05:28:29 -0400 Original-Received: from mail-io1-xd29.google.com ([2607:f8b0:4864:20::d29]:44932) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hibYw-0007eg-1W for emacs-devel@gnu.org; Wed, 03 Jul 2019 05:28:26 -0400 Original-Received: by mail-io1-xd29.google.com with SMTP id s7so3097439iob.11 for ; Wed, 03 Jul 2019 02:28:23 -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=AtXw5T//fSFCTkKSvp493Cxa14QTEsadmFrjLo3Nnbk=; b=BtmJ0YdQ8447Vlfh18FDN/UncWP6C0jKCe9LDYoyPa96zgLATyZBEMcy9JJlrrtiYJ dUuk+AKBfqBf9pjkG9SNdEySW1bcfF5UecmeXIdR261y8PzCjyWZ4BEej7iVj6j0hwTD vwyCi7VwiMTEGiYqwr9quWhLlMfGq/ED3BDaERmAvBrgPY/S8dRHm1aasl2schyJccLy LQrD+ursKYY8zxWuSF2TgZzucUe6ZIr2FyCq3x3/IGzlkKiYEa+9K24kF9cV/pZH+S2u x6ezD6lqU43i52OqskcECxWU6J3jZxQjA45hCQGKsiuMupOZ3UysanzvRbUlMCgOwVKO feJQ== 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=AtXw5T//fSFCTkKSvp493Cxa14QTEsadmFrjLo3Nnbk=; b=ank3JMZl2PqWs3FGLHcfvGgY/EhXpgNpqCu2wVrFSF2zjnpBayFnwK7JxPpEcRs29a j+gIT0ds9O2+Ru3DoOahDFFi8U31T6wEsiAaDWHXissiQcoLEA1qsF+XKYy7Or+oSVPf pnjwgc9cFh9v0jzpthJ6iEVBS0VKFD1qEQDqsyn30vzY6d5aaFOjcDRrHG5uDsIMF5sv 8T73UCwtCv0zALdg2wTn2hVwl0rTzb/WGlCM8Si2OqsA9u4KBpc5OHVTfc8s2qXCFdyn XXiCNHaGkxg9OXZe5JMuYyw7/wSHdsr3yDsgkBdNAMACVRBc9hAYTmJkA/rgS7OThXAP e5IQ== X-Gm-Message-State: APjAAAWn0Jb+Cn+QSSVnZCGt7Cf6iqwg8w1ORRQ5K3Fkr7t1r/wgt2ou 55MeBgdi/koENs9Lo+aRMed1QxRBsgoKtKKtrxM= X-Google-Smtp-Source: APXvYqwvCFhDI6Qly4aGr8/W/tWSp+i4DEtg4QB/HaoTC3frWSF57epmN22321mulsMFqY9vpAVIwnxcCA/FroBdTfQ= X-Received: by 2002:a6b:b257:: with SMTP id b84mr40691696iof.137.1562146102901; Wed, 03 Jul 2019 02:28:22 -0700 (PDT) In-Reply-To: <20190702182811.GC30597@ACM> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d29 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:238321 Archived-At: --0000000000008d0032058cc37b19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 2, 2019 at 7:28 PM Alan Mackenzie wrote: > Hello, Jo=C3=A3o. > I didn't know about the former, and as for the bug, it is a different > bug with differenct causes from #36423. If you say so... I stopped cross-posting, you probably should, too. > > > 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. C-M-u (up-list) made an invalid assumption? > > 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. > 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. Start emacs -Q, open a buffer with a double quote followed by some newlines and then another another double quote. Now put the buffer in C++ mode and type C-M-u from between the quotes. Instead of up-listing to the first quote, you get an error. Now but point on the starting quote and try C-M-f. Again, error. But only in Emacs 27/cc-mode, probably starting from fe06f64b (that's a git commit hash). Now repeat this experiment. Let me make a little ASCII table: WORKS DOESN'T emacs 27/c++mode X emacs 26.1/c++-mode X emacs 27/js-mode X emacs 27/ruby-mode X emacs 27/(many) X Do you know what I'm talking about now? Now, you might not care for this consistency, but I personally did. I've always had my methods of navigating code with unterminated strings, with _or without_ electric-pair mode and your cc-mode changes broke this workflow. > > 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. I gave your one exactly one paragraph ago, which you called dismissed as "irrelevant". *shrug*. > > 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. What about d37d30cef5bbbdf8d17315835126d76d4681b22a? Is that the same problem? Maybe, I don't know. Certainly the broken C-M-u and C-M-f, aren't the same problem. > 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. It's not "my" code and I won't be bullied into making changes I don't agree with. Things worked fine until you added a feature in June 2018 that broke them. You refuse to even let the user disable that feature or consider alternatives. That's simply not reasonable to me. > > 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'd ask you to actually give an argument instead of an insult, but I've been on this hamster wheel before, so never mind. It works quite well. -- Jo=C3=A3o T=C3=A1vora --0000000000008d0032058cc37b19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 2, 2019 at 7:28 PM Alan Mackenzie <acm@muc.de> wrote:
> Hello, Jo=C3=A3o.<= br>
> I didn't know about the former, and as for the bug, it is a= different
> bug with differenct causes from #36423.

If you sa= y so... I stopped cross-posting, you probably should, too.

> >= > This isn't true.
>
> > What "isn't true&q= uot;? Have those features broken or not?
>
> They may well be b= roken.=C2=A0 CC Mode hasn't broken them.=C2=A0 They made invalid
>= ; assumptions, which turned out to be unjustified.

C-M-u (up-list) m= ade an invalid assumption?

> > They worked before the fe06f643= b commit and don't work after the
> > commit. It sounds quite = unrefutable to me.
>
> I don't know what you're talking= about.
> I've just tried these in a multiline string in C++ Mode= .=C2=A0 Both up-list
> and forward-sexp work just fine.=C2=A0 I don&#= 39;t know what you're doing.

Start emacs -Q, open a buffer with = a double quote followed by some
newlines and then another another double= quote.=C2=A0 Now put the buffer in
C++ mode and type C-M-u from between= the quotes.=C2=A0 Instead of up-listing
to the first quote, you get an = error.=C2=A0 Now but point on the starting
quote and try C-M-f.=C2=A0 Ag= ain, error. But only in Emacs 27/cc-mode,
probably starting from fe06f64= b (that's a git commit hash).

Now repeat this experiment. Let me= make a little ASCII table:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0WORKS =C2=A0 =C2=A0DOESN'T
emacs 27/c++mode =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0X<= br>emacs 26.1/c++-mode =C2=A0 X
emacs 27/js-mode =C2=A0 =C2=A0 =C2=A0Xemacs 27/ruby-mode =C2=A0 =C2=A0X
emacs 27/(many) =C2=A0 =C2=A0 =C2=A0= X

Do you know what I'm talking about now?

Now, you might= not care for this consistency, but I personally did.

I've alway= s had my methods of navigating code with unterminated strings,
with _or = without_ electric-pair mode and your cc-mode changes broke
this workflow= .

> > 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 wha= t you want is the red annotation, are you
> > absolutely sure ther= e isn't a better way to get it?
>
> No, I'm not.=C2=A0 = That's why I invited you to come up with a better way, if
> you c= an.

I gave your one exactly one paragraph ago, which you called dism= issed as
"irrelevant". *shrug*.

> > I'll be &= quot;mulling this over". There are potentially many other points
&g= t; > of breakage
> "Potentially" many?=C2=A0 So far, the= re is precisely one, in
> electric-pair--unbalanced-strings-p.
What about d37d30cef5bbbdf8d17315835126d76d4681b22a? Is that the same
p= roblem?=C2=A0 Maybe, I don't know.=C2=A0 Certainly the broken C-M-u and= C-M-f,
aren't the same problem.

> No, you'd be cleani= ng up your code, to conform with the reality that in
> 2019 major mod= es use syntax-table text properties.=C2=A0 Features from CC
> Mode ha= ve a habit of migrating to the Emacs core.

It's not "my&quo= t; code and I won't be bullied into making changes I don't
agree= with.=C2=A0 Things worked fine until you added a feature in June 2018
t= hat broke them.=C2=A0 You refuse to even let the user disable that feature<= br>or consider alternatives.=C2=A0 That's simply not reasonable to me.<= br>
> > 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:
>
> > =C2=A0 (defun c-unescaped-nls-in-string-p = (&optional quote-pos) t)
>
> It's free software, but th= at's a stupid thing to do.

I'd ask you to actually give an a= rgument instead of an insult, but I've
been on this hamster wheel be= fore, so never mind.=C2=A0 It works quite well.

--
Jo=C3=A3o T=C3= =A1vora
--0000000000008d0032058cc37b19--