その前に、BDS2006が何百MBもメモリー要求してスワップでしょっちゅう作業中断する件。
メモリー買い足せばいいんだろうけど、事務所のはやっかいな位置に取り付けてあって、
他のいろんなものをいちいちバラさないとダメなので面倒でやる気がしない。
何の根拠もないが、おそらくソースに含まれる数百KB分のテーブルデータかなと疑い、
文字コード変換部分をDLL化して、ソースを切り離そうかと画策。
テーブルのデータを受け渡すだけの関数をエクスポートするのはたぶん動作速度に絡む。
動作速度向上のためのテーブルなんだからこれはやっても意味がない。
よって、DLL化するなら、文字コードの判定から変換まで全部やる関数にしなきゃいかん。
だが、それだとSaveは良くてもLoadでDelphi特有のメモリー問題と向き合うことになる。
borlndmm.dllはたったの29KBなので、これを使っても良いのだが、
その部分をC++(書くのはCだけど)に移植すればそれもいらなくなるので、移植開始してみる。
ところがここで、Load関数の引数や戻り値で悩み、これをやっても複雑になるだけだと思い直す。
結局Delphiで作ってるものは、DLLに分散するのには向いてない宿命なのか。
いや、そもそも分散したい理由になった、Delphi自体の挙動不審さえ回避できればいいのだが。
というわけでこれは、Delphiの調子次第で将来やるかも知れないしやらないかも知れない。
この部分を動的リンクにすれば、その分起動時の処理も減って良いのだが。

さて本題のVBだが、VB6.0とVB.NETと、VB2005でどれだけの差があるんだろうか？
これから色分けで対応させたいのは、もちろん2005だが、
その選択肢に付ける名称が、単にVisual Basicじゃ、なんかどこかで文句が出そうな気がする。
それはC#にも言えることで、バージョンが上がって変更があった部分も対応しなきゃな。
ほいで、VBの色分けだが、ヘルプを見ていると、
予約されたキーワード、予約されてないキーワード、関数、モジュールなど、
色分けではなく強調表示として実装すべき単語がたくさんあるのだ。
文章に英単語が登場した時点で、予約語に該当するかどうかを検索するわけだが、
予約語だけでなくその他の関数やモジュールに該当するかも検索させれば、
当然描画速度も下がっていくわけだが、VB以外にもこれをやりたい言語はあるので、
とくにPHPがVBと同様に半分キーワードになってる関数が多いので対応していきたい。

いろんな言語の色分けをやる上で、キーワードは調べれば出てくるので問題ないのだが、
大文字と小文字の区別であったり、文字列の中でのエスケープであったり、
16進数のためのプリフィクスのようなもの、さらにヒアとかが問題になって、
使ってみたことのない言語はなかなか対応して行きにくい。
VBはちょっと触ってやる気が起きたけど、本当は他にも対応したい言語は多いんだぜ。