From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.devel Subject: Re: [sigra@home.se: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows] Date: Wed, 15 Mar 2006 11:16:28 -0500 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1142439445 23631 80.91.229.2 (15 Mar 2006 16:17:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 15 Mar 2006 16:17:25 +0000 (UTC) Cc: bug-cc-mode@gnu.org, martin rudalics , Ralf Angeli , "Richard M. Stallman" , emacs-devel@gnu.org Original-X-From: cc-mode-help-admin@lists.sourceforge.net Wed Mar 15 17:17:21 2006 Return-path: Envelope-to: sf-cc-mode-help@m.gmane.org Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FJYgM-0007JC-Ua for sf-cc-mode-help@m.gmane.org; Wed, 15 Mar 2006 17:17:07 +0100 Original-Received: from sc8-sf-list1-b.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7]) by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP id E7EBC13043; Wed, 15 Mar 2006 08:17:05 -0800 (PST) Original-Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1FJYgE-00007y-9B for cc-mode-help@lists.sourceforge.net; Wed, 15 Mar 2006 08:16:58 -0800 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by mail.sourceforge.net with esmtps (TLSv1:RC4-SHA:128) (Exim 4.44) id 1FJYgD-00040Z-9P for cc-mode-help@lists.sourceforge.net; Wed, 15 Mar 2006 08:16:58 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1FJYfy-0002h7-Dk for bug-cc-mode@gnu.org; Wed, 15 Mar 2006 11:16:46 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1FJYkN-0006xD-Ll for bug-cc-mode@gnu.org; Wed, 15 Mar 2006 11:21:18 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FJYkN-0006x5-74; Wed, 15 Mar 2006 11:21:15 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id B8E862CE9A7; Wed, 15 Mar 2006 11:16:37 -0500 (EST) Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 58427452A; Wed, 15 Mar 2006 11:16:28 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id 40338714FB; Wed, 15 Mar 2006 11:16:28 -0500 (EST) Original-To: Alan Mackenzie In-Reply-To: (Alan Mackenzie's message of "Wed, 15 Mar 2006 11:40:45 +0000 (GMT)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 Original-Sender: cc-mode-help-admin@lists.sourceforge.net Errors-To: cc-mode-help-admin@lists.sourceforge.net X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: , List-Id: Bug reports, feature requests, and general talk about CC Mode. List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 15 Mar 2006 11:16:28 -0500 Xref: news.gmane.org gmane.emacs.cc-mode.general:3208 gmane.emacs.devel:51666 Archived-At: >> Also, I thought we had agreed that this new feature should be in >> f-l-default-fontify-region rather than f-l-after-change-function. I believe >> it is *wrong* for it to be in f-l-after-change-function where it is mostly >> useless: > It actually works quite well, I've tested it. :-) Please re-read what I wrote. I don't say it won't work. It has various problems, tho, which you most likely wouldn't notice in random testing, especially if you turn off jit-lock. > I'm convinced this feature needs to be in the font-lock/jit-lock > after-change-functions. The fontification region is determined by the > _change_, not merely by the buffer contents after the change. For > example: > The stealth/display fontification would extend their regions using these > functions, Thinking of stealth fontification as a special case will not lead you to a good solution. Been there, done that. All the problems I've ever encountered that were supposedly "due to jit-lock" could also be reproduced without jit-lock. >> you can already get the same result by using an >> (non-f-l)after-change-functions hook that sets the >> font-lock-multiline property. > OK, but for that, font-lock-multiline must first be documented. Go for it. Note that I'm not talking about the variable, but about the text-property. > I've tried to figure out from the source how f-l-multiline works, but > haven't succeeded yet. Can f-l-multiline be used to extend the > fontification region backwards? Of course. Put font-lock-multiline property on all the chars of a region that should be refontified as a whole because the font-lock-keywords don't know how to refontify it correctly unless they get to see the whole thing at once. f-l-default-fontify-region then extends the region forward&backward so the region it refontifies doesn't start or end in the middle of a font-lock-multiline property. > With the f-l-multiline approach, you need somehow to ensure that the > non-f-l-after-change function gets called before f-l-after-change. Not if you use jit-lock ;-) > It can be done, but is hassle. Also, f-l-multiline is an internal Font > Lock mechanism, and major modes shouldn't have to manipulate it directly, > since it would increase the coupling between modes and Font Lock > enormously, making it expensive to change approach in the future. The feature you added suffers from the exact same problem. > ######################################################################### >>> More controversially, I've explicitly documented that the region returned >>> by the f-l-extend-region may start or end in the middle of a line. >> I don't care much either way. If someone does that, it's his problem: >> it won't hurt font-lock.el. But it may screw up the other >> font-lock-keywords. > Why would it be a problem? Given that f-l-extend-region-function and > font-lock-keywords both belong to the major mode, they can be made to > match eachother. Exactly: the author can only shoot himself, so "it's his problem". Except of course for minor modes which add their own keywords (via font-lock-add-keywords, for example), but these already suffer from several other comparable minor problems, so it's probably not making things noticeably worse. > A comment in jit-lock says that if the f-l region starts in the middle of > a line, that line won't be re-displayed. Which comment? >>> The "baz" on L3 hasn't a snowball's chance in Hades of getting fontified >>> with f-l-function-name-face unless the font lock region is allowed to >>> start at the "int" on L2. >> Why? After all, when you open the file, the region will start at BOB. > When you open the file, yes. > (i) You type a space on L2, "baz" changes to variable-name-face. > (ii) You then type a space on L3, it flips back to function-name-face, > but "bar" goes to default face. (font-lock-lines-before == 1) > (iii) Type a space on L1, "bar" is restored to variable-name-face after > ~0.5 second (contextual fontification?). > (iv) reload the file, do (i), then put point over "baz" (currently > variable-name-face). Do C-u C-x =, to display its properties. It > changes instantly to function-name-face, which it reports in the other > window. Hello Heisenberg! I dno't see where the above example requires the region to start "at the int on L2" (or more generally in the middle of a line). > I honestly don't think it's worthwhile to investigate each of these > happenings individually - it's amusing to watch for a few minutes, but > rapidly becomes tedious. They all stem from a single cause, namely the > misapprehension that font lock can start analyzing code at an > arbitrary BOL. It's not a misapprehension: it's a constraint. If your font-lock-keywords don't obey this constraint, then yes, you'll see funny things because your font-lock-keywords are broken. Lifting this constraint is what "adding multiline keywords support" is all about. But I still haven't seen any example where it needs to be possible to start in the middle of a line. What is often neded is to be able to prevent starting/ending at some particular BOLs. > OK, these are likely to be bugs in CC Mode's font lock patterns, but the > uncertainty caused by font-lock's instability makes them more difficult > to debug. Easy: turn off jit-lock and it becomes much more deterministic (and those bugs can still be easily reproduced). Sometimes you just need to cut&paste a block of text at the same spot (i.e. mark and then C-w C-y). > (i) f-l-extend-region-function should be supplemented by > f-l-safe-\(floor\|ceiling\)-position-function; if non-nil, these > functions give guaranteed good boundaries for fontification. They would > render contextual fontification redundant. No, it's still not redundant at all. Contextual fontification is solving other cases of multiline patterns where the approach of extending the region is unworkable (because the region may end up extended much too far, bringing Emacs to a crawl): e.g. removing/adding a " in a C file typically causes the whole rest of the buffer to be refontified. > (ii) Code expanding the font lock region to whole lines should be > removed (except as in (iii)). font-lock-multiline would become > redundant. I fail to see the conection between font-lock-multiline and whole lines. > (iv) The interface between Font Lock and the display code should be > amended so that a font lock region need not start at column 0. I don't think there is any such requirement. Stefan ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642