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#3269: 23.0.93; C-mode text highlighting Date: Tue, 19 May 2009 10:26:19 +0000 Message-ID: <20090519102619.GA1317__10897.8119715632$1242730343$gmane$org@muc.de> References: <878wl1h5fw.fsf@ancient.thomaschristensen.org> <20090514213924.GB2413@muc.de> <20090518150643.GA12920@muc.de> <20090518213030.GD12920@muc.de> Reply-To: Alan Mackenzie , 3269@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1242730343 11136 80.91.229.12 (19 May 2009 10:52:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 May 2009 10:52:23 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, Chong Yidong , 3269@emacsbugs.donarmstrong.com, Thomas Christensen , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 19 12:52:15 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1M6Mvd-0002Dt-Ge for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 May 2009 12:52:14 +0200 Original-Received: from localhost ([127.0.0.1]:56480 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M6Mvb-0000oH-MG for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 May 2009 06:52:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M6MvW-0000nu-Fd for bug-gnu-emacs@gnu.org; Tue, 19 May 2009 06:52:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M6MvT-0000nV-2c for bug-gnu-emacs@gnu.org; Tue, 19 May 2009 06:52:06 -0400 Original-Received: from [199.232.76.173] (port=40338 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M6MvS-0000nP-O2 for bug-gnu-emacs@gnu.org; Tue, 19 May 2009 06:52:02 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:38404) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M6MvS-0007HC-2q for bug-gnu-emacs@gnu.org; Tue, 19 May 2009 06:52:02 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4JApvBe003712; Tue, 19 May 2009 03:51:57 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n4JAZ6vl030808; Tue, 19 May 2009 03:35:06 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Alan Mackenzie Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 19 May 2009 10:35:06 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 3269 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 3269-submit@emacsbugs.donarmstrong.com id=B3269.124272874728521 (code B ref 3269); Tue, 19 May 2009 10:35:06 +0000 Original-Received: (at 3269) by emacsbugs.donarmstrong.com; 19 May 2009 10:25:47 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from mail.muc.de (qmailr@colin.muc.de [193.149.48.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4JAPfsk028515 for <3269@emacsbugs.donarmstrong.com>; Tue, 19 May 2009 03:25:44 -0700 Original-Received: (qmail 8348 invoked by uid 3782); 19 May 2009 10:25:40 -0000 Original-Received: from acm.muc.de (pD9E2397A.dip.t-dialin.net [217.226.57.122]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Tue, 19 May 2009 12:25:38 +0200 Original-Received: (qmail 1649 invoked by uid 1000); 19 May 2009 10:26:20 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Tue, 19 May 2009 06:52:06 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:28023 Archived-At: Hi, Stefan, On Mon, May 18, 2009 at 10:24:02PM -0400, Stefan Monnier wrote: > > The opening string quote (?\" or ?\') gets f-l-warning-face. The > > rest of the unclosed string (up to the first EOL which isn't escaped) > > gets f-l-string-face. > > Actually, that's not _quite_ "proper". A string with an even number of > > backslashes at an EOL is broken at that point, but the font locking > > doesn't show this (yet). I don't suppose that will bother you all that > > much. ;-) Whoops! I was utterly wrong there. When a string inside a #define has an even number of backslashes at an EOL, this is perfectly legal; the last \ escapes the EOL, concatenating the lines, and the second last \ escapes the first character on the next line. Nice simple language, C. ;-) > I won't oppose the change, but just to be clear: I think that the > increased code complexity introduced by your patch is a worse problem > than the "improper" highlighting it tries to fix. Well, I don't agree with that, but I'm beginning to think that the current fontification (ommitting f-l-string-face until the closing " is there) wasn't perhaps quite so bad after all. > When code is syntactically incorrect, it's common/normal/expected for > the highlighting to be "incorrect". Where "incorrect" here means "different from what it would be if the code were correct". > This "incorrect" behavior is actually a good way for the user to notice > that his code has problems. Agreed, totally. > So, from this point of view, there's no need to highlight the opening > string quote with f-l-warning-face: just looking back in the buffer > until you find the first char that is not font-locked as expected will > find the culprit without any need for any extra elisp code, and > moreover this method will work in many more cases. > In other words, messed-up highlighting for incorrect code is just as > good if not better than explicitly recognizing the incorrect code and > highlighting it with f-l-warning-face. I was thinking of "compatibility" with unterminated strings in normal code. But they're not the same thing. An open string in a #define is perfectly valid code, if somewhat unusual outside of the Obfuscated C competition. You've persuaded me that the existing fontification is actually better. So I won't be committing yesterday's patch. Thanks! I'll just finish the other patch and commit that. > Stefan -- Alan Mackenzie (Nuremberg, Germany).