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 13:10:45 +0100 Message-ID: References: <20190708100539.GD4529@ACM> <20190708164501.GB5244@ACM> <20190708180551.GD5244@ACM> <20190709160022.GC5230@ACM> <20190709182646.GD5230@ACM> <20190710103242.GB4109@ACM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e16f97058d529129" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="219192"; 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 14:11:12 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 1hlBRG-000us6-Ng for ged-emacs-devel@m.gmane.org; Wed, 10 Jul 2019 14:11:11 +0200 Original-Received: from localhost ([::1]:60656 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlBRF-0000M3-Mj for ged-emacs-devel@m.gmane.org; Wed, 10 Jul 2019 08:11:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53020) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlBR9-0000LS-59 for emacs-devel@gnu.org; Wed, 10 Jul 2019 08:11:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hlBR5-0002W0-JC for emacs-devel@gnu.org; Wed, 10 Jul 2019 08:11:02 -0400 Original-Received: from mail-io1-xd41.google.com ([2607:f8b0:4864:20::d41]:34348) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hlBR5-0002TX-B2 for emacs-devel@gnu.org; Wed, 10 Jul 2019 08:10:59 -0400 Original-Received: by mail-io1-xd41.google.com with SMTP id k8so4214212iot.1 for ; Wed, 10 Jul 2019 05:10:58 -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=O9bgZAvaOerz1Oheb0p4Yb4U7lId5QLCSBTiVeEAoXk=; b=lFCKY+dZTd+jDdG2SP6prtwfCYHToS0yf4TENkgaNX+0uDlOHMTW3lGCLt8brUyAYE tsz8qpc+UG7Eqz81db7BI6XjDmYLp8tgk3uHa3dqW0nze/cS1r1QRtTFv48QqN91CJ9p 3Za5Gs7YjhofdlUgYc9eTKqUxYe0qHTDCFOiXKnbf57gK8uOpJagmFJRBSsTK3h3IihJ xmYpJRCPUWCD/gsscs8G7jmx5hb4vUdeeZAaN3ymKuscv9H3TW9vZfRK2R7uvztMU+AJ 7pA39GwwTHd/z5oqtnwjElO+v4QYx1QYjNAlh5t3YE4z+ucbvj9biDO09SOqeNaNDZVK fnVA== 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=O9bgZAvaOerz1Oheb0p4Yb4U7lId5QLCSBTiVeEAoXk=; b=B53tT3kNXiYnRFdgLzySC2pDX/5Zcui3Ku0mbLt0CneEqviNmymUj1m+PZkomA3bmu E92NKYQrgG0/FyqAGoouDC3LbmCMsCyf+Abaa2NsmVowSqTwrco3++rPW95pu+e1pzXN R8e84TT/7YsLbFikOqNOCPGYpkVcvTNOql0pX9vVWDdoRMb0Y3mUPzbMvzehjT44berC YaTgPRfqLm0rZ2wmkc+PTg+cPE4+xbYU32wCE+UOehVVg0BVDcfCoyh7Jx7oZEsRRghJ Qnh5RRosvVJoWunXGu2WvjQ+G4IQB6Ie4P60seBTG0cW53sRStkT/ZR0kKIA5ow3rwgn VELQ== X-Gm-Message-State: APjAAAU9XFpJrI3g4dzFNUF2VSjg94LVlBg6C1ZfVxsP11hriD8eUjAo TFcyQOOSDY+nHI2ygVVu+QNd8YtxZ/SfUY2urz0= X-Google-Smtp-Source: APXvYqzlgMdQ9TGyOvU0eeGMs0kylkDNrDBSwKYYLRR/l0PJ6GvEkybiZlgE9RUaXER0HNH5NNQ4q5ienTpVZCfel94= X-Received: by 2002:a5e:9319:: with SMTP id k25mr998829iom.137.1562760657854; Wed, 10 Jul 2019 05:10:57 -0700 (PDT) In-Reply-To: <20190710103242.GB4109@ACM> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d41 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:238498 Archived-At: --000000000000e16f97058d529129 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2019 at 11:32 AM Alan Mackenzie wrote: > Hello, Jo=C3=A3o. > > On Tue, Jul 09, 2019 at 19:53:17 +0100, Jo=C3=A3o T=C3=A1vora wrote: > > On Tue, Jul 9, 2019 at 7:26 PM Alan Mackenzie wrote: > > > > Not really. The overwhelmingly most common use case is typing in a > > > short string which fits on one line, when the next line is (almost) > > > always a line of code. It is not sensible to fontify arbitrarily lar= ge > > > pieces of code as a string, just because the user hasn't yet reached > her > > > closing double quote. > > > You think that's the "overwhelmingly" most common use case. But if > > the user is using electric-pair-mode (the thing you just "fixed", the > thing > > that the original author of the bug is using), it just doesn't happen. > > Even if electric-pair-mode is enabled, the overwhelmingly most common > use case will still be a short string which fits on a single line, and > the next line will still (almost) always be a line of code. > You misunderstood me. What I said "just doens't happen" is "fontify arbitrarily large pieces". That's fine for users of electric-pair-mode, but that's a minority > sport. Many, likely most, users don't use that mode. For that > majority, CC Mode no longer fontifies arbitrarily large pieces of code > as a string. > Even if electric-pair-mode users are a minority users of autopairing solutions such as smartparens are most definitely not. Every modern editor has one of those. The very same applies to those users. But even if those users are a minority (< 50%), it still doesn't justify breaking long-held behavior that they expect. > > Now if you don't use electric-pair-mode or another paren-matching > > solution you will see the common blinking, precisely because the major > > mode doesn't know if the user is keeping a closing quote in his > > "mental stack". > > With all due respect, I think this anthropomorphic view of major modes > supposedly "guessing" what the user wants is wide of the mark. Precisely. I say it _doesn't_ know and _can't_ know. So any guess, such as the one you're taking, that it's an invalid string, is wrong some percentage of the time. > In C > Mode, a string starts at an opening ", and stops at the next " or > unescaped NL. That's how a compiler handles it. It's that simple. > The compiler doesn't edit code. It's irrelevant how it views the lines afte= r the error, so long as it hightlights the error in the correct line. > > All that Stefan is saying is that you are providing for this group of > > people, but that there is another group of people for which not only > > the functionality you are developing isn't useful, but also > > potentially harmful. > > I fail to see this harm. > Stepping carefully on the terms, you have made two patches since this "problem" happened: 1. One to restore the previous e-p-m behaviour in cc-mode 2. A long patch devised "just for me" to restore previous C-M-behaviour The necessity of such patches, and the fact that patch 2 is likely buggy, according to you, can be seen, in my opinion, as an expression of "harm". > We all agree that if an unterminated string occurs, be it accidentally > > by the deletion of a closing quote, or transiently (because the user > > hasn't downloaded his "mental closing quote"), the matter should > > be annotated on that line. > > I don't agree. Or rather, that characterization is a gross distortion > of my take on the matter, which I stated last Thursday. This is the > passage which Stefan refuses to reply to, or even acknowledge I wrote: > > >> The error is clear: There is an opening quote without a matching > >> closing quote. The former part of the error is at the opening quote, > >> so we must indicate its position somehow, most simply by marking it > >> with warning-face. The latter part of the error happens at the first > >> unescaped EOL; this is what defines the string as invalid. We must > >> indicate this position as well, and the best way of doing this is > >> terminating the string-face at that position. > > >> It is not arbitrary. We are not trying to guess the intention of the > >> user; we are pointing out the objective error. > So the "gross distortion" is that you think it's absolutely necessary that the error be annotated both at string start and invalid string end? Only on= e of them is are totally wrong for you. Is that it, the thursday thing? Doesn't seem so important for me, but if it were, the flymake backend I proposed can highlight wherever you most desire. I don't know about Stefan's solution, though. Does the compiler tell the user about both locations? > > There are multiple simple solutions that do that, with no perceived > > drawbacks. Please consider some of them. > > These simple solutions all have drawbacks. I'd already considered them, > or several of them, before arriving at the current solution for CC Mode. > So can you summarize, for my benefit: - What are the drawbacks of Stefan's solution? - What are the drawbacks of my flymake-based soluion? Jo=C3=A3o --000000000000e16f97058d529129 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 10, 2019 at 11:32 AM Alan Mackenzie <acm@muc.de> wrote:
Hello, Jo=C3=A3o.

On Tue, Jul 09, 2019 at 19:53:17 +0100, Jo=C3=A3o T=C3=A1vora wrote:
> On Tue, Jul 9, 2019 at 7:26 PM Alan Mackenzie <acm@muc.de> wrote:

> > Not really.=C2=A0 The overwhelmingly most common use case is typi= ng in a
> > short string which fits on one line, when the next line is (almos= t)
> > always a line of code.=C2=A0 It is not sensible to fontify arbitr= arily large
> > pieces of code as a string, just because the user hasn't yet = reached her
> > closing double quote.

> You think that's the "overwhelmingly" most common use ca= se. But if
> the user is using electric-pair-mode (the thing you just "fixed&q= uot;, the thing
> that the original author of the bug is using), it just doesn't hap= pen.

Even if electric-pair-mode is enabled, the overwhelmingly most common
use case will still be a short string which fits on a single line, and
the next line will still (almost) always be a line of code.

You misunderstood me. What I said "just doens'= ;t happen" is "fontify arbitrarily
large pieces&qu= ot;.

That's fine for users of electric-pair-mode, but that's a minority<= br> sport.=C2=A0 Many, likely most, users don't use that mode.=C2=A0 For th= at
majority, CC Mode no longer fontifies arbitrarily large pieces of code
as a string.

Even if electric-pair-mode= users are a minority users of autopairing
solutions such as smar= tparens are most definitely not. Every modern
editor has one of t= hose.=C2=A0 The very same applies to those users. But even
i= f those users are a minority (< 50%), it still doesn't justify break= ing
long-held behavior that they expect.
=C2= =A0
> Now if you don't use electric-pair-mode or another paren-matching<= br> > solution you will see the common blinking, precisely because the major=
> mode doesn't know if the user is keeping a closing quote in his > "mental stack".

With all due respect, I think this anthropomorphic view of major modes
supposedly "guessing" what the user wants is wide of the mark.=C2= =A0

Precisely. I say it _doesn't_ know= and _can't_ know. So any guess,
such as the one you're t= aking, that it's an invalid string, is wrong
some percen= tage of the time.
=C2=A0
In C
Mode, a string starts at an opening ", and stops at the next " or=
unescaped NL.=C2=A0 That's how a compiler handles it.=C2=A0 It's th= at simple.

The compiler doesn't edi= t code. It's irrelevant how it views the lines after
the erro= r, so long as it hightlights the error in the correct line.

<= /div>

> All that Stefan is saying is that you are providing for this group of<= br> > people, but that there is another group of people for which not only > the functionality you are developing isn't useful, but also
> potentially harmful.

I fail to see this harm.

Stepping caref= ully on the terms, you have made two patches since
this &quo= t;problem" happened:

1. One to restore the pr= evious e-p-m behaviour in cc-mode
2. A long patch devised "j= ust for me" to restore previous C-M-behaviour

The necessity of such patches, and the fact that patch 2 is likely buggy,<= /div>
according to you, can be seen, in my opinion, as an expression of= "harm".

> We all agree that if an unterminated string occurs, be it accidentally=
> by the deletion of a closing quote, or transiently (because the user > hasn't downloaded his "mental closing quote"), the matte= r should
> be annotated on that line.

I don't agree.=C2=A0 Or rather, that characterization is a gross distor= tion
of my take on the matter, which I stated last Thursday.=C2=A0 This is the passage which Stefan refuses to reply to, or even acknowledge I wrote:

>> The error is clear: There is an opening quote without a matching >> closing quote.=C2=A0 The former part of the error is at the openin= g quote,
>> so we must indicate its position somehow, most simply by marking i= t
>> with warning-face.=C2=A0 The latter part of the error happens at t= he first
>> unescaped EOL; this is what defines the string as invalid.=C2=A0 W= e must
>> indicate this position as well, and the best way of doing this is<= br> >> terminating the string-face at that position.

>> It is not arbitrary.=C2=A0 We are not trying to guess the intentio= n of the
>> user; we are pointing out the objective error.

So the "gross distortion" is that you think it&#= 39;s absolutely necessary that
the error be annotated both at str= ing start and invalid string end? Only one
of them is are totally= wrong for you. Is that it, the thursday thing?

Doesn't seem so important for me, but if it w= ere, the flymake backend
I proposed can highlight wherever y= ou most desire. I don't know about
Stefan's solution= , though.

Does the compiler tell the user about bo= th locations?
=C2=A0
> There are multiple simple solutions that do that, with no perceived > drawbacks. Please consider some of them.

These simple solutions all have drawbacks.=C2=A0 I'd already considered= them,
or several of them, before arriving at the current solution for CC Mode.

So can you summarize, for my benefit:
=

- What are the drawbacks of Stefan's solution= ?
- What are the drawbacks of my flymake-based soluion?

Jo=C3=A3o
--000000000000e16f97058d529129--