From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: CC Mode and electric-pair "problem". Date: Mon, 18 Jun 2018 10:36:54 +0000 Message-ID: <20180618103654.GA9771@ACM> References: <20180531123747.GA24752@ACM> <20180617201351.GA4580@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1529318519 22254 195.159.176.226 (18 Jun 2018 10:41:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 18 Jun 2018 10:41:59 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) Cc: Glenn Morris , Emacs developers , Tino Calancha To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 18 12:41:55 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 1fUrbe-0005gW-OO for ged-emacs-devel@m.gmane.org; Mon, 18 Jun 2018 12:41:54 +0200 Original-Received: from localhost ([::1]:33920 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUrdm-0005Yv-1Y for ged-emacs-devel@m.gmane.org; Mon, 18 Jun 2018 06:44:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUrd8-0005Yn-Kh for emacs-devel@gnu.org; Mon, 18 Jun 2018 06:43:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUrd5-0000J2-If for emacs-devel@gnu.org; Mon, 18 Jun 2018 06:43:26 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:34872 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fUrd5-0000Il-84 for emacs-devel@gnu.org; Mon, 18 Jun 2018 06:43:23 -0400 Original-Received: (qmail 99079 invoked by uid 3782); 18 Jun 2018 10:43:22 -0000 Original-Received: from acm.muc.de (p5B146420.dip0.t-ipconnect.de [91.20.100.32]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 18 Jun 2018 12:43:20 +0200 Original-Received: (qmail 9792 invoked by uid 1000); 18 Jun 2018 10:36:54 -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.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:226449 Archived-At: Hello, Joćo. On Sun, Jun 17, 2018 at 22:27:20 +0100, Joćo Tįvora wrote: > On Sun, Jun 17, 2018 at 9:13 PM, Alan Mackenzie wrote: > > Hello, Glenn. > > On Sun, Jun 17, 2018 at 12:58:53 -0400, Glenn Morris wrote: > > > Alan Mackenzie wrote: > > > > However, the test suite (make check) threw up another discrepancy, in a > > > > test called > > > > electric-pair-whitespace-chomping-2-at-point-4-in-c++-mode-in-strings. > > > Hello, is this still being worked on? > > > The test continues to fail on RHEL 7 and hydra.nixos.org. > > From my point of view, the bug is not being worked on this very day, but > > has by no means been forgotten. It has needed a period of mulling over. > > I think Joćo sees it the same way. > 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. > So I suggest taking a quick temporary action to make the test pass > and then think about how to do it properly. This action could be > disabling the test temporarily but IME that invariably buries the > issue ad eternum. So it's better to do it in cc-mode. 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. > Although it won't be difficult to fix, this bug is an awkward thing, and > > will need decisions (smallish ones) to be taken. > > My favoured method would be to alter electric-pair--skip-whitespace such > > that a NL terminating a string (as contrasted with a NL terminating a > > comment) would be allowed to be scanned over. > I'm OK with adding an customization point to > electric-pair--skip-whitespace that c-mode can customize. But I also > wonder whether the benefit to end-users of handling NL-terminated > 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. A C(++) compiler regards an unterminated string as ending at the (first unescaped) linefeed. It will then regard the next line as code (not string). If there is a subsequent ", the compiler won't see that as a terminator for the unbalanced opening ". CC Mode now matches this reality, which is a Good Thing. 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? 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. > But more importantly perhaps there are ways to reap these benefits in a > way that doesn't require changes to e-p-m, or even better, in a way > that benefits all of Emacs, not just c-mode. 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.) > 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. 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. > Joćo -- Alan Mackenzie (Nuremberg, Germany).