---

24.7.2 検索ベースのフォント化 ¶

検索ベースのフォント表示を直接制御する変数はfont-lock-keywordsです。この変数は通常はfont-lock-defaults内の要素keywordsを通じて指定されます。

Variable: font-lock-keywords ¶

この変数の値はハイライトするキーワードのリスト。Lispプログラムはこの変数を直接セットしないこと。通常はfont-lock-defaults内の要素keywordsを使用してFont Lockモードが自動的に値をセットする。この値は関数font-lock-add-keywordsとfont-lock-remove-keywordsを使用して変更することもできる(検索ベースのフォント化のカスタマイズを参照)。

font-lock-keywordsの各要素は、特定の例に該当するテキストを見つける方法や、それらをハイライトする方法を指定します。Font Lockモードはfont-lock-keywordsの要素を逐次処理してマッチを探して、すべてのマッチを処理します。通常はテキストの一部はすでに一度はフォント表示されており、同じテキスト内で連続するマッチによりこれをオーバーライドすることははできません。しかしsubexp-highlighterの要素overrideを使用して異なる挙動を指定できます。

font-lock-keywordsの各要素は以下の形式のいずれかをもつべきです:

regexp

font-lock-keyword-faceを使用してregexpにたいするすべてのマッチをハイライトする。たとえば、

;; font-lock-keyword-faceを使用して
;; 単語‘foo’をハイライトする
"\\<foo\\>"

これらの正規表現を作成するときは慎重に行うこと。下手に記述されたパターンによりスピードが劇的に低下し得る! 関数regexp-opt (正規表現の関数を参照)は、いくつかのキーワードとマッチするために最適な正規表現の計算に有用である。

function

functionを呼び出すことによりテキストを探し、font-lock-keyword-faceを使用して見つかったマッチをハイライトする。

functionは呼び出される際に1つの引数(検索のリミット)を受け取る。検索はポイント位置から開始しリミットを超えた検索は行わないこと。これは検索が成功したら非nilをリターンして見つかったマッチを表すマッチデータをセットすること。nilのリターンは検索の失敗を示す。

フォント表示は前の呼び出しでポイントが残された位置から同じリミットを用いてfunctionを呼び出し、functionが失敗するまでfunctionを繰り返し呼び出すだろう。検索が失敗しても何らかの特別な方法でfunctionがポイントをリセットする必要はない。

(matcher . subexp)

この種の要素ではmatcherは上述のregexpかfunctionのいずれかである。CDRのsubexpは、(matcherがマッチするテキスト全体のかわりに)matcherのどの部分式(subexpression)がハイライトされるべきかを指定する。

;; font-lock-keyword-faceを使用して
;; ‘bar’が‘fubar’の一部のときに
;; ハイライトする
("fu\\(bar\\)" . 1)

(matcher . facespec)

この種の要素ではfacespecの値がハイライトに使用するフェイスを指定する。もっともシンプルな例ではfacespecは値がフェイス名であるようなはLisp変数(シンボル)。

;; fubar-faceの値のフェイスを使用して
;; ‘fubar’をハイライトする
("fubar" . fubar-face)

しかしfacespecは以下のような形式のリストに評価されてもよい:

(subexp
(face face prop1 val1 prop2 val2...))

これはマッチしたテキストにフェイスfaceを指定し、さまざまなテキストプロパティをputする。これを行う場合には、この方法によってfont-lock-extra-managed-propsに値をセットする、他テキストプロパティ名を確実に追加すること。そうすればそれらのプロパティが妥当性を失ったとき、それらのプロパティもクリアーされるだろう。これらのプロパティをクリアーする関数を変数font-lock-unfontify-region-functionにセットすることもできる。Font Lockのその他の変数を参照のこと。

(matcher . subexp-highlighter)

この種の要素ではsubexp-highlighterはmatcherにより見つかったマッチをハイライトする方法を指定するリストである。これは以下の形式をもつ。

(subexp facespec [override [laxmatch]])

CARのsubexpはマッチのどの部分式をフォント表示するかを指定する整数(0はマッチしたテキスト全体を意味する)。これの2つ目の要素facespecは上述したような、値がフェイスを指定する式である。

subexp-highlighter内の残りの値overrideとlaxmatchはオプションのフラグである。overrideがtなら、この要素は前のfont-lock-keywordsの要素により作成された既存のフォント表示をオーバーライドできる。値がkeepなら、すでに他の要素によりフォント表示されていない文字がフォント表示される。値がprependなら、facespecにより指定されたフェイスがfont-lock-faceプロパティの先頭に追加される。値がappendなら、そのフェイスがfont-lock-faceプロパティの最後に追加される。

laxmatchが非nilなら、それはmatcher内で番号付けされた部分式subexpが存在しなくてもエラーにならないことを意味する。番号付けされた部分式subexpのフォント表示は当然発生しない。しかし他の部分式(と他のregexp)のフォント表示は継続されるだろう。laxmatchがnil、かつ指定された部分式が存在しなければ、エラーがシグナルされて検索ベースのフォント表示は終了する。

以下はこのタイプの要素とそれが何を行うかの例:

;; foo-bar-faceを使用して、たとえハイライト済みでも
;; ‘foo’と‘bar’をハイライトする
;; foo-bar-faceは値がフェイスであるような変数であること
("foo\\|bar" 0 foo-bar-face t)

;; fubar-faceの値のフェイスを使用して
;; 関数fubar-matchが見つけた各マッチの
;; 最初の部分式をハイライトする
(fubar-match 1 fubar-face)

(matcher . anchored-highlighter)

この種の要素ではanchored-highlighterはmatcherが見つけたマッチに後続するテキストをハイライトする方法を指定する。つまりmatcherが見つけたマッチは、anchored-highlighterにより指定されるその先の検索にたいするアンカー(anchor)として機能する。anchored-highlighterは以下の形式のリストである:

(anchored-matcher pre-form post-form subexp-highlighters...)

ここでanchored-matcherはmatcherと同様、正規表現か関数である。matcherにたいするマッチを見つけた後に、ポイントはそのマッチの終端に移動する。そこでFont Lockはフォームpre-formを評価する。それからanchored-matcherにたいするマッチを検索し、subexp-highlightersを使用してそれらのマッチをハイライトする。subexp-highlighterについては上記を参照のこと。最後にFont Lockはpost-formを評価する。

フォームpre-formとpost-formは、anchored-matcher使用時の事前の初期化と事後のクリーンアップに使用できる。pre-formは通常はanchored-matcherの開始前に、matcherのマッチに関連する何らかの位置にポイントを移動するために使用される。post-formは、matcherの再開前にポイントを戻すために使用できる。

pre-formを評価した後、Font Lockはその行の終端の先にたいしてanchored-matcherの検索を行わない。しかしpre-formがpre-form評価後のポイント位置より大きいバッファー位置をリターンした場合には、かわりにpre-formによりリターンされた位置が検索リミットとして使用される。その行の終端より大きい位置をリターンするのは、一般的にはよいアイデアではない。言い換えるとanchored-matcher検索は複数行にわたる(span lines)べきではない。

たとえば、

;; item-faceの値を使用して
;; 単語‘anchor’に(同一行内で)
;; 後続する単語‘item’をハイライトする
("\\<anchor\\>" "\\<item\\>" nil nil (0 item-face))

ここではpre-formとpost-formはnilである。したがって‘item’にたいする検索は‘anchor’にたいするマッチの終端から開始されて、後続する‘anchor’インスタンスにたいする検索は‘item’にたいする検索が終了した位置から再開される。

(matcher highlighters…)

この種の要素は単一のmatcherにたいして複数のhighlighterリストを指定する。highlighterリストには、上述したsubexp-highlighterかanchored-highlighterのいずれかを指定できる。

たとえば、

;; anchor-faceの値内に現れる単語‘anchor’、
;; および、(同じ行の)後続のitem-faceの
;;  値内に現れる単語‘item’をハイライトする
("\\<anchor\\>" (0 anchor-face)
                ("\\<item\\>" nil nil (0 item-face)))

(eval . form)

ここでformはバッファー内でこのfont-lock-keywordsの値が最初に使用されるときに評価される式である。この値は上述のテーブルで説明したいずれかの形式をもつこと。

警告: 複数行にわたるテキストにたいするマッチさせるために、font-lock-keywordsの要素をデザインしてはならない。これは確実に機能するとは言えない。詳細は複数行のFont Lock構造を参照のこと。

検索ベースのフォント表示がcaseを区別すべきかどうかを告げるfont-lock-keywords-case-fold-searchの値を指定するためにfont-lock-defaults内でcase-foldを使用できる。

Variable: font-lock-keywords-case-fold-search ¶

非nilはfont-lock-keywordsのための正規表現マッチングがcaseを区別すべきではないことを意味する。