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 16:43:42 +0100 Message-ID: References: <20190708100539.GD4529@ACM> <20190708164501.GB5244@ACM> <20190708180551.GD5244@ACM> <20190709095222.GA5230@ACM> <81716eae-14f1-a427-b6e0-46e861adc93a@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000938227058d416dd5" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="136545"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Alan Mackenzie , =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 09 17:52:48 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 1hksQB-000YtN-BJ for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 17:52:47 +0200 Original-Received: from localhost ([::1]:51248 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hksI1-0007XO-CQ for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 11:44:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49441) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hksHh-0007X3-QX for emacs-devel@gnu.org; Tue, 09 Jul 2019 11:44:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hksHf-0003FX-PP for emacs-devel@gnu.org; Tue, 09 Jul 2019 11:44:01 -0400 Original-Received: from mail-io1-xd36.google.com ([2607:f8b0:4864:20::d36]:46181) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hksHc-0003Br-04 for emacs-devel@gnu.org; Tue, 09 Jul 2019 11:43:57 -0400 Original-Received: by mail-io1-xd36.google.com with SMTP id i10so44073850iol.13 for ; Tue, 09 Jul 2019 08:43:55 -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=hp6UlvJEo2zF9YT7e1crSNAEMXNIZp6kLMpZ9uCwxqs=; b=GmzVrPfTqX7HpPgmAlC7aCUJ/4DqHcZy0KMMWyjNML/w51xDzctSKil2I5ywKVYhHa rWrarnNl7C9aJmRw9zjHdEUC6MZRjx0+jqpZIe2kTA0cXGM/LuOiQ0yzUx4bDR0RHkG7 jcdWSGR1TyUfHco9MohWWaSdEd0flqHAkTUSYDh9DUBjrvn5+PBiWZuxsXfQc/FOvH34 /WK9iPVUT25auvSqWVIdJNhhhse6chVtco5BdhUNwFOseffYUI9EBxhpF4KGweJ4AjMp dX0umZsJQpCpugji4qFDzMbRNk2gQlBjB9yTG6gnAbbvR2ttCfBtP75/b04gPGo1za2g eewA== 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=hp6UlvJEo2zF9YT7e1crSNAEMXNIZp6kLMpZ9uCwxqs=; b=uUOds2S+nI8k3vsIU+immOkWOd31kY7bW61R99zXv4S5CGbCZk3gmuJ5MHEWTrpToz OBq5P6RBn5zZkUJ/oXLZcqMvx3v/iC+adF0Q4XRSxPgZjH/r8hQJV0SxNLJvwo5tbZti sOncQr5P2THd7nWFPp3BujDrLj9KpD2kOKd04LnFLgtQC1VxUrxpdg+KpFvfkI4fuEPe VKWUVCQ8aFaoxQbOeYywd141DRaEcfKmNIx2ogZG8q3v8Xd6SRe1TjvYiOn3N8Auegga n6JgYXVF6m7tzWf3KWwL95N+DPXnKPKrNsK5cfp2an2EKGddXx/LAJz30o1+QOP54TGD 0DKQ== X-Gm-Message-State: APjAAAU3QUrm9cL2pT/JM5uzUgQjTnXfaxwcjv/8s38A5xT+8jUKZyWZ OfK3QQzJWx4GXJKRx41kfGOTsSGY0dcW02WcGYg= X-Google-Smtp-Source: APXvYqxETze+DCuEAwc8KYujkVbcbYUwv7jIyFBb5wf6H8gDO4wSMSR+4KWwsk6Te5cvSNJlRDMe/ic3gbbY4KnY8Ho= X-Received: by 2002:a02:ce52:: with SMTP id y18mr27596041jar.78.1562687034325; Tue, 09 Jul 2019 08:43:54 -0700 (PDT) In-Reply-To: <81716eae-14f1-a427-b6e0-46e861adc93a@yandex.ru> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d36 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:238457 Archived-At: --000000000000938227058d416dd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 9, 2019 at 4:19 PM Dmitry Gutov wrote: > Since the "correct" behavior is a matter of interpretation here, who > broke what is a matter of interpretation. And I'm sure you can agree > that "you broke XXX" can be interpreted emotionally. Anything can (and everything is). That's the nature of being an animal and not a machine. So what word/phrasing would you suggest when you need to unequivocally state that "the actions (of individual A) led to the loss of a previously verified behaviour X, desired by individual B, such that both A and B now agree that X is desirable and A is working to make X work again"? I don't repeat this gratuitously: I am using it to make an argument against a feature, listing it in the "cons" part. Other people are stating facts that they add to the "pros". > To get back to Clement's question (and maybe I'm just restating your > opinion here), I think: > > * Fontifying "broken" strings only until EOL might be beneficial, at > least in certain languages, where it's consistent with the syntax. The > result will be less "blinking". Depends on how you edit. If the most common case is that you, for example, C-k kill-line a closing " at EOL away, then yes, you're right. If the most common case is that you RET newline at the middle of a string then no, you're wrong. Both can be accidents/mistakes or deliberate actions. But let's say they are accidents. Which one is more common? For me it's the RET thing, after which I usually C-M-u C-M-SPC to fix the situation. So I would experience _more_ blinking (along with all the other disadvantages). Consistency with how the compiler views invalid code is not very important for me, because every view allows me to spot the error unequivocally (also the compiler probably doesn't care about this because the compiler doesn't edit code or fontify it). > * It doesn't seem trivial to implement without breaking a lot of > pair-matching and quote-matching functionality, because both font-lock > and the latter features depend on parse status, and buffer can be > fontified in chunks, etc. I would agree fully here. Jo=C3=A3o --000000000000938227058d416dd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2019 at 4:19 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> Since= the "correct" behavior is a matter of interpretation here, who> broke what is a matter of interpretation. And I'm sure you can a= gree
> that "you broke XXX" can be interpreted emotion= ally.

Anything can (and everything is). That's= the nature of being an animal
and not a machine.
<= br>
So what word/phrasing would you suggest when you need to
unequivocally state that "the actions (of individual A) led to= the loss of
a previously verified behaviour X, desired by indivi= dual B, such that both
A and B now agree that X is desirable= and A is working to
make X work again"?

=
I don't repeat this gratuitously: I am using it to make an a= rgument
against a feature, listing it in the "cons" par= t. Other people are
stating facts that they add to the "= ;pros".

> To get back to Clement's ques= tion (and maybe I'm just restating your
> opinion here), I think:=
>
> * Fontifying "broken" strings only until EOL mig= ht be beneficial, at
> least in certain languages, where it's con= sistent with the syntax. The
> result will be less "blinkin= g".

Depends on how you edit. If the most comm= on case is that
you, for example, C-k kill-line a closing " = at EOL away, then yes, you're
right. If the most common = case is that you RET newline at the middle
of a string then = no, you're wrong. Both can be accidents/mistakes
or deli= berate actions. But let's say they are accidents. Which
= one is more common? For me it's the RET thing, after which I
=
usually C-M-u C-M-SPC to fix the situation. So I would experience
=
_more_ blinking (along with all the other disadvantages).
<= div>
Consistency with how the compiler views invalid code is = not very
important for me, because every view allows me to s= pot the error
unequivocally (also the compiler probably does= n't care about
this because the compiler doesn't edi= t code or fontify it).

> * It doesn't seem trivial to i= mplement without breaking a lot of
> pair-matching and quote-matching= functionality, because both font-lock
> and the latter features depe= nd on parse status, and buffer can be
> fontified in chunks, etc= .

I would agree fully here.

Jo=C3=A3o
--000000000000938227058d416dd5--