From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#15212: 24.3.50; c++-mode doesn't support raw string literals Date: Tue, 31 May 2016 21:32:37 +0000 Message-ID: <20160531213237.GB20373@acm.fritz.box> References: <8C5AB533-B326-424B-9612-0B4858BC80BF@gmail.com> <20160403183638.GE3537@acm.fritz.box> <20160528144045.GB2950@acm.fritz.box> <20160529213616.GC3367@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1464730408 5638 80.91.229.3 (31 May 2016 21:33:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 May 2016 21:33:28 +0000 (UTC) Cc: 15212@debbugs.gnu.org To: Ivan Andrus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 31 23:33:17 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b7rHo-0007k7-2r for geb-bug-gnu-emacs@m.gmane.org; Tue, 31 May 2016 23:33:16 +0200 Original-Received: from localhost ([::1]:38533 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b7rHn-00005K-Cz for geb-bug-gnu-emacs@m.gmane.org; Tue, 31 May 2016 17:33:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33420) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b7rHg-0008V2-8E for bug-gnu-emacs@gnu.org; Tue, 31 May 2016 17:33:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b7rHe-0000Zs-Ng for bug-gnu-emacs@gnu.org; Tue, 31 May 2016 17:33:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b7rHa-0000Ym-4t; Tue, 31 May 2016 17:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b7rHZ-0006T7-U4; Tue, 31 May 2016 17:33:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 31 May 2016 21:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15212 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 15212-submit@debbugs.gnu.org id=B15212.146473035624821 (code B ref 15212); Tue, 31 May 2016 21:33:01 +0000 Original-Received: (at 15212) by debbugs.gnu.org; 31 May 2016 21:32:36 +0000 Original-Received: from localhost ([127.0.0.1]:48783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b7rH9-0006SH-KL for submit@debbugs.gnu.org; Tue, 31 May 2016 17:32:35 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:30440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b7rH7-0006Rw-FM for 15212@debbugs.gnu.org; Tue, 31 May 2016 17:32:34 -0400 Original-Received: (qmail 25043 invoked by uid 3782); 31 May 2016 21:32:31 -0000 Original-Received: from acm.muc.de (p4FC4673E.dip0.t-ipconnect.de [79.196.103.62]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 31 May 2016 23:32:30 +0200 Original-Received: (qmail 21545 invoked by uid 1000); 31 May 2016 21:32:37 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:118906 Archived-At: Hello again, Ivan. On Tue, May 31, 2016 at 08:22:07AM -0600, Ivan Andrus wrote: > On May 29, 2016, at 3:36 PM, Alan Mackenzie wrote: >> I've now got a patch, which I'd be grateful if you could try out, both >> to see if there are any bugs, and also to get your general impression. >> I think there are one or two bugs left in the code, and it needs tidying >> up quite a lot. So this won't be the final version. > Awesome. I’ll keep looking and let you know of any bugs I find. > I did find one. According to > http://en.cppreference.com/w/cpp/language/string_literal the delimiter can > contain any characters except parentheses, backslash and spaces. Yes, I've read that and got angry with it. It's vague - it's not clear what is meant by "any source character" - the C++11 page in Wikipedia says that control characters are excluded. In practice, I suspect it won't matter all that much - most of the time the delimiter will just be "\"(" - anybody trying to do anything fancy in the delimiter deserves everything she gets. ;-) > Using square brackets confuses c++-mode though: > char brackets [] = R"0x22[(foobar)0x22["; > Now, I’ve never actually seen such a construct in the wild, but it would be > good to fix it regardless. The *Messages* buffer shows > File mode specification error: (invalid-regexp Unmatched [ or [^) > Error during redisplay: (jit-lock-function 1013) signaled (invalid-regexp > "Unmatched [ or [^") > which seems to point to a missing regexp-quote, and indeed it thinks > char bar [] = R"YYY*(bar)YYY"; > is a valid string literal. Yes indeed! I was doing a regexp search when an ordinary search was needed (twice). And a third occasion did indeed need a regexp-quote. Here's a (supplementary) patch to fix these glitches: --- cc-engine.el~ 2016-05-29 22:21:06.000000000 +0000 +++ cc-engine.el 2016-05-31 20:49:48.000000000 +0000 @@ -5836,7 +5836,7 @@ id (match-string-no-properties 1)) (goto-char (1+ open-paren-pos)) (when (and (not (c-get-char-property open-paren-pos 'syntax-table)) - (search-forward-regexp (concat ")" id "\"") nil t)) + (search-forward (concat ")" id "\"") nil t)) (setq close-paren-pos (match-beginning 0) close-quote-pos (1- (point)))))) (and open-quote-pos @@ -5908,7 +5908,7 @@ (open-quote (1+ (match-beginning 0))) (open-paren (match-end 1)) ) - (if (search-forward-regexp (concat ")" id "\"") nil t) + (if (search-forward (concat ")" id "\"") nil t) (let ((end-string (match-beginning 0)) (after-quote (match-end 0)) ) --- cc-fonts.el~ 2016-05-29 17:49:34.000000000 +0000 +++ cc-fonts.el 2016-05-31 21:01:14.000000000 +0000 @@ -1598,7 +1598,8 @@ (c-put-font-lock-face (match-beginning 1) (match-end 2) 'default) (when (search-forward-regexp - (concat ")\\(" (match-string-no-properties 2) "\\)\"") + (concat ")\\(" (regexp-quote (match-string-no-properties 2)) + "\\)\"") limit t) (c-put-font-lock-face (match-beginning 1) (point) 'default))))) > Moreover, I was somehow able to get it into a bad state where changing the > delimiters wouldn’t update fontification. I’ll see if I can come up with a > recipe for how to reproduce it reliably. That's happened to me, too. Maybe it's connected with the above error. But then again, maybe not. I'll keep trying to reproduce it, too. >> The way I am fontifying these is thus: >> (i) For a correctly terminated raw string, everything between the ( and ) >> inclusive gets string face, everything else just the default face: >> R"foo(bar)foo" >> ^^^^^ >> font-lock-string-face. > I was wondering how this would work. It’s a little weird that regular > string delimiters are fontified with font-lock-string-face, but these > aren’t. But I think I like this way better since it’s much easier to > confuse these delimiters with the contents of the string than normal string > delimiters. Glad you like it! [ .... ] >> Thanks a bunch for your work on this. Thank you! > -Ivan -- Alan Mackenzie (Nuremberg, Germany).