Re: display version for w3m-0.2.1

[Kiyokazu SUTO <suto@xxxxxxxxxxxxxxx>]

Citation (with leading "> " of each line) from article:
  <200103260346.MAA12864@udlew10.uldev.lsi.nec.co.jp>
    by Hironori Sakamoto <h-saka@lsi.nec.co.jp> :
> で、-backend なんですが w3m.el はそちらが本線なのでしょうか？

今の実装は-dump_head＋-dump_source＋-halfdumpという組み合わせを使って
ますね。

# だからあるページを見るとHEADとGETを両方必ず送ってくる、サーバを管理
# する側としてはあまり嬉しくないブラウザになってます。

この実装や土屋さんのオリジナルのbackend patchの問題点が
[emacs-w3m:00218]にリストされています。このうち幾つかはw3m側で対処しな
いとどうしようもないので(backend patchのような形になるかどうかはともか
く)w3m側を変更しない限り、いずれはw3を再発明するようなことになるんじゃ
ないかと思います。

> 私がしぶっていた理由の一つは、固まっていない状態で本体に入ると
> 逆に w3m.el 側の開発の足枷になりそうだったから。
> また、どうしても必要なら w3m への patch とともに w3m.el を
> 配布すると思ったから。(だから必須じゃないんだと思ってました。)
> w3m.el の動作を知らなくても w3m-dev 側でメンテできる状態になるまでは
> (基本的なプロトコルが固まるまでは) w3m.el 側で開発をして欲しかった。

実際にbackend patchをいじってみてわかったけど、emacs-w3mで必要な機能を
追加しようと思うとw3mのかなり深いところまで入りこんでいかないといけな
くなるんですよ。だからemacs-w3mとセットで両方開発すると、どっちにも中
途半端に労力を取られて、いつまでも使えるものが出てこないようなことになっ
ていたんじゃないかな。

私は並列動作に使えると思ったのと

> w3m-m17n や w3mmee を想定すると内部コードや entity の扱いに関しても、
> 内部コードのまま出すかクライアントからの指定で選択するか
> 決めてもらえると、entity や NBSP や #undef KANJI_SYMBOL の時の
> <RULE>..</RULE> に関しても対処はできると思いますよ。

このあたりのことがあるので、backend patchにw3m{,mee}側での十分なメリッ
トを感じて手を出すことにしたんですけどね。

# 今のemacs-w3mの実装だと、Mule-UCS上ででも使わない限り、w3mmeeをw3mの
# 替わりに使うメリットが全然無いし。

-- 
須藤 清一 <suto@ks-and-ks.ne.jp>
http://pub.ks-and-ks.ne.jp/pgp-public-key.html