From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie 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:00:22 +0000 Message-ID: <20190709160022.GC5230@ACM> References: <20190704165846.GF5564@ACM> <20190704190100.GG5564@ACM> <20190708100539.GD4529@ACM> <20190708164501.GB5244@ACM> <20190708180551.GD5244@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="231946"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 09 18:14:24 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 1hksl4-000y9O-E0 for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 18:14:22 +0200 Original-Received: from localhost ([::1]:51476 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hksbU-00085j-7W for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 12:04:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53643) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hksXi-0006GI-8q for emacs-devel@gnu.org; Tue, 09 Jul 2019 12:00:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hksXg-0006Xj-Qv for emacs-devel@gnu.org; Tue, 09 Jul 2019 12:00:34 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:41375 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hksXe-0006Pv-Qc for emacs-devel@gnu.org; Tue, 09 Jul 2019 12:00:32 -0400 Original-Received: (qmail 14665 invoked by uid 3782); 9 Jul 2019 16:00:24 -0000 Original-Received: from acm.muc.de (p4FE15DA9.dip0.t-ipconnect.de [79.225.93.169]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 09 Jul 2019 18:00:22 +0200 Original-Received: (qmail 7694 invoked by uid 1000); 9 Jul 2019 16:00:22 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:238461 Archived-At: Hello, Stefan. On Mon, Jul 08, 2019 at 16:59:31 -0400, Stefan Monnier wrote: > >> > Don't knock it - it's working, and will give Joćo what he wants whilst > >> > preserving correct fontification. > >> Several people have already pointed out that what you call here "correct > >> fontification" is "incorrect" in the cases where the error is a missing > >> \ rather than a missing ". > > "Several people" is just one that I have seen, and he is wrong. > Joćo gave you actual examples where fontifying the second line as > a code rather than string was an error. So we're at least 2. > > Whether the error "is" a missing \ or a missing " (for whatever > > value of "is"), the purpose of the fontification is to draw > > attention to this error. This error is at the EOL where there is a > > missing " or \. In that sense CC Mode's fontification of it is > > correct. > Maybe we're not talking about the same thing: We most assuredly are. And you still haven't read my post from Date: Thu, 4 Jul 2019 16:42:33 +0000, which dealt in full with your next three paragraphs. Please go and read that post now, and either assent to its compelling logic or take issue with it in detail. > The addition of some kind of error/warning face on this line is indeed > always correct and is something that can easily be done without any > need to fiddle with syntax-table text properties. I'm definitely not > arguing against this highlighting of the immediate error. > But I'm talking about is the highlighting of the subsequent line(s). > You seem to want them to be highlighted as if the next line was not part > of a string (i.e. assume that a " was missing on the previous line), > whereas all other major modes highlight that second line under the > assumption that what was missing was a final \ on the previous line (or > whatever other syntax the corresponding language requires). > Both are wrong sometimes and right at other times. 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. It is not up to the major mode to second guess the user. It is the major mode's job to indicate the presence and position of an error as clearly as possible. CC Mode's fontification does this. Many other modes don't. [ .... ] > Stefan -- Alan Mackenzie (Nuremberg, Germany).