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: Tue, 9 Jul 2019 19:53:17 +0100 Message-ID: References: <20190704190100.GG5564@ACM> <20190708100539.GD4529@ACM> <20190708164501.GB5244@ACM> <20190708180551.GD5244@ACM> <20190709160022.GC5230@ACM> <20190709182646.GD5230@ACM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009513ef058d4413b4" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="136001"; 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 Tue Jul 09 21:03:36 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 1hkvOq-000ZGN-DJ for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 21:03:36 +0200 Original-Received: from localhost ([::1]:52908 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkvOp-0004nR-9j for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 15:03:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47196) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkvF6-0006Hn-65 for emacs-devel@gnu.org; Tue, 09 Jul 2019 14:53:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hkvF4-00014s-J9 for emacs-devel@gnu.org; Tue, 09 Jul 2019 14:53:31 -0400 Original-Received: from mail-io1-xd44.google.com ([2607:f8b0:4864:20::d44]:44954) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hkvF4-00012u-8u for emacs-devel@gnu.org; Tue, 09 Jul 2019 14:53:30 -0400 Original-Received: by mail-io1-xd44.google.com with SMTP id s7so45406724iob.11 for ; Tue, 09 Jul 2019 11:53:30 -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=hh124qZZ0+atxjSP0FAPNNqfDuEnfeiOodlGlAg5uJo=; b=dJKHgvPs52vipPTcjRS8Ttdn++X4aN406//WB5Sn7EqKmj1rjqk9SYng/E8KoSAr1L F0Stt6yeb6HEK+JLLIgFabXYQcN9OhEnm2ihTMLFGTqUrhJskGID96w2071wVioRLHYv rhpuuj8JQhd2NxbipuuBMw0EGATXuAdSR2V4BbCGe7HH1fETXsjZm+JvlKbQHknR8Ce0 yTfFK8vjbV5rvSb9kRztnd8DdRag40/SZ15L1BnmYttiAuupIgsQodpzPIHuGZeHLohz 0XFtM4Ks7OGXkQAIuJEBsOyenb53AGy/0A+LVzBT6LuOTNKNtvfAXj7EliTSRRNAYOHL l9jg== 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=hh124qZZ0+atxjSP0FAPNNqfDuEnfeiOodlGlAg5uJo=; b=CeSiw6kQ+vI4ogyYMpxqZLcvxDZwCEMYt9PEj5+4/w15Lg4I/cMgHbSHeIU8CzJ009 81BukZp7uyJFosIQr4U+PuTU3V+Qexecf0MYBZ58Q7UiR1wmUDKeA5YPjLzAesNaot32 nzBzG/eYYoflkx3AcKYnj8IVxcK9BVUyp8OALYoDJtjAN9Fad3y5HDxksSyoO2p07rdj q4l2EU2N1Laz8dhSBNqDyLBKk8xfkzc1yWNC6LpAEbDGv+FdPuVV4/iUEJwVpC9dAngm RYd9NlOsrAbBiBVuWwX9uSZ7lmyjASifke5Z/ezUMr/ArMV76kVSOXvxDxQWiYZB9VVO RppA== X-Gm-Message-State: APjAAAWJCU/AhcWaSZY9pkOX9BxJN/hAG2hrEtOQpx7vkt6cMMwDZ8um v9zCqxY+VBOAAdLLPcEBtB8zsjfWHDwgqHgyQoE= X-Google-Smtp-Source: APXvYqzyLcIZbwK5FR1kBcqRtMEaBbcTJHsckfBqdxDwV7aaogZ4S+UFLOFpxfUKvhmfoZaFPYpLi4778lO9urSUU4I= X-Received: by 2002:a5d:9ec4:: with SMTP id a4mr25820445ioe.125.1562698409380; Tue, 09 Jul 2019 11:53:29 -0700 (PDT) In-Reply-To: <20190709182646.GD5230@ACM> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d44 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:238476 Archived-At: --0000000000009513ef058d4413b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 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. That's not because those users don't insert strings in their code, but because the closing double quote is inserted for them automatically. And so no arbitrarily large piece of code is fontified as a string _in the particular case of adding, say, a printf("Hello world"); to the start of a function. 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". 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. 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. There are multiple simple solutions that do that, with no perceived drawbacks. Please consider some of them. Jo=C3=A3o --0000000000009513ef058d4413b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 typing in a
> short st= ring which fits on one line, when the next line is (almost)
> always = a line of code.=C2=A0 It is not sensible to fontify arbitrarily large
&g= t; 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&= quot;, the thing
that the original author of the bug is using), i= t just doesn't happen. That's
not because those users don= 't insert strings in their code, but because
the closing doub= le quote is inserted for them automatically. And so no
arbit= rarily large piece of code is fontified as a string _in the particular case=
of adding, say, a printf("Hello world"); to the start = of a function.

Now if you don't use electric-p= air-mode or another paren-matching
solution you will see the= common blinking, precisely because the major
mode doesn't kn= ow if the user is keeping a closing quote in his
"menta= l stack". All that Stefan is saying is that you are providing for
this group of people, but that there is another group of people for w= hich
not only the functionality you are developing isn't usef= ul, but also
potentially harmful.

W= e 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 m= atter should
be annotated on that line. There are multiple simple= solutions that
do that, with no perceived drawbacks. Please cons= ider some of them.

Jo=C3=A3o
--0000000000009513ef058d4413b4--