font-lock

font-lock

[Florian Kaufmann]

I want to configure font-lock for my own mode. I still have troubles
to understand what I have to do so font-lock understands what to do
when matches overlap. Say my comments start with 2 hashes and go until
the end of the line, and strings are in between double quotes:

(defconst adoc-font-lock-keywords
  (eval-when-compile
    (list
     (cons "##.*$" 'font-lock-comment-face)
     (cons "\".*?\"" 'font-lock-string-face)
    )))

Now in my test buffer

"foo##bar"
##foo"bar"

The first line is not correctly fontified. I expect that the while
line has the string face, but "foo has no face, and ##bar" has comment
face. If I reverse the two (cons ...) lines, then the 2nd line in the
test buffer is ill formated: ##foo has no face, and "bar" has comment
face; I expect the whole 2nd line to be in comment face.

I think I can't make use of syntax tables, because actually my
comments/strings are more complex (and even that is a bit simplified
for this post):

comments
##.*$
#\w+
#\*.*?\*#

strings
".*?"
'\w+
'\[.*?\]
`\W+

Re: font-lock

[Andreas Politz]

Florian Kaufmann <sensorflo@gmail.com> writes:

[...]
> (defconst adoc-font-lock-keywords
>   (eval-when-compile
>     (list
>      (cons "##.*$" 'font-lock-comment-face)
>      (cons "\".*?\"" 'font-lock-string-face)
>     )))
>
> Now in my test buffer
>
> "foo##bar"
> ##foo"bar"
>
> The first line is not correctly fontified. I expect that the while
> line has the string face, but "foo has no face, and ##bar" has comment
> face. If I reverse the two (cons ...) lines, then the 2nd line in the
> test buffer is ill formated: ##foo has no face, and "bar" has comment
> face; I expect the whole 2nd line to be in comment face.
>
,----[ (info "(elisp) Search-based Fontification") ]
|    Each element of `font-lock-keywords' specifies how to find certain
| cases of text, and how to highlight those cases.  Font Lock mode
| processes the elements of `font-lock-keywords' one by one, and for each
| element, it finds and handles all matches.  Ordinarily, once part of
| the text has been fontified already, this cannot be overridden by a
| subsequent match in the same text; but you can specify different
| behavior using the OVERRIDE element of a SUBEXP-HIGHLIGHTER.
`----

> I think I can't make use of syntax tables, because actually my
> comments/strings are more complex (and even that is a bit simplified
> for this post):
>
Why not use both ? Syntax tables for, what I suppose are, multiline
matches (since they are difficult to do `by hand') and keywords for the
rest.

> comments
> ##.*$
> #\w+
> #\*.*?\*#
>
> strings
> ".*?"
> '\w+
> '\[.*?\]
> `\W+

-ap