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: Mon, 18 Jun 2018 18:01:18 +0100 Message-ID: References: <20180531123747.GA24752@ACM> <20180617201351.GA4580@ACM> <20180618103654.GA9771@ACM> <20180618154227.GB3973@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 1529342597 17703 195.159.176.226 (18 Jun 2018 17:23:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 18 Jun 2018 17:23:17 +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 Mon Jun 18 19:23:12 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 1fUxry-0004U0-4O for ged-emacs-devel@m.gmane.org; Mon, 18 Jun 2018 19:23:10 +0200 Original-Received: from localhost ([::1]:36176 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUxu5-0000R6-9W for ged-emacs-devel@m.gmane.org; Mon, 18 Jun 2018 13:25:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUxX1-0000Ub-9s for emacs-devel@gnu.org; Mon, 18 Jun 2018 13:01:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUxWu-0007am-Rw for emacs-devel@gnu.org; Mon, 18 Jun 2018 13:01:31 -0400 Original-Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:40197) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fUxWu-0007Zz-GF; Mon, 18 Jun 2018 13:01:24 -0400 Original-Received: by mail-wm0-x229.google.com with SMTP id n5-v6so16908448wmc.5; Mon, 18 Jun 2018 10:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=QzGiVvJO4Pun81zZI4IEkDAEsZEPbR3vUWf2DccGcAQ=; b=aA4FMemYzRCWM/gWm1la0vLZ14OZ0Yd/gCScKnHGcrBFyL9C4/Fa2TGUbkRq/Xiu8X H5D+821NZvfCv4RHLqNgvCu6NrO+KhwoE4oeg9JhDHQtplyuf2HsxTM19b+b28E6KMTf 5wzHBYZds0FBzNPlVvTx5EqjeSY2AsJTxkCz31KPnnOqCpb5BQjzkmbkIBlJHyjABmh+ uKCRqeECfVoWLppkoIOrYHYaf/4IK9cDWFrL7QgfLEsm2NiCL4YCSbp55AOiZYh1QiRf S5gKXPjUBMrUSRgnKuoDMvnoYs811B5eIbCz00/d+Uuv3buaok056BdOzzrHhf1lPyhR Rw5A== 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:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=QzGiVvJO4Pun81zZI4IEkDAEsZEPbR3vUWf2DccGcAQ=; b=C8sh0l6hy4KEd9DZO7TNQzE5WFDw2RBqXeQfnKfTNMud2HP8TsgHHk42gYi2DDx9Mi FbdlR0okSp4bDK4HqAXRUA8Mcax8SDUu+VOQAjXpI22RjgwDqDOH1JNreN/3G+2Zf8YM pVBjmW0UILJf8hE1jxRtyJNGwHnISaw6WideXO9wE1D/sWfjC5hSrut3bjgZxqsXduOn J3t2ZQXTx81zUv7bT/RsZ/6IOEpE1H4VtDMHfnZCOEJaBmzG42mXPlGl181Cti2/eWCG 2XBqb3Z5JBJk4hrnTZEYdg8iPvMark3ktRhGaFlEeOqeyliYlYEb3QMiBoAK165xkEGm qaTQ== X-Gm-Message-State: APt69E23hx7lLwBwWUKVdiX+vvrIMUFz/4uq1nplJZulCUbpYFEr8RxA 5hrDpSOCoMyxNhTr0wKsf2XSyraUE4A= X-Google-Smtp-Source: ADUXVKJxT0RJHuQhY4+RrnJx/mB7h+S4hAYFAm/wo2qG3onNhYc3M2js5KKAe0g0WL8tvYvKzuILrA== X-Received: by 2002:a1c:f014:: with SMTP id a20-v6mr8638173wmb.97.1529341282760; Mon, 18 Jun 2018 10:01:22 -0700 (PDT) Original-Received: from kitaj.yourcompany.com (44.191.54.77.rev.vodafone.pt. [77.54.191.44]) by smtp.gmail.com with ESMTPSA id d5-v6sm18360966wrp.64.2018.06.18.10.01.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 18 Jun 2018 10:01:21 -0700 (PDT) In-Reply-To: <20180618154227.GB3973@ACM> (Alan Mackenzie's message of "Mon, 18 Jun 2018 15:42:27 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::229 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:226467 Archived-At: Alan Mackenzie writes: >> For development temporarily unhampered by tests, I think a separate >> branch is a much better alternative. It's a very easy thing to do in >> git (and in your case, trivial to merge from and back to master, given >> you have near-total control over that area of code). > > It's possible, but it's a hassle; it's outside of normal workflow, > therefore involves getting into git's execrable documentation. hehe. lol. OK, but really you should checkout out branches, they're all the rage these days :-) >> > OK, here goes. Why should major modes tie themselves in knots, just so >> > that electric-pair-mode can work? What CC Mode is doing is natural, a= nd >> > matches the reality. > >> I think you mean "mode", in the singular form :-). > > No. CC Mode comprises lots of modes, not all of them maintained by me. > But even aside from that, CC Mode has often been a pioneer, developing > new techniques, which the rest of Emacs has then followed. Examples are > hungry deletion and electric indentation. But they are all children of cc-mode.el right? I meant singular as in, afaik, nobody else independently thought of doing that besides you. >> Also, it doesn't "match reality": if you open a line in a string, it >> syntax highlights the remaining string as C statements, but the C parser >> doesn't see C statements. IOW, newline doesn't *really* terminate a >> string in C. > > 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. >> > electric-pair-mode's chomp facility could be more rigorously coded - >> > sometimes it is dealing with visible whitespace, sometimes it is deali= ng >> > with syntactic properties. Surely it should be working with visible >> > whitespace all the time? > >> No. If it did so, it would chomp parenthesis from non-comment regions >> into comment regions, for example. > But it could use the strategy of determining the end of any comment, > then using non-syntax facilities for traversing the space up to that > end. Or something like that. I'll look into "something like that". > 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. >> * Also inside the string, `blink-matching-paren', on by default, also >> doesn't work as before: closing a paren on a NL-started string doesn't >> match the opener. > > Do you mean a NL-ENDED string? I see matching here. If you can be more > precise about the failure, I can look at it. No, I mean the closer. You and the mode don't consider that a string anymore, but you used to, and I still want do. >> There are no automated tests for these things, otherwise you could be >> seeing test breakage here too (and, with higher probably, you may be >> seeing breakage in user's expectations later on). > No, these things are not all intended functionality of Emacs, they're > just side effects of the way the real functionality was implemented. 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. >> > electric-pair--skip-whitespace, I encountered a scan-sexps in subfunct= ion >> > ended-prematurely-fn of function electric-pair--balance-info, which >> > snagged on the end of string at EOL. >> I don't understand how this matters to the problem at hand, but >> regardless, can you make a bug report demonstrating the presumed bug and >> its impact so I can follow up? > I attempted to see how difficult it would be to modify elec-pair.el to > cope with unconstrained text properties in buffers. This was the second > problem I came up against. 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. >> > We are talking about a corner case in e-p-m, namely where e-p-m attemp= ts >> > to chomp space between parens inside an invalid string. This surely >> > won't come up in practice very much. Is it worth fixing? (I would say >> > yes.) >> Don't forget that the particular piece of e-p-m we're talking about is >> one of the ways (arguably the easiest way) to actually fix the specific >> C/C++ problem at hand for the user. IOW it's not some random whimsical >> useless thing. > It's not useless, but it's rare - it's three things happening all at the > same time, namely a broken string, pseudo-matching parens and space > between them. This isn't going to happen very often. I'd wager that > broken strings (two "s with non-escaped NLs between them) in themselves > are quite rare. But I still think it should be fixed. :-) Well, it's handling the rarities that makes Emacs stand out. >> > The user is visually informed of the reality: that one or more >> > strings are unterminated, and where the "breakage" is (where the >> > font-lock-string-face stops). This is an improvement over the >> > previous handling, where the opening invalid " merely got >> > warning-face, but the following unterminated string flowed on >> > indefinitely. > >> I suppose that's a "yes". In that case, the face `warning`, which >> defaults to a very bright red, would be fine for me personally (and I'm >> confident if could be made even more evident). Also, the fact that the >> remaining string is now syntax-highlighted as C statements is extremely >> confusing. > > Why? They are now C statements, and would be handled by the compiler as > such. Clarify "would". Because this doesn't compile. My compiler doesn't even seem to look at anything after the unterminated string: =20=20=20=20 int main () { printf("foo );=20 printf("bar"); return 0; } >> > The disadvantage is that e-p-m is constraining major modes in how they >> > can use syntax-table text properties. I think this is a problem in >> > electric-pair-mode, not in CC Mode. > >> Again, AFAIK, "mode", singular. > > See above. Perhaps it's worth noting that AWK-Mode has used this method > of indicating invalid strings for around 15 years, now. There have > never been any complaints about this from users. But they weren't ever exposed to the previous behaviour, right? And also, I believe that there is some discrepancy between the number users of AWK and C, the complexity of the average program, etc... >> But now that I've understood the non-e-p-m implications of your change, >> I urge to at least make this configurable (if it is already >> configurable, then don't mind me). > Make correct fontification configurable? For some newfound value of "correct", surely... > There remains the problem of making chomping parens inside a broken > string work. I honestly think that modifying elec-pair.el is the way to > go, but I'm open to suggestions of alternative strategies that CC Mode > could follow to get the same fontification, that wouldn't require > modifying elec-pair.el. As I said, I will look into providing an entry point in elec-pair.el for this. Didn't you mention earlier pike-mode and d-mode? Quoting your earlier message: > Pike Mode has a special feature whereby a string starting with #" > is a multiline string. I think in D Mode (not maintained here), > strings simply are multiline, and there is no such thing as an > escaped EOL. > The writer of the mode sets the CC Mode "language variable" > c-multiline-string-start-char to the character # for Pike Mode, or > some non-character non-nil value for D Mode (usually t, of > course). Can't I do this to my c/c++ mode? Would't this be a way to get the old behaviour back. Perhaps it could be be let-bound in tests, also. Jo=C3=A3o