Hi, Stefan.
On Wed, 9 Mar 2005, Stefan Monnier wrote:
>> [The discussion is about a font-locking problem reported in CC Mode: The
>> user types the start of a C function, but puts a NL in the middle:
>> void function
>> (int x);
>> The second line gets incorrectly fontified, because in its
>> after-change-functions, font-lock considers only that line in and of
>> itself.]
>[...]
>> However: I did complain about this shortcoming of font-lock on
>> gnu.emacs.bug way back, on Friday 10th May 2002 (Subject: Font-lock:
>> Major mode should be able to specify region to fontify. Message-Id:
>> <[EMAIL PROTECTED]>), and that post of mine contained a patch to add
>> the facility to font-lock. Nobody apart from Kim Storm (who objected
>> (quite reasonably) to the prolix function names I'd used) responded to
>> the post at the time, and nothing happened. That's when I decided that
>> advising font-lock was the least bad way of solving the problem.
>Hmm... I can't remember such a post and I have a hard time imagining why
>I wouldn't have jumped on it.
We talked about it in bug-cc-mode just after CC Mode 5.30 had been
released. (Subject: Advising in cc-awk.el and namespace Date: Wed, 09
Jul 2003 13:20:20 -0400). I drew attention then (Jul 2003) to the patch
I had submitted in 2002, which you acknowledged. However, the topic of
conversation drifted onto why jit-lock consumed so much processor power.
>Could you explain some more about your two cases (the one in awk and the
>one in the subject of this article):
>- how do they use your new before-font-lock-after-change-function hook?
The one in AWK is with a string like this:
print "multi-l\
ine\
string
^
|
point
The opening quote has been given warning font, since it is an unmated
quote. When the closing quote is typed, the opening quote's face gets
changed to string face. This is done by the advice on
font-lock-after-change-function (or the jit-lock thingy ...) amending the
BEGIN parameter to point to the start of the "print" line, before passing
this into font-lock.
The C example at the top is essentially the same; the single line
containing "(int x);" currently gets fontified by after-change in
isolation; correct fontification requires that it be fontified with the
previous line as a unit.
The patch I proposed would achieve this result via a user supplied
function.
>- why can't they use the font-lock-multiline property?
I couldn't find any documentation for the facility back in 2002, and I
couldn't figure out from the source code exactly what it did. I've now
got it working for me in Texinfo mode, though.
Also, font-lock-multiline doesn't (yet?) exist in XEmacs, so I'd need to
implement a second solution for XEmacs if f-l-multiline was used. CC
Mode still supports Emacs 20.x, and I think I found that f-l-multiline
was introduced later than 20.1 (though I can't remember exactly).
>- why can't they use the jit-lock-defer-multiline property?
I'll have to look at that one. But presumably that doesn't exist in both
of XEmacs and Emacs 20.x either.
>This will allow us the better judge which is the better course of
>action. Using advice on font-lock functions from awk-mode is pretty
>ugly, so it's important we come up with a better way to solve this
>issue.
Agreed on all points. I think, as I have done since 2002, that the
major-mode should be able to supply functions to determine the start and
end of the region to be fontified. It seems a natural and idiomatic
Emacsy way of doing things.
Even so, it would be several years before major modes could start using
it in earnest, due to the need to continue supporting older Emacs
versions. (CC Mode 5.30 gave up support for 19.34 by starting to use
text properties.) How long is it going to be before 22.1 becomes the
oldest Emacs version supported by a major mode?
> Stefan
--
Alan Mackenzie (Munich, Germany)
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
