From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: bug#3269: 23.0.93; C-mode text highlighting Date: Mon, 18 May 2009 22:24:02 -0400 Message-ID: References: <878wl1h5fw.fsf@ancient.thomaschristensen.org> <20090514213924.GB2413@muc.de> <20090518150643.GA12920@muc.de> <20090518213030.GD12920@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1242699810 32359 80.91.229.12 (19 May 2009 02:23:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 May 2009 02:23:30 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, Chong Yidong , 3269@emacsbugs.donarmstrong.com, Thomas Christensen , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 19 04:23:22 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1M6EzC-0005uf-6t for ged-emacs-devel@m.gmane.org; Tue, 19 May 2009 04:23:22 +0200 Original-Received: from localhost ([127.0.0.1]:39667 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M6EzB-0004YY-9q for ged-emacs-devel@m.gmane.org; Mon, 18 May 2009 22:23:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M6Ez6-0004W8-CS for emacs-devel@gnu.org; Mon, 18 May 2009 22:23:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M6Ez1-0004Ln-0k for emacs-devel@gnu.org; Mon, 18 May 2009 22:23:15 -0400 Original-Received: from [199.232.76.173] (port=45872 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M6Ez0-0004La-Ss for emacs-devel@gnu.org; Mon, 18 May 2009 22:23:10 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:6830) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M6Eyy-0008Te-ME; Mon, 18 May 2009 22:23:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugEALK0EUpMCovv/2dsb2JhbACBT8tygjiBSQWFag X-IronPort-AV: E=Sophos;i="4.41,212,1241409600"; d="scan'208";a="38744872" Original-Received: from 76-10-139-239.dsl.teksavvy.com (HELO pastel.home) ([76.10.139.239]) by ironport2-out.teksavvy.com with ESMTP; 18 May 2009 22:23:05 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id CDE0E7F29; Mon, 18 May 2009 22:24:02 -0400 (EDT) In-Reply-To: <20090518213030.GD12920@muc.de> (Alan Mackenzie's message of "Mon, 18 May 2009 21:30:30 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:110977 gmane.emacs.pretest.bugs:24465 Archived-At: >> > OK, here is a patch for half of the problem - it now fontifies a broken >> > string in a #define properly >> For some definition of "properly". > 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. ;-) 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. When code is syntactically incorrect, it's common/normal/expected for the highlighting to be "incorrect". This "incorrect" behavior is actually a good way for the user to notice that his code has problems. 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. When I introduced the use of f-l-warning-face in C strings, it was not to avoid messed-up highlighting, but rather to avoid apparently correct highlighting for code that was actually incorrect/unportable (and even accepted by GCC at that time). >> I think this part is more important. I don't care much (if at all) >> about how invalid code is highlighted. > I agree it's important. I've got it working; what's more, the code > doesn't advise any of the font lock functions for (>= emacs-major-version > 22). I'll commit it tomorrow sometime. Thanks, Stefan