Case insensitive font-lock

Case insensitive font-lock

[Bert Geens]

Hi,

I originally posted this to gnu.emacs.lisp in the hopes that it was less
dead than it seemed, but it really is as dead as it looks so I'm reposting
this here.

I'm writing a major mode (http://www.lair.be/projects_fvwm-mode.php) for
the Fvwm window manager, now as Fvwm's keywords are case insensitive I was
wondering if there is an easy way to make font lock ignore the casing of
the keywords.

Thanks in advance for any help you can provide.

Bert 'theBlackDragon' Geens

Re: Case insensitive font-lock

[Kevin Rodgers]

Bert Geens wrote:
 > I'm writing a major mode (http://www.lair.be/projects_fvwm-mode.php) for
 > the Fvwm window manager, now as Fvwm's keywords are case insensitive 
I was
 > wondering if there is an easy way to make font lock ignore the casing of
 > the keywords.

,----[ C-h v font-lock-keywords-case-fold-search RET ]
| font-lock-keywords-case-fold-search's value is nil
|
| Documentation:
| *Non-nil means the patterns in `font-lock-keywords' are case-insensitive.
| This is normally set via `font-lock-defaults'.
|
| Defined in `font-lock'.
`----

,----[ C-h v font-lock-defaults RET ]
| font-lock-defaults's value is nil
|
| Documentation:
| Defaults for Font Lock mode specified by the major mode.
| Defaults should be of the form:
|
|  (KEYWORDS KEYWORDS-ONLY CASE-FOLD SYNTAX-ALIST SYNTAX-BEGIN ...)
|
| KEYWORDS may be a symbol (a variable or function whose value is the 
keywords to
| use for fontification) or a list of symbols.  If KEYWORDS-ONLY is non-nil,
| syntactic fontification (strings and comments) is not performed.
| If CASE-FOLD is non-nil, the case of the keywords is ignored when 
fontifying.
| If SYNTAX-ALIST is non-nil, it should be a list of cons pairs of the form
| (CHAR-OR-STRING . STRING) used to set the local Font Lock syntax 
table, for
| keyword and syntactic fontification (see `modify-syntax-entry').
|
| If SYNTAX-BEGIN is non-nil, it should be a function with no args used 
to move
| backwards outside any enclosing syntactic block, for syntactic 
fontification.
| Typical values are `beginning-of-line' (i.e., the start of the line is 
known to
| be outside a syntactic block), or `beginning-of-defun' for programming 
modes or
| `backward-paragraph' for textual modes (i.e., the mode-dependent 
function is
| known to move outside a syntactic block).  If nil, the beginning of 
the buffer
| is used as a position outside of a syntactic block, in the worst case.
|
| These item elements are used by Font Lock mode to set the variables
| `font-lock-keywords', `font-lock-keywords-only',
| `font-lock-keywords-case-fold-search', `font-lock-syntax-table' and
| `font-lock-beginning-of-syntax-function', respectively.
|
| Further item elements are alists of the form (VARIABLE . VALUE) and 
are in no
| particular order.  Each VARIABLE is made buffer-local before set to VALUE.
|
| Currently, appropriate variables include `font-lock-mark-block-function'.
| If this is non-nil, it should be a function with no args used to mark any
| enclosing block of text, for fontification via M-g M-g.
| Typical values are `mark-defun' for programming modes or 
`mark-paragraph' for
| textual modes (i.e., the mode-dependent function is known to put point 
and mark
| around a text block relevant to that mode).
|
| Other variables include that for syntactic keyword fontification,
| `font-lock-syntactic-keywords'
| and those for buffer-specialized fontification functions,
| `font-lock-fontify-buffer-function', 
`font-lock-unfontify-buffer-function',
| `font-lock-fontify-region-function', 
`font-lock-unfontify-region-function',
| `font-lock-inhibit-thing-lock' and `font-lock-maximum-size'.
|
| Defined in `font-lock'.
`----

-- 
Kevin Rodgers

Re: Case insensitive font-lock

[Bert Geens]

On Mon, 15 Aug 2005 11:08:02 -0600, Kevin Rodgers wrote:

> Bert Geens wrote:
>  > I'm writing a major mode (http://www.lair.be/projects_fvwm-mode.php) for
>  > the Fvwm window manager, now as Fvwm's keywords are case insensitive 
> I was
>  > wondering if there is an easy way to make font lock ignore the casing of
>  > the keywords.
> 
> ,----[ C-h v font-lock-keywords-case-fold-search RET ]
<snip>
> `----

Thanks a lot, i had looked at font-lock-defaults but apparently not hard
enough...

So I tried this:
(set (make-local-variable 'font-lock-defaults) '(fvwm-font-lock-keywords
nil fvwm-keywords-ignore-case))
But that apparently didn't  work, I wonder why?

I now use this, which does work though, but the above solution would be
cleaner imho...

  (if fvwm-keywords-ignore-case
      (set (make-local-variable 'font-lock-defaults) '(fvwm-font-lock-keywords))
    (set (make-local-variable 'font-lock-defaults)
    '(fvwm-font-lock-keywords nil t)))

Cheers

Bert

Re: Case insensitive font-lock

[Kevin Rodgers]

Bert Geens wrote:
 > Thanks a lot, i had looked at font-lock-defaults but apparently not hard
 > enough...
 >
 > So I tried this:
 > (set (make-local-variable 'font-lock-defaults) '(fvwm-font-lock-keywords
 > nil fvwm-keywords-ignore-case))
 > But that apparently didn't  work, I wonder why?

Because the CASE-FOLD entry is not like the KEYWORDS entry.  To cite the
doc string again:

	KEYWORDS may be a symbol (a variable or function whose value is
	the keywords to use for fontification) or a list of symbols.

But no similar statement is made about CASE-FOLD, so you want the actual
value of fvwm-keywords-ignore-case:

(set (make-local-variable 'font-lock-defaults)
      (list 'fvwm-font-lock-keywords nil fvwm-keywords-ignore-case))

or:

(set (make-local-variable 'font-lock-defaults)
      `(fvwm-font-lock-keywords nil ,fvwm-keywords-ignore-case))

That being said, using any non-nil object for CASE-FOLD (such as the
fvwm-keywords-ignore-case symbol) should result in case-insensitive
font-locking.

 > I now use this, which does work though, but the above solution would be
 > cleaner imho...
 >
 >   (if fvwm-keywords-ignore-case
 >       (set (make-local-variable 'font-lock-defaults) 
'(fvwm-font-lock-keywords))
 >     (set (make-local-variable 'font-lock-defaults)
 >     '(fvwm-font-lock-keywords nil t)))

That looks backwards.  If fvwm-keywords-ignore-case is set, I'd expect
you to specify CASE-FOLD as non-nil.  But you are specifying CASE-FOLD
as t when fvwm-keywords-ignore-case is nil.

-- 
Kevin Rodgers

Re: Case insensitive font-lock

[Bert Geens]

On Mon, 22 Aug 2005 13:09:24 -0600, Kevin Rodgers wrote:

> Bert Geens wrote:
>  > Thanks a lot, i had looked at font-lock-defaults but apparently not hard
>  > enough...
>  >
>  > So I tried this:
>  > (set (make-local-variable 'font-lock-defaults) '(fvwm-font-lock-keywords
>  > nil fvwm-keywords-ignore-case))
>  > But that apparently didn't  work, I wonder why?
> 
> Because the CASE-FOLD entry is not like the KEYWORDS entry.  To cite the
> doc string again:
> 
> 	KEYWORDS may be a symbol (a variable or function whose value is
> 	the keywords to use for fontification) or a list of symbols.
> 
> But no similar statement is made about CASE-FOLD, so you want the actual
> value of fvwm-keywords-ignore-case:
> 
> (set (make-local-variable 'font-lock-defaults)
>       (list 'fvwm-font-lock-keywords nil fvwm-keywords-ignore-case))
> 
> or:
> 
> (set (make-local-variable 'font-lock-defaults)
>       `(fvwm-font-lock-keywords nil ,fvwm-keywords-ignore-case))
> 
> That being said, using any non-nil object for CASE-FOLD (such as the
> fvwm-keywords-ignore-case symbol) should result in case-insensitive
> font-locking.
> 
>  > I now use this, which does work though, but the above solution would be
>  > cleaner imho...
>  >
>  >   (if fvwm-keywords-ignore-case
>  >       (set (make-local-variable 'font-lock-defaults) 
> '(fvwm-font-lock-keywords))
>  >     (set (make-local-variable 'font-lock-defaults)
>  >     '(fvwm-font-lock-keywords nil t)))
> 
> That looks backwards.  If fvwm-keywords-ignore-case is set, I'd expect
> you to specify CASE-FOLD as non-nil.  But you are specifying CASE-FOLD
> as t when fvwm-keywords-ignore-case is nil.

I'm in the middle of my exams, so that's why I'm replying a bit slow, and
why I'm sleeping too little, thanks for the explanation, I'll get that
fixed before I release a new version :)

Cheers

Bert