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 14:24:39 +0100 Message-ID: References: <20180531123747.GA24752@ACM> <20180617201351.GA4580@ACM> <20180618103654.GA9771@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 1529328225 23159 195.159.176.226 (18 Jun 2018 13:23:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 18 Jun 2018 13:23:45 +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 15:23:40 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 1fUu89-0005pc-GO for ged-emacs-devel@m.gmane.org; Mon, 18 Jun 2018 15:23:37 +0200 Original-Received: from localhost ([::1]:34783 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUuAF-00051d-4C for ged-emacs-devel@m.gmane.org; Mon, 18 Jun 2018 09:25:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55974) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUu9W-00051Q-Lh for emacs-devel@gnu.org; Mon, 18 Jun 2018 09:25:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUu9T-0005CS-Ca for emacs-devel@gnu.org; Mon, 18 Jun 2018 09:25:02 -0400 Original-Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]:53039) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fUu9T-0005BN-0q; Mon, 18 Jun 2018 09:24:59 -0400 Original-Received: by mail-wm0-x235.google.com with SMTP id p126-v6so14089612wmb.2; Mon, 18 Jun 2018 06:24:58 -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=RpEPn6tBG5DDK4KN7ddClScsOsf1jZSnLkkUzPY/3go=; b=bLL7UEdq4fBjv+XUG2Aoa3qR9pG9lC4rODEtTQIpgyVIwanoeGvsDmxHJxsj5k1VG1 2lVIAaIpsQhEl9oH9nn8iKKhWspybAXy3WkTeYpuwEhrrB85R0ryN3KXZzDEyXOh31dp i1lJxMDOea17zSnAtbNV3SKfjKsu3kiEKFYSfG/jtInswd2EpB+gDgBQIu0hRH4V+a+E dCfIQUabSfXqrCXPEiUsqpAwWZi8OeFD5i3RoBbFEoTtRddTbb4Rm5A6wuTVDud8Xp4W OXM4894cwhys0ELP+4ycxKfbQ1yU5ylE8h4pScEPLfFaHePahvpuS2fK1Y/jZTnvniEj HKBg== 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=RpEPn6tBG5DDK4KN7ddClScsOsf1jZSnLkkUzPY/3go=; b=uYmfXx14j2OEpvLQ00s1mHvDEtJkZIjlAMbp9a6DuumZMMC9nyJ19KykWfAH87+84o kahdJbt67ocDAmdK4VRGb6oAjJCo3NPp4NAZ3COCBvJPO0pHDAKACHerefIB5yArhkNy 0hukXO0dtmjh7GdP+ZiqegXOlks3pwYgXzu4hKA6RtSiuOgUQ4aA9fkfVWKtY8cvubAv Aor6mikP0R8yqDIfBCJgjOHZG4xrXuYOOnp06CbjavY4ex9fRm78UGhHcPjfT6vnWCtv 7OyUB0P9yLE4DRxKYkq0/SK1Tv5jdX+JtmYwHLt+CJBRGEAKOiq65PHl9ouKwPsLVRo2 bj3A== X-Gm-Message-State: APt69E3vPyk6tzhNXlJe1GLIITWEEAXE79HQ8HuHFoS3pgKLConN5d15 /mPdPKJAayBPbT+gXxHbTmj2X1f3 X-Google-Smtp-Source: ADUXVKJtsry6HO9jlQsTCE1ZNr2tNUFyrzEGm5gIaxzb6wJGB0xmS7/apFxtdfdnO6WzreLszpj19g== X-Received: by 2002:a1c:ee5d:: with SMTP id m90-v6mr8772155wmh.113.1529328297393; Mon, 18 Jun 2018 06:24:57 -0700 (PDT) Original-Received: from kitaj.yourcompany.com (50.55.43.5.rev.vodafone.pt. [5.43.55.50]) by smtp.gmail.com with ESMTPSA id z5-v6sm12540798wrh.10.2018.06.18.06.24.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 18 Jun 2018 06:24:55 -0700 (PDT) In-Reply-To: <20180618103654.GA9771@ACM> (Alan Mackenzie's message of "Mon, 18 Jun 2018 10:36:54 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::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:226451 Archived-At: Alan Mackenzie writes: > Hello, Jo=C3=A3o. >> Yes, while mulling over things is generally good, I believe the problem >> from Glenn's perspective is the nuisance of checking whether every >> test failure is something to worry about or just the thing being >> mulled over. > Yes. But it is the master branch, where not everything can be expected > to work all the time. I think the main thing is, we're _going_ to fix > this bug. Well, I respectfully and totally disagree. The reason we have automated tests in Hydra is to catch unintentional breakage, not intentional breakage. And, IIUC that test is the only one preventing a successful "make check". 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). > Hmm. To modify CC Mode temporarily to make 'chomp in electric-pair-mode > work would be an order of magnitude more work than "simply" to fix the > bug. That's without disabling the handling of " in CC Mode entirely. How so? Can't you just revert the commit that broke it?=20 >> strings are worth it. Perhaps there are indeed benefits, it's just that >> I haven't seen them argued. > 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, and > matches the reality. I think you mean "mode", in the singular form :-). 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. > electric-pair-mode's chomp facility could be more rigorously coded - > sometimes it is dealing with visible whitespace, sometimes it is dealing > 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. That doesn't make sense, not according to show-paren-mode, for example. By the way, after your change, very basic commands which fall completely outside electric-pair-mode have fundamentally changed their behaviour in cc-mode. Here are a few, out of Emacs -Q: * Open a line in a string, using C-o. Sexp-navigation is now messed up in the whole buffer, i.e. C-M-*. Most commads error or produce surprising result. So even if the intent is to eventually add a backslash escaping the newline, or make it two adjacent strings by typing two quotes (something perfectly allowed by C). * Inside the string, `forward-sexp' in a parenthesis of a NL-terminated string now errors where it would previously do its job of jumping to the closer; * 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. 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). > I've attempted a bit of debugging. In addition to > electric-pair--skip-whitespace, I encountered a scan-sexps in subfunction > 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? > We are talking about a corner case in e-p-m, namely where e-p-m attempts > 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. >> So, in practice, is the advantage here that the user is visually >> warned of an invalid NL-terminated string? > 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. > 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. And, obviously, I'm not going to special-case cc-mode in elec-pair.el: after doing some of my own mulling, I may open a customization point for cc-mode.el to use. So at the very least, it's going to require some (potentially trivial) fix in cc-mode.el, for sure. 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). Jo=C3=A3o