🚀 go-pugleaf

新村です。有難うございます、山岡さん。

まずは、結果から。

int x,
    y;
などの2行だけなら、無事着色されました^^;　ところが、3行目からは着色さ
れません。M-x font-lock-mode 2回で、何度も試しましたが、やはり、3行目
からは、新規ファイルの編集でも、既存のファイルの読み込みでも同様に2行
のみの着色でした。例えば、
int a,
    b,
    c;
でも、
int a,
    b,
    c,
    d;
でも、着色されるのは、2行目までです。Lispを拝見していても、ループで次
行を検索していくので、3行目だろうが、4行目だろうが着色されるはずですよ
ね。何故？？私が、致命的な勘違いをしているのかな。

Katsumi Yamaokaさんの<yosug0asm9n7.fsf@jpl.org>から

>ただしこれはまだ、
>
>山岡> find-file した直後には効くのですが、on the fly でコードを書いて
>山岡> いる最中には効果が無いことです。
>
>この問題を解決していません。
>font-lock は行単位の動作が主のようで、以下の 2 行目が改変された
>場合はその行を fontify し直すかどうかを調べるのですが、
>
>int foo,
>    bar;
>
>font-lock-keywords にはその行だけにマッチするキーが無いので着色
>が解除されてしまいます。それは、着色が解除された後で 1 行目を書
>き換えると色が復活することからもわかります。

ええ。おっしゃっている意味からも、前述の結果が不思議です。山岡さんのと
ころでは、うまくいっているのですよね。テストは、sample.Cで行いましたけ
ど、C++モードに入って、着色が済み、font-lock-modeを解除・実行としてみ
ても結果同じです。無論書きなおしてみたりもしてみましたけど。うーーん。

>それはかなりすごいものなのだと思えてきました。たぶんぼくのアプロー
>チとは違って keywords そのものを書き換えてしまうタイプではないか
>と思うのですが、オリジナルの font-lock では
>
>(match-beginning 13)
>
>などというすさまじい正規表現が使われているので、一朝一夕にできる
>ものではないでしょう。ぼくは、また折を見て挑戦しようと思いますが。

山岡さんのような、e-lispのスキルがないので、今のところ手が出せません
が、確かに、keyword.elなるものをロードして書きなおしていたようにも思え
ます。不確かで申し訳ありませんが。

>ところで、新村さんは font-lock を素のままで使っていらっしゃいま
>すよね(?)。よろしければ XEmacs に付属している lazy-shot を併用す
>るのはいかがでしょうか。たぶん
>
>(add-hook 'font-lock-mode-hook 'turn-on-lazy-shot)
>
>これだけで良いと思います。

早速、放り込みました^^;　有難うございます。実は、lazy-lockを使ってみた
のですが、すぐに戻しました。地雷を踏んだというより、挙動が解り難かった
ものですから。
 
>;; http://list-archive.xemacs.org/xemacs-beta/200106/msg00314.html
>;; だれも相手してくれなかったのは変な英語のせいかしら。(^^;;)

米国のサイトでも、普通に検索していても、見つかりませんものね。開発者さ
んが、自前でカスタマイズしていて、パッチの類とかが出回っていないのかも
しれませんね。でも、構造体なんかで、長いレコードを作る時、米国の方々も
同じようなコーディングしているんで、普通に起きる話だと思うのですけど。

C++なら、尚更ですし。

ともあれ、勉強になりました。有難うございます。

-- 
Atushi Shinmura mailto:atushi.shinmura@nifty.ne.jp