From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: CC Mode and electric-pair "problem". Date: Tue, 19 Jun 2018 00:43:05 +0100 Message-ID: References: <20180531123747.GA24752@ACM> <20180617201351.GA4580@ACM> <20180618103654.GA9771@ACM> <20180618154227.GB3973@ACM> <20180618180846.GC3973@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1529365288 9118 195.159.176.226 (18 Jun 2018 23:41:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 18 Jun 2018 23:41:28 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (darwin) Cc: Glenn Morris , Emacs developers , Tino Calancha To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 19 01:41:24 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fV3lz-0002Fh-T1 for ged-emacs-devel@m.gmane.org; Tue, 19 Jun 2018 01:41:24 +0200 Original-Received: from localhost ([::1]:37288 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fV3o5-0005wt-AU for ged-emacs-devel@m.gmane.org; Mon, 18 Jun 2018 19:43:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45261) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fV3nr-0005uq-Ss for emacs-devel@gnu.org; Mon, 18 Jun 2018 19:43:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fV3nj-0001fj-Cq for emacs-devel@gnu.org; Mon, 18 Jun 2018 19:43:19 -0400 Original-Received: from mail-wr0-x235.google.com ([2a00:1450:400c:c0c::235]:33458) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fV3ni-0001dg-V5; Mon, 18 Jun 2018 19:43:11 -0400 Original-Received: by mail-wr0-x235.google.com with SMTP id k16-v6so18562223wro.0; Mon, 18 Jun 2018 16:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=JIKDS6f0WDmwPE++qKS3hKbx9pVO5uZw0sWIcvl6Hz0=; b=DVCIPabg7NzsJ4ggZJqHRdvr+/1TYCBPliOsPbKWyTARsm9eNX+6iaNbS/Gpdex+7A A6C6IP8AFE4lLzEW9o/eEbDxbxSrH6VzLhbsWsxrm2w1D6rakTI0eDP2HuqtEiOY854O CiJTbeBM1w8S2aByxwZL/u+3FdxFV66T5y1pQDbd8N11KMj1PovwLoEz1L5otYCTxRyl v9Nl0J1ji+QRmGRRydfJI0nTw5Jk0QpaYaVPbpJ3WGAoIpeeKY4SdVCnplp0ix5FawDN 2l7q3sE2EKS2gPiesDc2KTlAuroLugOY39xtKnX3QBsykZYiOFx8p8tycFUhN5lv9tFH hPCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-transfer-encoding; bh=JIKDS6f0WDmwPE++qKS3hKbx9pVO5uZw0sWIcvl6Hz0=; b=DC/DA22rMxShO1VD8TCqFGGDLgqg+BgqEziNUUj84AtRhlC10mND55N0EM7+q+6zVl MeTq0iMWDVJL8QQt7hwNGi+6psVGP0XtukTwWP+j6GdSKscwI4neqguP6ACiPSh7ljuz byB/ev/1yLMykLZHX54I1nk1mNZZ6WPIAvwBG8LTOdzByAWGMIieRc/5bTFUyhNvqjD6 sgW/WkymNL7+BYXlV+YdgvBx4aRd+ihWCx2qI6x5iEmxT5dkB04obtp/bQXt6/wcc2au lVPqOmgBRou4vNTZkveUDJ57Lb8YB1b3KdGKfZ9zJNnTFKG6evlncRSWlpoAvIH0TRFa hVmw== X-Gm-Message-State: APt69E3EYEi2HXERbi0dOV9C7XFbzekGZJOS/dealnoMrTnLWrqCjNv8 +E2BT6CuKS+O9VQtu/MCexxfOXGQEmI= X-Google-Smtp-Source: ADUXVKI1jCuDCtjcj6BsklF6+F2ouG9Tzn0J9CHk5g/UIWDw3+oCO2G5oCr2Ohe02Z1E1Z/bvvrlzg== X-Received: by 2002:adf:ec4d:: with SMTP id w13-v6mr11595108wrn.222.1529365389357; Mon, 18 Jun 2018 16:43:09 -0700 (PDT) Original-Received: from kitaj.yourcompany.com (178.110.103.87.rev.vodafone.pt. [87.103.110.178]) by smtp.gmail.com with ESMTPSA id v129-v6sm10365330wme.26.2018.06.18.16.43.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 18 Jun 2018 16:43:08 -0700 (PDT) In-Reply-To: <20180618180846.GC3973@ACM> (Alan Mackenzie's message of "Mon, 18 Jun 2018 18:08:46 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c0c::235 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:226478 Archived-At: Alan Mackenzie writes: > Hello again, Jo=C3=A3o. Hello again, Alan > On Mon, Jun 18, 2018 at 18:01:18 +0100, Jo=C3=A3o T=C3=A1vora wrote: > Probably other people have thought of it. The actual doing was quite > involved. But maybe we'll see whether or not the idea spreads. > >> > We could argue about words like "terminate" indefinitely. What I >> > think is incontrovertible is if you open a line in a string, the >> > portion after that opening is not part of the string opened on the >> > line above. The new fontification reflects this fact. > >> OK, but now reflects it reflects something that is also wrong (they're >> not statements either), but to a much greater degress. And on top of >> that with many more adverse side effects, of which only one is breaking >> e-p-m mode. > > How adverse are they really? I mean, I think you are currently in the > "looking for flaws" mode, which is essential, worthwhile, and > appreciated, but if you were just using, say, C++ mode, how bad would > these side effects actually be? That's not a rhetorical question. It's > about deciding whether to invest the work to make the "correct" behaviour > optional. Honestly, I don't know. You're right I am indeed in "looking for flaws" mode. "Once you see it, you can't unsee it". After reading your example below, I think the feature you are adding is good for people who inadvertently delete the terminating quote, but not for those who once in a while add a newline inside a string. I am in the latter group: I almost never unbalance by buffer (thanks mostly to e-p-m) and I like to navigate by sexp, even in languages other than lisp (even in message-mode, for instance). So I get sad when something breaks this balance. >> > I've tried this, obviously, but as far as I'm aware, the operation of >> > C-M-* is correct for the (now syntactically incorrect) buffer. If you >> > can give me a concrete example, I can look at it and correct it. > >> It's now much hard to select the whole invalid string. It used to be a >> matter of C-M-u C-M-SPC. To use query-replace in the region, for >> example. > > OK, thanks. But how often does this happen? Well, there's obvious the case of actually writing a multi-line string, such as when writing a "usage:" blurb. Here I believe most users, like I, will first draft out the string visually and then add "\n\" to every line, perhaps by selecting the string where point is in, which is now much harder. While it's true I don't write many of those lately, it will probably bug me much more often in another situation: I'm in the the habit of C-o'ing a lot (everywhere, not just in strings, obviously) to "open space" for my thoughts, i.e. for the thing I am going to write next. And this new behaviour breaks that. But now I've tested a bit more and can be specific: it breaks *some* of that. C-M-u C-M-SPC is indeed broken. That's what I use, for example, just before I deciding to replace the string with a variable. But curiously, chomping to the end quote is working, which is nice. And if I can somehow make it to the closer quote, C-M-b works, though C-M-f at the opener doesn't. In any case, things were more predictable before. >> These accidents, as you have them, work just fine in just about any >> other mode I can imagine. And they worked just fine in c-mode up until >> your change. > I suspect it is more that people have got so used to them, that any > change will appear to be bad. Maybe. As we all know, Emacs is fertile in this regard. For example, I can think of a certain version control system, rhymes with "knit"... >> Well, programming is a continuous problem in general. If I understand >> correctly, the thing you're trying to change is an implementation detail >> of electric-pair-mode, not part of its contract, right? If, on the >> contrary, you think it is a bug, let me know. > It is what I said at the end of my previous post. e-p-m assumes that > whitespace has "neutral" syntax. When it doesn't (like here, with a > string-fence property), the scan-sexps doesn't work as desired. I'm > convinced this could be changed. OK. I'll have a look (I admit to not having looked at that code in depth since I wrote it 5 years ago). I was pretty much convinced it was flawless :-) >> Well, it's handling the rarities that makes Emacs stand out. > Indeed! Let's carry on doing this. >> int main () { >> printf("foo >> );=20 >> printf("bar"); >> return 0; >> } > > Maybe the compiler has the same bug as the old CC Mode. ;-) No, I passed it a silly example. It does indeed look past the unterminated string. > But to see my point of view, type the following into a C Mode buffer in > Emacs-26.1, the last two lines first, then type in the first line above > them: > > char *foo =3D "foo; > int bar =3D 5; > char *baz =3D "baz"; > > face. We've been used to this for so long that we've lost sight of just > how bad and amateurish it really is. > > Now do the same in master. The fontification of the last two lines > remains unaffected by typing in the first line, as it should. Indeed, I admit this is better. I very rarely get a buffer like this, though. Jo=C3=A3o