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: Wed, 10 Jul 2019 10:32:42 +0000 Message-ID: <20190710103242.GB4109@ACM> References: <20190708100539.GD4529@ACM> <20190708164501.GB5244@ACM> <20190708180551.GD5244@ACM> <20190709160022.GC5230@ACM> <20190709182646.GD5230@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="82373"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Stefan Monnier , emacs-devel To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 10 12:33: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 1hl9v2-000LHM-IO for ged-emacs-devel@m.gmane.org; Wed, 10 Jul 2019 12:33:48 +0200 Original-Received: from localhost ([::1]:59842 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hl9uw-00077Q-Fo for ged-emacs-devel@m.gmane.org; Wed, 10 Jul 2019 06:33:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44678) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hl9uB-00076Q-3i for emacs-devel@gnu.org; Wed, 10 Jul 2019 06:33:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hl9u8-0007T2-Sh for emacs-devel@gnu.org; Wed, 10 Jul 2019 06:32:54 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:43393 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hl9u7-0007Pf-1y for emacs-devel@gnu.org; Wed, 10 Jul 2019 06:32:52 -0400 Original-Received: (qmail 88778 invoked by uid 3782); 10 Jul 2019 10:32:44 -0000 Original-Received: from acm.muc.de (p4FE15E52.dip0.t-ipconnect.de [79.225.94.82]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 10 Jul 2019 12:32:42 +0200 Original-Received: (qmail 4996 invoked by uid 1000); 10 Jul 2019 10:32:42 -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:238495 Archived-At: Hello, Joćo. On Tue, Jul 09, 2019 at 19:53:17 +0100, Joćo Tįvora 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 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. 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. > 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. 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. > 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. 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. > 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. However, there is the possibility of improving the handling of multi-line strings in CC Mode, most notably by modifying c-context-line-break automatically to insert backslashes, and making M-q handle backslashes properly (which it doesn't do at the moment). > 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. > 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. What I think the real issue here is that it is difficult to adapt other major modes to follow CC Mode's lead, since they are too tightly constrained by the syntax-propertize-function/syntax-ppss mechanisms. > Joćo -- Alan Mackenzie (Nuremberg, Germany).