Re: [w3m-dev 01836] Re: display version for w3m-0.2.1

[Hironori Sakamoto <h-saka@xxxxxxxxxxxxx>]

坂本です。
# emacs-w3m@namazu.org へも投稿しておきます。

 >> From: Kiyokazu SUTO <suto@ks-and-ks.ne.jp>
 >> Subject: [w3m-dev 01836] Re: display version for w3m-0.2.1
詳細にどうも。頭の中がかなりクリアになりました。＞ SUTO さん

 >> halfdump imageをバッファ毎に抱えておくように変更してしまえば意味は無い
 >> んですが、そうすると今度はどうやって持っておくかという問題が。
buf->lineBuf でもに入れておけばいいと思いますが。
# cache ファイルでもいいと思うけど。

====
 >>   http://namazu.org/~tsuchiya/emacs-w3m/

ちらっと見て
 > Win32のw3mは-dump_sourceの出力をご丁寧にCRLFにして出してくれます。:-(
というのがあったのですがこれはバグです。
# text/binary を気にしてないのは他にもあるかもしれない。
# [w3m-dev 01411] である程度は問題なくなっているはずだが。

 >> 経由で投稿が読めるし、坂本さんが積極的にコミットしてくれたらemacs-w3m
 >> の開発グループとしても嬉しいんじゃないかな。

emacs 使わないからなぁ。lisp 読めないし…
いちおう subscribe しましたが、w3m 本体に関わることは w3m-dev(-en) ML
にもください。

で、-backend なんですが w3m.el はそちらが本線なのでしょうか？

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

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

また、form に関しては通常の HTML と同じ形式(に fid を加えた形)で
出した方がいいのではないかと思います。
----------------------------------- 
坂本 浩則 <hsaka@mth.biglobe.ne.jp> 
 http://www2u.biglobe.ne.jp/~hsaka/