🚀 go-pugleaf

>>>>> In <9leq0g$15s$1@news512.nifty.com>
>>>>>	Atushi Shinmura <atushi.shinmura@nifty.ne.jp> wrote:

新村さん> うーーん。すぐさま試してみたのですが、コードを読みこみ、着色
新村さん> のプログレスバーが画面下側に出てきて、９０％ぐらいまで進むの
新村さん> ですが、そこから先にいかずに、ずっと処理中になってしまいまし
新村さん> た。

ごめんなさい無限ループが起きていました。これなら大丈夫だと思うの
ですが、いかがでしょうか。

(defadvice font-lock-match-c++-style-declaration-item-and-skip-to-next
  (around work-with-the-next-line activate)
  "Advised to work with the next line."
  (if (<= (point) (ad-get-arg 0))
      (let ((opoint (if (and (= (point) (ad-get-arg 0))
			     (eolp)
			     (not (eobp)))
			(prog1
			    (point)
			  (while (and (zerop (forward-line 1))
				      (looking-at "[\t ]*$")))
			  (end-of-line)
			  (ad-set-arg 0 (point))
			  (beginning-of-line)))))
	ad-do-it
	(if (and (not ad-return-value) opoint)
	    (goto-char opoint)))
    (goto-char (ad-get-arg 0))
    (setq ad-return-value nil)))

ただしこれはまだ、

山岡> find-file した直後には効くのですが、on the fly でコードを書いて
山岡> いる最中には効果が無いことです。

この問題を解決していません。
font-lock は行単位の動作が主のようで、以下の 2 行目が改変された
場合はその行を fontify し直すかどうかを調べるのですが、

int foo,
    bar;

font-lock-keywords にはその行だけにマッチするキーが無いので着色
が解除されてしまいます。それは、着色が解除された後で 1 行目を書
き換えると色が復活することからもわかります。そういうわけで、

新村さん> 確か、１００行前後にもなる力作だったと思います。作者本人が現
新村さん> 在おりませんので、確かめる術もないのですが、米国のサイトから
新村さん> 貰って来た物を手直ししただけだということです。 

それはかなりすごいものなのだと思えてきました。たぶんぼくのアプロー
チとは違って keywords そのものを書き換えてしまうタイプではないか
と思うのですが、オリジナルの font-lock では

(match-beginning 13)

などというすさまじい正規表現が使われているので、一朝一夕にできる
ものではないでしょう。ぼくは、また折を見て挑戦しようと思いますが。

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

(add-hook 'font-lock-mode-hook 'turn-on-lazy-shot)

これだけで良いと思います。
これは人によっては気持ち悪いかもしれませんが、ともかく起動が速く
なります。etc/sample.init.el で紹介されている lazy-lock の方が見
え方がずっと綺麗なのですが、残念ながら致命的なバグがあります。

;; http://list-archive.xemacs.org/xemacs-beta/200106/msg00314.html
;; だれも相手してくれなかったのは変な英語のせいかしら。(^^;;)
-- 
Katsumi Yamaoka <yamaoka@jpl.org>