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 14:03:17 +0000 Message-ID: <20190710140317.GC4109@ACM> References: <20190708164501.GB5244@ACM> <20190708180551.GD5244@ACM> <20190709160022.GC5230@ACM> <20190709182646.GD5230@ACM> <20190710103242.GB4109@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="156708"; 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 16:04:20 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 1hlDCk-000eYY-Ie for ged-emacs-devel@m.gmane.org; Wed, 10 Jul 2019 16:04:18 +0200 Original-Received: from localhost ([::1]:33274 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlDCj-00060M-CP for ged-emacs-devel@m.gmane.org; Wed, 10 Jul 2019 10:04:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34810) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlDC7-0005zg-Lr for emacs-devel@gnu.org; Wed, 10 Jul 2019 10:03:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hlDC2-0008PM-7g for emacs-devel@gnu.org; Wed, 10 Jul 2019 10:03:37 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:46179 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hlDBv-0008Jq-75 for emacs-devel@gnu.org; Wed, 10 Jul 2019 10:03:32 -0400 Original-Received: (qmail 68473 invoked by uid 3782); 10 Jul 2019 14:03:18 -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 16:03:17 +0200 Original-Received: (qmail 26501 invoked by uid 1000); 10 Jul 2019 14:03:17 -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:238501 Archived-At: Hello, Joćo. On Wed, Jul 10, 2019 at 13:10:45 +0100, Joćo Tįvora wrote: > On Wed, Jul 10, 2019 at 11:32 AM Alan Mackenzie wrote: > > 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. > You misunderstood me. What I said "just doens't happen" is "fontify > arbitrarily large pieces". OK. Sorry about that. > > 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. I'll believe you, though I don't know what you mean by smartparens. > 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. Or are we talking about fixing long standing breakage they've had to tolerate? At least two people on this list have said they welcome the CC Mode style of fontification of invalid strings. > > > 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. Neither CC Mode nor I guess. "We" both use a definition of "string" that obviates guessing. (See next paragraph.) > > 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 > after the error, so long as it hightlights the error in the correct > line. What's that got to do with it? If you don't like CC Mode's definition of a string, propose an alternative here, a non-vague alternative, and we can discuss it. > > > 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 Yes. There were bugs in the interface between CC Mode and electric-pair-mode, and half of us had to sort these out. It's a good job that one of us was able to step up, and diagnose and fix this. As for 2, what you want there, as I keep saying, is bogus. You want to treat two syntactically disjoint "s as though they enclosed a string. Although this is bogus, I have some sympathy with people who want to do this, on the grounds that it "worked" in the past. But it is fundamentally bogus. > 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". Must you be like that? That patch is not "likely buggy", any more than any other patch. There is one particular bug in it, a very obscure situation, where a raw string's identifier which contains "s gets confused with another raw string when the defining delimiters are damaged in a particular fashion. Not something you're liable to stumble over, but my integrity prevents me from representing the patch as bug free. It will be getting fixed nevertheless. As you acknowleged in another post, that patch took some hours to write. Would you please, as the person clamouring for it, try it out now and give me appropriate feedback. I would rather get that feedback before committing it to savannah than afterwards. > > > 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? Yes. > Only one of them is are totally wrong for you. Is that it, the thursday > thing? Sorry, I can't parse that. > 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? I don't know. With having the correct highlighting in CC Mode, invalid strings get corrected before being submitted to the compiler. ;-) > > > 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? It doesn't, at least without an awful lot of effort, fontify an invalid string in the correct CC Mode fashion. It would leave an arbitrary amount of text after the end of an invalid string fontified with string-face. > - What are the drawbacks of my flymake-based soluion? It's not part of CC Mode. It would involve loading another package, and likely would be slower than CC Mode's fontification. It would not be well integrated with CC Mode, and would possibly need a lot of work to make it work properly. > Joćo -- Alan Mackenzie (Nuremberg, Germany).