w3m の個人的な TODO
Last update: 2001/10/03
私の w3m への個人的な TODO (というか Wish List^^;) です。
個人的に欲しい程度を ☆ の数で表しています。
★ になっているのは完成度(初期検討も含む)です。
(注意)
これらは個人的なものなので
作者の aito さんや開発グループの考えとは無関係です。
また、私が実装する予定があるわけでもありませんし、
現時点で実装できるスキルがあるわけでもありません。
実装しても取り込んでもらえない(;_;)可能性もあります。
当然、実装してくれる方は大歓迎です！
誰か JavaScript 対応を進めてください。
w3m-m17n として開発中です。
開発ポリシーとして、以下を念頭に置いてます。
- パフォーマンス
- オリジナル版に対して(特に日本語を扱った場合に)、
速度や必要とするメモリといった
パフォーマンスをできるだけ落さない。
→ 現時点で 10～20% down くらい。限界か…
- 文字コード
- ISO-2022 と ISO-10646(≒Unicode)
の双方をまともに扱える様にする。
また各種 CodePage や CJK の拡張文字コード(GBK,UHC,...)にも対応可能な枠組を提供する。
→ Shift_JISX0213,GBK,UHC,GB18030 は現在対応中。
さらに結合文字を扱える枠組も提供する
→ タイ語やベトナム語では動いていますが、
インドや中東の諸言語ではどうなるか分かりません。
表示できないし表示できても理解できないので……
Native のサポートが必要と思っています。
- 汎用性、拡張性
- 文字コード処理部(iconv 相当)と内部コードを扱う部分を
w3m 本体からできるだけ分離する。
理由は、
将来的に glibc-iconv や
citrus
を使える余地を残しておくためと、
今後でてくるかもしれない新しい文字コードや Unicode の更新
に対応して内部コードの拡張を楽にするため。
→ 基本的にそうしているのですが、
文字コードの規格のデタラメ(?)につき合った結果、
完全な分離は不可能でした。
- 設定の簡易化
- 端末(kterm,xterm-utf8,...)の font 等の設定は仕方ないと思うが、
基本的にオプション選択でなんとかなるようにする。
→ 日本語で使う場合は、まあデフォルト設定で問題ないはず。
- 安定化
- まあ、当り前。
→ 実は w3m-dev ML の patch を追っているので、
現時点ではオリジナルより安定してたりする :-)。
※) 勉強不足ゆえの問題点はあるでしょうが、
個人的にはそれなりに出来ているんではと思っています。
基本的に、マルチリンガル化(M17N)のメドがついてから実装する予定です。
国際化の主要な要素である NLS (Native Language System) については、
GNU-gettext や POSIX-catgets
を使うか、自前で実装するかちょっと迷っています。
おそらく、現時点で w3m の最大の欠点が
JavaScript に対応していないことだと思っています。
そこで、NJS JavaScript Interpreter を用いての実装を始めてみました。
まだ、全く使いものにはなりませんが、
一緒に開発してくれる方を募集中です。
最新版は ここ にあります。
w3m-img として開発中です。
w3m の MGL 版
に刺激されてテスト開始。
インライン画像の表示に関しては、
XEmacs/w3m.el
で既に実現されていたけれど、
まさか kterm 上などで実用に耐えるだけのものになるとは思わなかった。
開発途中で感動したことが何度もあった。
HTML ページャとは必要な部分だけ HTML レンダリングして表示する機能です。
現行では HTML 文書を全て中間表現にレンダリングしてからテキストにしているのを、
中間表現にレンダリングできた行から逐次テキストにして表示するわけです。
実装されれば、表示のスピードが劇的にアップすると思われます。
ただし、ローカルファイルの場合は問題はないのですが、
ネット上の文書の場合、別プロセスで(もしくは別スレッドで、
もしくはシグナルハンドラを駆使して)
バッググラウンドでファイルをダウンロードする機能と組み合わせないと
いけないと思われるので、かなり大改造になると思われます。
対応して欲しい人もいるようですが、
基本的にグラフィカルブラウザ用にカスタマイズされたものが多いので、
下手をするとより表示が悪化しそう。
しばらくは(？)必要ないでしょう。
![[update]](../images/update.png)