Re: How to make font lock work with comments?

[rusi <rustompmody@gmail.com>]

On Dec 30, 7:09 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
> rusi <rustompm...@gmail.com> writes:
> > Im hacking on an apl mode
> > In other words emacs sees this as a comment-type char (similar to what
> > it says for semicolon in elisp buffers
>
> > And yet in an elisp buffer the ; to EOL is red
> > but here it is not.
>
> Font locking is a tricky matter.
>
> (font-lock-add-keywords nil
>     '(("⍝.*"                          0 font-lock-comment-face prepend)
>      ("[^\\]\"\\([^\"\\]*\\|\\.\\)\"" 0 font-lock-string-face  prepend)))

Thanks Pascal.  I gave this (\x235 is that char) and it works
[Else I get some unicode-related messages when I try ot save the el
file]

(font-lock-add-keywords 'inferior-apl-mode
    '(("\x235d.*"     0 font-lock-comment-face prepend)))

I guess the second line is for strings?
Where do I get all the (typical) faces that should be set up for a
progmode?
Ive been trying to copy stuff from scheme.el -- is there a better
model?

>
> The main problem is that it uses regular expressions to find the
> "keywords", but you want syntax coloring.  However, there's a way to use
> it for syntax coloring, since instead of a regular expression, you can
> use a function here, which will have to set the "matched regions".
>
> For example, for an assembler, I wrote a function to parse
> (syntactically) an assembler line, and matching the fields.  It is
> configured with font-lock-add-keywords as:
>
>  (font-lock-add-keywords
>    nil
>    (list
>     (list
>      (function search-asm7090-fields)
>      '(1 font-lock-function-name-face)       ; labels
>      '(2 font-lock-keyword-face)             ; operation codes
>      '(3 font-lock-reference-face)           ; arguments
>      '(4 font-lock-comment-face)             ; comments
>      '(5 font-lock-preprocessor-face)        ; ibsys
>      '(6 font-lock-type-face)                ; cols 72-80
>      )))


I dont think I really understand this...  In any case I guess I dont
need much parsing (for apl)


>
> Of course, you can also implement buffer-wide syntax analysis, and have
> these functions just report the findings.
>
> --
> __Pascal Bourguignon__                    http://www.informatimago.com/
> A bad day in () is better than a good day in {}.