趣旨
Thebeを作り直した時期にはてなダイアリーで色々教えていただいたまとめ。
データ構造
- http://d.hatena.ne.jp/ytqwerty/20040528#p2
- http://d.hatena.ne.jp/ytqwerty/20040530#p3
- http://d.hatena.ne.jp/ytqwerty/20040607#p1
- http://d.hatena.ne.jp/ytqwerty/20040616#p1
- http://d.hatena.ne.jp/ytqwerty/20040616#p2
発端はk.inabaさん他のギャップバッファの記事から。
最初はバッファのデータ構造にリンクリストを用いていたのが遅いと思い込んでしまっていました。次に色分けが遅いと思い込んでしまいました。しかし、雑に測ってみると、位置と行の対応をバッファとは別のリストに格納していたのですが、その同期を取るのが遅かったと判明。
位置情報は全体に渡る記録は行わず常にカーソル位置からの差分で計算するのが正。
なおバッファはある既知の一点から前後へ移動しつつのアクセスさえ高速にできるデータ構造であればなんでもよさげ。転送速度さえ間に合うならvectorですらよさげ。ちなみに結局降参して?ギャップバッファにした。
行の管理
一行が可変長のバイナリエディタで行と位置情報の対応を記録しないで済ますにはと試行錯誤の結果、行リストをそもそも使わず副バッファを用意してそこのビットフラグを毎回更新してどんな処理をするにも副バッファをなぞっていくことを決定。
副バッファの構造は主のデータバッファと同じでよいため、行リストのように細切れにならずメモリ効率の改善にも。
色分け
状態遷移をそのまま設定する方式にした。
見出し解析
ちょっとしたスタック型パーサーを設定で作れます…が、本来複雑なルールとなるものをレコードの配列の形に収めるため歪になっています。
Diff
- http://d.hatena.ne.jp/ytqwerty/20040803#p1
- http://d.hatena.ne.jp/ytqwerty/20040807#p1
- http://d.hatena.ne.jp/ytqwerty/20040808#p1
- http://d.hatena.ne.jp/ytqwerty/20040813#p1
- http://d.hatena.ne.jp/ytqwerty/20040813#p2
行単位のDiffでは特に問題もありませんが、最大の敵はバイト単位でDiffを取ったときのメモリ消費量。参照カウンタにより参照されなくなった経路を再利用するのと、固定長アロケータを書くことで対処。
またRuby実装(simple-diff.rb)では連想配列の探索が必要となりこれもボトルネックとなりうるためPukiWiki実装を真似るのがよろしいです。
キーマクロ
結局キー単位でもアクション単位でもなく、編集操作単位。
下基準スクロール
自画自賛。
設定のインポート/エクスポート
結局setting.yaml直接編集推奨になってしまっています…いずれなんとかしたい部分。
→なんとかしました。
Unicode
- http://d.hatena.ne.jp/ytqwerty/20040709#p1
- http://d.hatena.ne.jp/ytqwerty/20040717#p2
- http://d.hatena.ne.jp/ytqwerty/20050523#p1
ほとんどのエディタがUnicode化される昨今、ThebeはSHIFT-JISスピリッツを(略)
現実は、Alphaの開発日誌を読んで、Unicodeをまじめに実装するのは大変だなあ…と思ってしまっただけです。
フォント
過去にはThebe上に似非ClearTypeを実装したこともあります。
ソース紛失により再現不可能ですしWindowsXP以降関係なし。