mlterm-dev-ja — mlterm mailing list(Japanese)

[Mlterm-dev-ja] plan to release 2.4.0

[Araki K. <j00...@ip...>]

	荒木です:-)

        先日来、端末エミュレータでの Bidi の扱いについて取り組んできたのですが、
        先程、カーソル移動の問題など懸案がだいたい片づき、この件につきご協力いた
        だいていた Nadim Shaikli さんより Absolutely no problem と太鼓判を頂くに
        至りました。
        
        というわけで、これを機に、2.4.0 のリリースに向けた準備に入りたいと思いま
        す。大体、27 or 28 日ころを目途にリリースしたいと思っております。

        特に Bidi の表示やカーソル移動について、チェックしてみていただけると
        助かります。

        また、

        http://www.arabeyes.org/archives/developer/2002/March/msg00010.html

        に、Nadim が作られた vim6 の arabic 対応パッチがありますので、README に
        従って、コンパイル、インストールすれば、mlterm 上で、そこそこのアラビア
        語環境が整うはずです。

        また、vim を起動する際、:set arabic は不要です。
        アラビア語入力の際には、:set keymap=arabic してください。
        
	では
--
kiken
j00...@ip...

[Mlterm-dev-ja] transparency is too slow

[Araki K. <j00...@ip...>]

	荒木です:-)

        高橋全さんより、以下のようなレポートをいただいております。

        一つは、背景透過させた mlterm を複数の仮想スクリーンに表示させた上で、仮
        想スクリーンの移動する際に、描画が極端に遅くなるという問題で、もう一つは、
        xsetroot などで背景色を指定する場合に、背景透過した mlterm を起動しようと
        すると、core dump するというものです。

        環境は、

        XFree86 4.1.0
        fvwm2 2.4.2
        mlterm 2.3.1

        だそうです。
        
        が、手元では全く再現できませんので、どなたか、再現できた方がいらっしゃれ
        ば、その環境など教えていただけると助かります。
        また、問題の修正パッチはもちろん、再現できない環境の報告などもいただける
        とありがたいです。

	では
--
kiken
j00...@ip...

=== その壱 ===
2.3.1 です。

デフォルト (~/.mlterm を mv しておいた状態) で
--transbg を付けて「ふたつ以上」起動すると
X の、viewport っていうんでしょうか、画面を
切り換えると、とっても CPU を食ってしまって
使いものになりません。
放っておくと、そのうちに戻ってくるのですが、
それまではマウス以外が動きません。

XFree86-4.1.0 と imlib-1.9.11 です。
DEBUG メッセイジは関係なさそうな感じです。
strace してみても見方がわからず……。(;_;

大きいのですが、strace 結果が
役に立つようであればお送りします。

とりあえず多重起動するときは
透過をやめています。(T_T

=== その弐 ===
そして mlterm --transbg を二回実行して、
ふたつを別々の画面、えーと、workspace, かな？
仮想デスクトップというのかな？
とりあえず右とか下とかの画面に動かします。
ここで「別々の」画面に移動しないと再現しないようです。

そしてひとつの mlterm を表示している状態から
マウスを画面端まで動かして別の画面に移動すると
(そこに mlterm があってもなくても関係なく)
マウスだけ生きていて他の X 関連がすべて停止、
という状態に陥ります。fvwm2 も反応なしです。
Ctrl + Alt + F2 などでは console に戻れます。

そのとき mlterm があっても、透過した背景だけ表示されていて、
font が表示されていません。(あ、font は xfs ではなく X 自体で
プロセスするように、/etc/X11/XF86Config-4 に書いています。
関係ないとは思いますが。)

xclock -update 1 -digital
は同じ時刻を指したまま停止しています。(つまり font は表示されています)

そして数十秒ほど待つと mlterm の font も表示されて
反応が戻り、速度も普通のようになるのです。

また別の画面に行って mlterm のある画面から移動すると
同じ症状を繰り返します。

いまやってみたところ、
一度停止状態から回復した mlterm (a) から別の mlterm (b) の画面に
移動しても停止状態にはなりませんでした。
そしてまた元の mlterm (a) の画面に戻ると再び停止です。

xpmroot や xsetroot での背景指定だと mlterm が
core dump するので (これも問題 ?) Esetroot で指定しています。

=== その参 ===
fvwm2 は 2.4.2 です。
brightness を 100 以外に (輝度調整) しても遅くなります。
(気のせいか、いま調整してやってみたら問題が少し軽減したような……。でも遅い)
Eterm で背景透過していますが、輝度調整してもしなくても問題ありません。

xsetroot は、同様のオプション (-solid gray) でもだめです。起動しません。
xpmroot は、とりあえずなので gnome 付属の yes.xpm でやってみて、だめでした。
で、xpmroot と同じ yes.xpm を Esetroot で指定すれば起動できます。

Re: [Mlterm-dev-ja] ncurses/whiptail/dialog =?ISO-2022-JP?B?GyRCJEdKODt6Mj0kMSQ3JF4kORsoQg==?=

[Tomohiro K. <tk...@ri...>]

久保田です。

At Wed, 20 Mar 2002 17:11:20 +0900,
Araki Ken wrote:

> > 2. 「0」など、ISO-2022 で通常使われない文字集合については、G1 では
> >    なく、特別な場所 (G4 とか?) に指示する。SI/SO は G1 ではなく
> >    G4 を呼び出すようにする。
> >
> > などの解決方法が考えられますが、ISO-2022-CN や ISO-2022-KR で
> > SI/SO が使われているので、だめです。
> 
> enacs=\E)0,smacs=^N,rmacs=^O のケースへの対応パッチです。
> 
> 2 モドキ を採用しました。
> 理由は、
> 
> 1. 一番ラクチン
> 2. この実装であれば、ISO-2022-CN や、ISO-2022-KR でも、\E)0 が流れて
>    くるまでは、正常動作する。
> 3. Locking Shift を使わないエンコーディングなら、害なく、対応できる。
> 
> からです。

動作確認できました。なぜ ISO-2022-CN や ISO-2022-KR でも動くのか
不思議だったんですが、ISO-2022-CN や ISO-2022-KR は、SI/SO を
単独では使わず、G1 に GB2312 や KSX1001 を指示するエスケープ
シーケンスも併用するから大丈夫なんですね。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/

Re: [Mlterm-dev-ja] ncurses/whiptail/dialog =?ISO-2022-JP?B?GyRCJEdKODt6Mj0kMSQ3JF4kORsoQg==?=

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] ncurses/whiptail/dialog で文字化けします
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: Wed, 20 Mar 2002 17:11:20 +0900

>         enacs=\E)0,smacs=^N,rmacs=^O のケースへの対応パッチです。

        すみません、初期化忘れのバグがありました。
        再度パッチを添付します。

	では
--
kiken
j00...@ip...

Re: [Mlterm-dev-ja] ncurses/whiptail/dialog =?ISO-2022-JP?B?GyRCJEdKODt6Mj0kMSQ3JF4kORsoQg==?=

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] ncurses/whiptail/dialog で文字化けします
	From: Tomohiro KUBOTA <tk...@ri...>
	Message-ID: <200...@si...>
	Date: Wed, 20 Mar 2002 02:13:19 +0900

> 2. 「0」など、ISO-2022 で通常使われない文字集合については、G1 では
>    なく、特別な場所 (G4 とか?) に指示する。SI/SO は G1 ではなく
>    G4 を呼び出すようにする。
>
> などの解決方法が考えられますが、ISO-2022-CN や ISO-2022-KR で
> SI/SO が使われているので、だめです。

        enacs=\E)0,smacs=^N,rmacs=^O のケースへの対応パッチです。
        
        2 モドキ を採用しました。
        理由は、

        1. 一番ラクチン
        2. この実装であれば、ISO-2022-CN や、ISO-2022-KR でも、\E)0 が流れて
           くるまでは、正常動作する。
        3. Locking Shift を使わないエンコーディングなら、害なく、対応できる。
        
        からです。

        今更、termcap や terminfo の設定を変更してもらうのは大変ですし、かと
        いって、mlterm というエントリを追加してもらうのは、気が引けますんで、
        この辺が一番いい妥協点かなーとか思います。

        いかがでしょうか?

        # \E)0 以外の enacs がある場合は、この方法では対応できませんので、
        # 知らせてください。

	では
--
kiken
j00...@ip...

Re: [Mlterm-dev-ja] ncurses/whiptail/dialog =?ISO-2022-JP?B?GyRCJEdKODt6Mj0kMSQ3JF4kORsoQg==?=

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] ncurses/whiptail/dialog で文字化けします
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: Wed, 20 Mar 2002 14:53:31 +0900

>         さらにタチの悪いことに、わたしの把握している範囲では、
>         
>         enacs=\E(0
>         (G0に指示)
>         
>         というケースもあるようです。
>         そのため、非ISO2022環境では、これにも対応しております。(ml_vt100_parser.c,l.1624)

        とかいいつつ、手元の termcap には見あたらない...
        どっかで見つけて、enacs=\E(0 かー、なめとんかーとか思った記憶があるんで
        すが、勘違いだったかもしれません _o_
        裏が取れてない話ですので、忘れてください。

	では
--
kiken
j00...@ip...

Re: [Mlterm-dev-ja] ncurses/whiptail/dialog =?ISO-2022-JP?B?GyRCJEdKODt6Mj0kMSQ3JF4kORsoQg==?=

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] ncurses/whiptail/dialog で文字化けします
	From: Tomohiro KUBOTA <tk...@ri...>
	Message-ID: <200...@si...>
	Date: Wed, 20 Mar 2002 02:13:19 +0900

>> curses を使うと、mlterm が文字化けします。ncurses の責任かも
>> しれないので、そちらで試していただけないでしょうか。
>
> 原因が分かりました。terminfo の、
>
> 	enacs=\E)0
>
> というのが、悪さをしているっぽいです。

        さらにタチの悪いことに、わたしの把握している範囲では、
        
        enacs=\E(0
        (G0に指示)
        
        というケースもあるようです。
        そのため、非ISO2022環境では、これにも対応しております。(ml_vt100_parser.c,l.1624)

        ISO2022 パーサを拡張して、GN に alternate character set が指示された
        場合に、その時点での GN の文字集合情報を保持しておき、その後、\E(B や
        \E)B がきて、alternate character set が解除された段階で、保存して
        おいた元の文字集合情報に再設定する、というのが一番無難な方法ですし、
        別にそれでもえっか、とも思ったりしていますが、なんといってもちょっと面
        倒くさいのと、UTF-8 など、非 ISO2022 環境が主流になっていけば、そこで
        は、特に問題にはならないわけですから、いまいちふんぎりがつかないでいます。

        # 今、BIDI のカーソル移動まわりで、かなり面倒な話が持ちあがってまして、
        # 頭を悩ませていますので、対応するにしても、ちょっと後になると思います。

        ところで、TERM=kterm とした場合でも、この問題が発生する環境って存在する
        のでしょうか?

	では
--
kiken
j00...@ip...

Re: [Mlterm-dev-ja] ncurses/whiptail/dialog =?ISO-2022-JP?B?GyRCJEdKODt6Mj0kMSQ3JF4kORsoQg==?=

[Tomohiro K. <tk...@ri...>]

久保田です。

At Wed, 20 Mar 2002 14:31:35 +0900,
Tomohiro KUBOTA wrote:

> 一方、curses を使うと文字化けするというのはちょっと痛いので、短期的
> な手法としては、「0」で表される文字集合への指示を mlterm が無視する、
> というのは、どうでしょうか。現状では mlterm では「0」はサポート
> されていないみたいなので、副作用もありません。将来的に
> termcap/terminfo が改善されたときに初めて「0」をサポートするという
> のでも、いいのではないかと思います。または、そもそもサポートされて
> いない文字集合への指示は、代わりに ASCII への指示とするよりは、無視
> してしまうほうがいいと思うのですが。

すみません、罫線文字集合はサポートされてるみたいですね。
(いま動作確認はできないですが)。

ちなみに、8 ビットエンコーディングは、GL=G0, GR=G1 とする代わりに
GL=G0, GR=G2 とすることで逃げることができます。luit がそのように
している理由も、これだと思います。

EUC-* や ISO-2022-* はこれで逃げられないので、とりあえずは、「0」
文字集合を EUC-* や ISO-2022-* のときだけ無効にするのがいいでしょうか。

にしても、現状では ISO-8859-* も文字化けするのに、バグレポートが
来ないって、ちょっとさびしいな。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/

Re: [Mlterm-dev-ja] ncurses/whiptail/dialog =?ISO-2022-JP?B?GyRCJEdKODt6Mj0kMSQ3JF4kORsoQg==?=

[Tomohiro K. <tk...@ri...>]

久保田です。

At Wed, 20 Mar 2002 02:53:51 +0900 (JST),
sakamoto hironori wrote:

> これについては、以前、指摘したことがあります。
> 無理矢理 ISO 2022 like に拡張しているわけで、
> 根本的には、enacs=, smacs=\E(0, rmacs=\E(B という"無難な"指定の
> mlterm 専用の termcap/terminfo を用意して、TERM=mlterm でアクセス
> すべきです。
> 
> が、xterm,kterm はどちらも認識するので、termcap/terminfo を書き換える
> のがいいかも。

長期的には、xterm の termcap/terminfo を変える (あちこちに頼んで
変えてもらう) のがいいと思います。ほんとうにその「"無難な"指定」で
問題がないか (たとえば、上記指定は GL がいつも G0 を呼び出していて、
G0 がいつも ASCII を指示しているという前提に基づいています)、議論
する必要もあるでしょうし、説得にも時間がかかるでしょうし。

ところで、termcap/terminfo を変えてもらうには、どこに言えばいいの
でしょうか。(Debian だと、ncurses が使われています。他は?)

一方、curses を使うと文字化けするというのはちょっと痛いので、短期的
な手法としては、「0」で表される文字集合への指示を mlterm が無視する、
というのは、どうでしょうか。現状では mlterm では「0」はサポート
されていないみたいなので、副作用もありません。将来的に
termcap/terminfo が改善されたときに初めて「0」をサポートするという
のでも、いいのではないかと思います。または、そもそもサポートされて
いない文字集合への指示は、代わりに ASCII への指示とするよりは、無視
してしまうほうがいいと思うのですが。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/

Re: [Mlterm-dev-ja] ncurses/whiptail/dialog =?ISO-2022-JP?B?GyRCJEdKODt6Mj0kMSQ3JF4kORsoQg==?=

[<hs...@mt...>]

坂本です。

> 久保田です。
> 原因が分かりました。terminfo の、
> 	enacs=\E)0
> というのが、悪さをしているっぽいです。これは、alternate character set

これについては、以前、指摘したことがあります。
無理矢理 ISO 2022 like に拡張しているわけで、
根本的には、enacs=, smacs=\E(0, rmacs=\E(B という"無難な"指定の
mlterm 専用の termcap/terminfo を用意して、TERM=mlterm でアクセス
すべきです。

が、xterm,kterm はどちらも認識するので、termcap/terminfo を書き換える
のがいいかも。
-----------------------------------
坂本 浩則 <hs...@mt...>
 http://www2u.biglobe.ne.jp/~hsaka/

Re: [Mlterm-dev-ja] ncurses/whiptail/dialog =?ISO-2022-JP?B?GyRCJEdKODt6Mj0kMSQ3JF4kORsoQg==?=

[Tomohiro K. <tk...@ri...>]

久保田です。

At Tue, 19 Mar 2002 01:10:08 +0900,
Tomohiro KUBOTA wrote:

> curses を使うと、mlterm が文字化けします。ncurses の責任かも
> しれないので、そちらで試していただけないでしょうか。

原因が分かりました。terminfo の、

	enacs=\E)0

というのが、悪さをしているっぽいです。これは、alternate character set
を使う準備で、これを使っておいて、それから

	smacs=^N

と

	rmacs=^O

を使うと、alternate character set が表示されるというものです。
これは、たとえば、罫線文字の表示などに使われているようです。
ちなみに、terminfo(5) によると、

  snacs は enable alternate character set
  smacs は start alternate character set
  rmacs は end alternate character set

で、

         Glyph              ACS           Ascii         VT100
          Name              Name          Default       Name
------------------------------------------------------------------
   solid square block      ACS_BLOCK        #            0

とのことです。

ところで、この機構は、じつは ISO-2022 の G1 をそのまま使っている
のです。\E)0 は、G1 に「0」を指示するエスケープシーケンスで、
^N と ^O はそれぞれ SO と SI です。

それで、文字化けをどう解決したらいいか、ですが、これが難しい問題です。
というのは、ISO-2022 を正しく解釈すれば、文字化けが必然的に起こって
しまうからです。

1. 「0」で示される alternate character set はサポートせず、無視する。
   また、SI/SO もサポートしない。

   こうすると、罫線文字は化けますが、日本語が化けるよりはましです。
   (というか、いま現在、罫線文字はサポートされていない)。

2. 「0」など、ISO-2022 で通常使われない文字集合については、G1 では
   なく、特別な場所 (G4 とか?) に指示する。SI/SO は G1 ではなく
   G4 を呼び出すようにする。

などの解決方法が考えられますが、ISO-2022-CN や ISO-2022-KR で
SI/SO が使われているので、だめです。


ちなみに、kterm は一見きちんと動いていますが、
TERM=xterm dialog --msgbox あいうえお 8 20
としてやると、ダメダメです。hanterm はきちんと動きます。


さて、どうしましょう?

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/

[Mlterm-dev-ja] ncurses/whiptail/dialog =?ISO-2022-JP?B?GyRCJEdKODt6Mj0kMSQ3GyhC?= =?ISO-2022-JP?B?GyRCJF4kORsoQg==?=

[Tomohiro K. <tk...@ri...>]

どうも。久保田です。

curses を使うと、mlterm が文字化けします。ncurses の責任かも
しれないので、そちらで試していただけないでしょうか。

まずは、EUC-JP で、

dialog --msgbox あいうえお 8 20

とか

whiptail --msgbox あいうえお 8 20

とかを、試してみてください。kterm などでは、正しく日本語の
メッセージボックスが表示されますが、mlterm では、「あいうえお」
の 8 ビット目を落とした文字列「$"$$$&$($*」が表示されます。
そして、それ以降、その mlterm は日本語が表示されなくなります。

次に、以下のプログラムを実行してみてください。やはり、
日本語が表示されず、実行以降は日本語が表示されなくなります。

/* TEST OF NCURSES                         */
/* 1999/9/1 Tomohiro KUBOTA                */
/* cc test1.c -o test1 -lncurses           */

#include <curses.h>

int main(int argc, char **argv)
{
        /* initialize screen */
        initscr();

        /* move to LINES/2, COLS/2 */
        move(LINES/2, COLS/2);

        /* write to screen */
        addstr("あいうえお");

        /* update screen */
        refresh();

/*      getch();*/
        
        /* Lack of this makes the terminal curious! */
        /* Type 'stty sane' to recover! */
/*      endwin();*/
}

また、EUC-JP ばかりではなく、たとえば ISO-8859-1 でも、
8 ビット目が落とされた文字列が表示されるようになってしまいます。

あ、いま試してみると、TERM=kterm のときは大丈夫で、TERM=xterm
だとだめです。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/

Re: [Mlterm-dev-ja] commit log [2002/03/06] (was: mlterm =?iso-2022-jp?b?GyRCJV4lSyVlJSIlayEmJVohPCU4GyhCKQ==?=

[Mike F. <mf...@su...>]

Araki Ken <j00...@ip...> writes:

> 	荒木です:-)
>
> 	Subject: Re: [Mlterm-dev-ja] commit log [2002/03/06] (was: mlterm マニュアル・ページ)
> 	From: Mike Fabian <mf...@su...>
> 	Message-ID: <s3t...@gr...>
> 	Date: Tue, 12 Mar 2002 18:47:41 +0100
>
>> このパッチを当たると、もっと良くなりますが、まだ小さな問題が残って
>> います。scroll_region の高さが２行しかなければ、まだ screen のステータ
>> ス行を上書きする事ができます：
>>
>>     ./mlterm -geometry 80x3
>>     screen
>>
>> 長い 'xxxxxxxxxxxxxxxxxxxxxxxxx ....' のコマンド・ラインを入力しました
>> (150 個の 'x'ぐらい)。行がラップアラウンドする時、screen のステータス
>> 行がまだ上書きされませんが、「return」を押す時、ステータス行が上書きさ
>> れます。ログを添付しました。
>
>         ありがとうございます。
>         CVS に、修正を commit しておきました。
>         修正個所は、大体添付のパッチのような感じです。

どうも有難うございました。現在の CVS バージョンに上のバグがありません。

それでは、

        マイク

-- 
Mike Fabian   <mf...@su...>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。

Re: [Mlterm-dev-ja] Bidi + w3m-m17n(-img)

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] Bidi + w3m-m17n(-img)
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: Thu, 14 Mar 2002 23:21:01 +0900

>> Bidi を有効にして w3m-m17n(-img) を使うと、カーソルのある行の
>> 画像が消えます。一行全部再描画しているためだと思うのですが、
>> 仕方ない(w3m 側で対処すべき)ものなのでしょうか。
>
>         ml_image_line.c の ml_imgline_bidi_visual() における、
>
> 	if( IS_MODIFIED(line->flag))
> 	{
> 		ml_imgline_set_modified( line , 0 , END_CHAR_INDEX(line) , IS_CLEARED_TO_END(line->flag)) ;
> 	}
>
>         の処理をもっと賢くしてやれば、可能です。
>         明日あたりにでも、もう少し書きなおしてみます。

        RTL 文字が含まれていなければ、行全体の再描画は行なわない、というようにしました。
        
        RTL 文字が含まれていた場合、相変わらず、行全体を再描画します。
        というのは、たとえば、

        [logical order]   abc
        [visual order(1)] bac
                   ↓ 一文字 'd' 挿入
        [logical order]   abc*d*
        [visual order(2)] *adbc*

        (** で囲まれている文字が、再描画対象)

        のように、(2) で、再描画対象の再計算を正確に行うには、挿入された 'd' や
        (2) での visual order 情報だけを見ていてもだめで、(1) での visual order
        情報も同時に保持(残)しておかないとならないのですが、それはちょっとコスト
        に見合わないと判断したためです。

        ただ、多分、これでも w3m-img での使用上は、問題ないと思います。

        パッチを添付します。
        この変更は、すでに、CVS repository に反映済みです。

	では
--
kiken
j00...@ip...

Index: src/ml_image_line.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_image_line.c,v
retrieving revision 1.72
diff -u -r1.72 ml_image_line.c
--- src/ml_image_line.c	2002/03/13 10:08:27	1.72
+++ src/ml_image_line.c	2002/03/15 05:37:40
@@ -982,6 +982,7 @@
 {
 	int  counter ;
 	ml_char_t *  src ;
+	int  has_rtl ;
 	
 	if( ! line->visual_order)
 	{
@@ -1008,6 +1009,7 @@
 
 	ml_str_copy( src , line->chars , line->num_of_filled_visual_order) ;
 
+	has_rtl = 0 ;
 	for( counter = 0 ; counter < line->num_of_filled_visual_order ; counter ++)
 	{
 	#ifdef  DEBUG
@@ -1021,12 +1023,17 @@
 		}
 	#endif
 
+		if( counter != line->visual_order[counter])
+		{
+			has_rtl = 1 ;
+		}
+
 		ml_char_copy( &line->chars[line->visual_order[counter]] , &src[counter]) ;
 	}
 
 	ml_str_final( src , line->num_of_filled_visual_order) ;
 
-	if( IS_MODIFIED(line->flag))
+	if( has_rtl && IS_MODIFIED(line->flag))
 	{
 		ml_imgline_set_modified( line , 0 , END_CHAR_INDEX(line) , IS_CLEARED_TO_END(line->flag)) ;
 	}

Re: [Mlterm-dev-ja] Bidi + w3m-m17n(-img)

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: [Mlterm-dev-ja] Bidi + w3m-m17n(-img)
	From: Hironori Sakamoto <hs...@mt...>
	Message-ID: <200...@ud...>
	Date: Thu, 14 Mar 2002 17:13:51 +0900 (JST)

> Bidi を有効にして w3m-m17n(-img) を使うと、カーソルのある行の
> 画像が消えます。一行全部再描画しているためだと思うのですが、
> 仕方ない(w3m 側で対処すべき)ものなのでしょうか。

        ml_image_line.c の ml_imgline_bidi_visual() における、

	if( IS_MODIFIED(line->flag))
	{
		ml_imgline_set_modified( line , 0 , END_CHAR_INDEX(line) , IS_CLEARED_TO_END(line->flag)) ;
	}

        の処理をもっと賢くしてやれば、可能です。
        明日あたりにでも、もう少し書きなおしてみます。
        
        現状では、上記コードより明らかなとおり、bidi を使用する場合、ある行のいずれ
        かの文字に変更操作が加えられると、行全体を再描画しております。
        w3m は、カーソル移動の際に、ただカーソル位置を移動するだけでなく、カーソル
        位置の文字も出力しているようですので、それが変更処理と認識され、行全体が再
        描画されてしまっているのだと思います。

> あと、文字コードに関係なく w3m(-img) でスクロールする時の画像の
> 描画が kterm に比べて若干もたつきます。
> # 高速なグラフィックスカードを使っていると分からない程度ですが。
> w3m 側で無理矢理 XSync() していたりするのが悪いのだと思うのですが、
> やっぱり仕方ない(w3m 側で対処すべき)ものなのでしょうか。

        多分、mlterm 側でも対応できるのだと思いますが、どこをどう直したらよいか、
        今のところ見当がつかない状態です。

        また、手元のマシンで、clock を 130MHz 程度まで落し、XF86Config で
        
Section "Device"
        Identifier  "NeoMagic"
        Driver      "neomagic"
        Option      "noaccel"
EndSection

        と、アクセラレーションを切って、w3m 0.2.3.2 + kterm 6.2.0 と mlterm
        (CVS 版) で比較してみたところでは、全く速度的な差は感じられませんでし
        た。

	では
--
kiken
j00...@ip...

[Mlterm-dev-ja] Bidi + w3m-m17n(-img)

[Hironori S. <hs...@mt...>]

$B:dK\$G$9!#(B

Bidi $B$rM-8z$K$7$F(B w3m-m17n(-img) $B$r;H$&$H!"%+!<%=%k$N$"$k9T$N(B
$B2hA|$,>C$($^$9!#0l9TA4It:FIA2h$7$F$$$k$?$a$@$H;W$&$N$G$9$,!"(B
$B;EJ}$J$$(B(w3m $BB&$GBP=h$9$Y$-(B)$B$b$N$J$N$G$7$g$&$+!#(B

$B$"$H!"J8;z%3!<%I$K4X78$J$/(B w3m(-img) $B$G%9%/%m!<%k$9$k;~$N2hA|$N(B
$BIA2h$,(B kterm $B$KHf$Y$F<c43$b$?$D$-$^$9!#(B
# $B9bB.$J%0%i%U%#%C%/%9%+!<%I$r;H$C$F$$$k$HJ,$+$i$J$$DxEY$G$9$,!#(B
w3m $BB&$GL5M}LpM}(B XSync() $B$7$F$$$?$j$9$k$N$,0-$$$N$@$H;W$&$N$G$9$,!"(B
$B$d$C$Q$j;EJ}$J$$(B(w3m $BB&$GBP=h$9$Y$-(B)$B$b$N$J$N$G$7$g$&$+!#(B
----------------------------------- 
$B:dK\(B $B9@B'(B <hs...@mt...> 
 http://www2u.biglobe.ne.jp/~hsaka/

Re: [Mlterm-dev-ja] commit log [2002/03/06] (was: mlterm =?ISO-2022-JP?B?GyRCJV4lSyVlJSIlayEmJVohPCU4GyhCKQ==?=

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] commit log [2002/03/06] (was: mlterm マニュアル・ページ)
	From: Mike Fabian <mf...@su...>
	Message-ID: <s3t...@gr...>
	Date: Tue, 12 Mar 2002 18:47:41 +0100

> このパッチを当たると、もっと良くなりますが、まだ小さな問題が残って
> います。scroll_region の高さが２行しかなければ、まだ screen のステータ
> ス行を上書きする事ができます：
>
>     ./mlterm -geometry 80x3
>     screen
>
> 長い 'xxxxxxxxxxxxxxxxxxxxxxxxx ....' のコマンド・ラインを入力しました
> (150 個の 'x'ぐらい)。行がラップアラウンドする時、screen のステータス
> 行がまだ上書きされませんが、「return」を押す時、ステータス行が上書きさ
> れます。ログを添付しました。

        ありがとうございます。
        CVS に、修正を commit しておきました。
        修正個所は、大体添付のパッチのような感じです。

	では
--
kiken
j00...@ip...

Index: src/ml_image.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_image.c,v
retrieving revision 1.225
retrieving revision 1.228
diff -u -r1.225 -r1.228
--- src/ml_image.c	2002/03/12 10:07:36	1.225
+++ src/ml_image.c	2002/03/13 14:25:25	1.228
@@ -92,7 +92,6 @@
 {
 	int  bol ;		/* index of the beginning of line */
 	u_int  row ;
-	u_int  line_len ;
 	u_int  line_cols ;
 	int  counter ;
 	u_int  scroll_size ;
@@ -117,86 +116,44 @@
 	line_cols = 0 ;	
 	while( 1)
 	{
-		if( line_cols + ml_char_cols( &chars[counter]) > image->model.num_of_cols)
+		if( counter > bol &&
+			line_cols + ml_char_cols( &chars[counter]) > image->model.num_of_cols)
 		{
-			/* wraparound line */
-
-			/* excluding this char */
-			line_len = counter - bol ;
-			
-			if( line_len > image->model.num_of_cols)
-			{
-			#ifdef  DEBUG
-				kik_warn_printf( KIK_DEBUG_TAG 
-					" line len %d is over ml_image_t::num_of_cols %d" ,
-					line_len , image->model.num_of_cols) ;
-			#endif
-
-				line_len = image->model.num_of_cols ;
-
-			#ifdef  DEBUG
-				kik_msg_printf( " ... modified -> %d\n" , line_len) ;
-			#endif
-			}
-			
-			ml_line_hints_add( &image->line_hints , bol , line_len , line_cols) ;
+			/*
+			 * line length is 'counter - bol' for the character at 'counter'
+			 * position to be excluded.
+			 */
+			ml_line_hints_add( &image->line_hints , bol , counter - bol , line_cols) ;
 
-			if( row > image->scroll_region_end)
+			if( row ++ >= image->scroll_region_end)
 			{
 				scroll_size ++ ;
 			}
-
-			row ++ ;
 			
 			bol = counter ;
 			line_cols = 0 ;
 		}
-		
-		line_cols += ml_char_cols( &chars[counter]) ;
-		
-		if( ++ counter >= num_of_chars)
+		else
 		{
-			if( counter > bol)
-			{
-				line_len = counter - bol ;
-				
-				if( line_len > image->model.num_of_cols)
-				{
-				#ifdef  DEBUG
-					kik_warn_printf( KIK_DEBUG_TAG 
-						" line len %d is over ml_image_t::num_of_chars %d" ,
-						line_len , image->model.num_of_cols) ;
-				#endif
-
-					line_len = image->model.num_of_cols ;
-
-				#ifdef  DEBUG
-					kik_msg_printf( "... modified -> %d\n" , line_len) ;
-				#endif
-				}
-				
-				/* last line is not completely filled */
+			line_cols += ml_char_cols( &chars[counter]) ;
 
-				ml_line_hints_add( &image->line_hints , bol , line_len , line_cols) ;
+			if( ++ counter >= num_of_chars)
+			{
+				ml_line_hints_add( &image->line_hints , bol , counter - bol , line_cols) ;
 
-				if( row >= image->model.num_of_rows)
+				if( scroll_size)
 				{
-					scroll_size ++ ;
+					if( ! ml_imgscrl_scroll_upward( image , scroll_size))
+					{
+					#ifdef  DEBUG
+						kik_warn_printf( KIK_DEBUG_TAG
+							" ml_imgscrl_scroll_upward failed.\n") ;
+					#endif
+					}
 				}
-			}
 
-			if( scroll_size)
-			{
-				if( ! ml_imgscrl_scroll_upward( image , scroll_size))
-				{
-				#ifdef  DEBUG
-					kik_warn_printf( KIK_DEBUG_TAG
-						" ml_imgscrl_scroll_upward failed.\n") ;
-				#endif
-				}
+				return  1 ;
 			}
-			
-			return  1 ;
 		}
 	}
 }
@@ -204,6 +161,7 @@
 static int
 overwrite_lines(
 	ml_image_t *  image ,
+	int *  cursor_index ,
 	ml_char_t *  chars ,
 	u_int  num_of_chars
 	)
@@ -212,6 +170,10 @@
 	int  current_row ;
 	int  beg_char_index ;
 	u_int  num_of_lines ;
+	ml_image_line_t *  line ;
+	int  beg_of_line ;
+	u_int  len ;
+	u_int  cols ;
 	
 	if( ! render_chars( image , image->cursor.row , chars , num_of_chars))
 	{
@@ -236,30 +198,15 @@
 	/* all changes should happen after cursor */
 	beg_char_index = image->cursor.char_index ;
 
-	while( 1)
+	while( ml_line_hints_at( &image->line_hints , &beg_of_line , &len , &cols , counter))
 	{
-		ml_image_line_t *  line ;
-		int  beg_of_line ;
-		u_int  len ;
-		u_int  cols ;
-
-		if( ! ml_line_hints_at( &image->line_hints , &beg_of_line , &len , &cols , counter))
+		if( counter == 0)
 		{
-		#ifdef  DEBUG
-			kik_warn_printf( KIK_DEBUG_TAG " ml_line_hints_at(%d) failed.\n" , counter) ;
-		#endif
-			
-			continue ;
-		}
-
-		if( beg_of_line >= num_of_chars)
-		{
-		#ifdef  DEBUG
-			kik_warn_printf( KIK_DEBUG_TAG " beg_of_line %d is over num_of_chars %d.\n" ,
-				beg_of_line , num_of_chars) ;
-		#endif
-			
-			return  0 ;
+			/*
+			 * adjusting cursor_index
+			 * excluding scrolled out characters.
+			 */
+			*cursor_index -= beg_of_line ;
 		}
 
 		line = ml_imgmdl_get_line( &image->model , current_row) ;
@@ -884,7 +831,7 @@
 	 */
 
 	/* overwriting lines with scrolling */
-	overwrite_lines( image , buffer , filled_len) ;
+	overwrite_lines( image , &cursor_index , buffer , filled_len) ;
 
 	ml_str_final( buffer , buf_len) ;
 
Index: src/ml_image_scroll.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_image_scroll.c,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- src/ml_image_scroll.c	2002/03/12 10:07:36	1.53
+++ src/ml_image_scroll.c	2002/03/13 14:25:25	1.54
@@ -134,6 +134,10 @@
 			}
 		}
 
+		image->cursor.row = boundary_beg ;
+		image->cursor.col = 0 ;
+		image->cursor.char_index = 0 ;
+
 		return  ml_image_clear_lines( image , boundary_beg , boundary_end - boundary_beg + 1) ;
 	}
 	
@@ -229,6 +233,10 @@
 		 * all lines within boundary are scrolled out.
 		 */
 
+		image->cursor.row = boundary_end ;
+		image->cursor.col = 0 ;
+		image->cursor.char_index = 0 ;
+		
 		return  ml_image_clear_lines( image , boundary_beg , boundary_end - boundary_beg + 1) ;
 	}
 

Re: [Mlterm-dev-ja] commit log [2002/03/06] (was: mlterm =?iso-2022-jp?b?GyRCJV4lSyVlJSIlayEmJVohPCU4GyhCKQ==?=

[Mike F. <mf...@su...>]

Araki Ken <j00...@ip...> writes:

> 	荒木です:-)
>
> 	Subject: Re: [Mlterm-dev-ja] commit log [2002/03/06] (was: mlterm マニュアル・ページ)
> 	From: Mike Fabian <mf...@su...>
> 	Message-ID: <s3t...@gr...>
> 	Date: Tue, 12 Mar 2002 17:40:51 +0100
>
>> やってみました。ログが添付されています。
>
>         ありがとうございます。
>         すみません、いただいたログをみてはじめて、大馬鹿をやっていたことに気づき
>         ました _o_
>         添付のパッチを CVS current に当てていただければ、直るんじゃないかと思いま
>         す。

このパッチを当たると、もっと良くなりますが、まだ小さな問題が残って
います。scroll_region の高さが２行しかなければ、まだ screen のステータ
ス行を上書きする事ができます：

    ./mlterm -geometry 80x3
    screen

長い 'xxxxxxxxxxxxxxxxxxxxxxxxx ....' のコマンド・ラインを入力しました
(150 個の 'x'ぐらい)。行がラップアラウンドする時、screen のステータス
行がまだ上書きされませんが、「return」を押す時、ステータス行が上書きさ
れます。ログを添付しました。

Re: [Mlterm-dev-ja] commit log [2002/03/06] (was: mlterm =?ISO-2022-JP?B?GyRCJV4lSyVlJSIlayEmJVohPCU4GyhCKQ==?=

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] commit log [2002/03/06] (was: mlterm マニュアル・ページ)
	From: Mike Fabian <mf...@su...>
	Message-ID: <s3t...@gr...>
	Date: Tue, 12 Mar 2002 17:40:51 +0100

> やってみました。ログが添付されています。

        ありがとうございます。
        すみません、いただいたログをみてはじめて、大馬鹿をやっていたことに気づき
        ました _o_
        添付のパッチを CVS current に当てていただければ、直るんじゃないかと思いま
        す。
        
	では
--
kiken
j00...@ip...

Index: src//ml_image.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_image.c,v
retrieving revision 1.225
diff -u -r1.225 ml_image.c
--- src//ml_image.c	2002/03/12 10:07:36	1.225
+++ src//ml_image.c	2002/03/12 16:54:17
@@ -141,7 +141,7 @@
 			
 			ml_line_hints_add( &image->line_hints , bol , line_len , line_cols) ;
 
-			if( row > image->scroll_region_end)
+			if( row >= image->scroll_region_end)
 			{
 				scroll_size ++ ;
 			}

Re: [Mlterm-dev-ja] commit log [2002/03/06] (was: mlterm =?iso-2022-jp?b?GyRCJV4lSyVlJSIlayEmJVohPCU4GyhCKQ==?=

[Mike F. <mf...@su...>]

Araki Ken <j00...@ip...> writes:

>         もしよろしければ、src/ml_vt100_parser.c の先頭の __DEBUG , ESCSEQ_DEBUG
>         マクロを define してビルドし、mlterm 2> log.txt のように、問題が発生する
>         まで実行して、その際の標準エラー出力をログに取ってみていただけませんでし
>         ょうか?

やってみました。ログが添付されています。

Re: [Mlterm-dev-ja] Re: core dump around bidi

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: [Mlterm-dev-ja] Re: core dump around bidi
	From: Hironori Sakamoto <hs...@mt...>
	Message-ID: <200...@ud...>
	Date: Tue, 12 Mar 2002 22:25:28 +0900 (JST)

>> また、Nadim Shaikli さんの助言に基づいて、Bidi まわりにかなり大きな修正(*)
>> を加えているのですが、どうも現在の CVS 版では、アラビア文字を表示した際に、
>> core dump してしまうようです(**)。
>
> 以下の patch を当てないと私の環境でも落ちました。

        今までたまたま動いてただけで、明かなバグですね。
        ありがとうございます _o_

        # なぜ、わたしの環境では落ちないのかしら...

        これで正常動作するかどうか、Shaikli さんにも伺ってみます。

	では
--
kiken
j00...@ip...

[Mlterm-dev-ja] Re: core dump around bidi

[Hironori S. <hs...@mt...>]

$B:dK\$G$9!#(B

> $B9SLZ$G$9(B:-)
> $B$^$:!"$5$-$[$I!"(Bml_image* $B<~$j$N4pK\E*$J%G!<%?9=B$$KBgI}$K<j$r2C$($^$7$?!#(B
> $B$3$N$?$a!"9-HO0O$K$o$?$C$F!"IT6q9g$,H/@8$9$k2DG=@-$,$"$j$^$9!#(B
> $B%F%9%H$7$F$_$F$$$?$@$1$k$H=u$+$j$^$9!#(B
> $B$^$?!"(BNadim Shaikli $B$5$s$N=u8@$K4p$E$$$F!"(BBidi $B$^$o$j$K$+$J$jBg$-$J=$@5(B(*)
> $B$r2C$($F$$$k$N$G$9$,!"$I$&$b8=:_$N(B CVS $BHG$G$O!"%"%i%S%"J8;z$rI=<($7$?:]$K!"(B
> core dump $B$7$F$7$^$&$h$&$G$9(B(**)$B!#(B

$B0J2<$N(B patch $B$rEv$F$J$$$H;d$N4D6-$G$bMn$A$^$7$?!#(B
----------------------------------- 
$B:dK\(B $B9@B'(B <hs...@mt...> 
 http://www2u.biglobe.ne.jp/~hsaka/

--- src/ml_char.c.orig	Tue Mar 12 22:13:52 2002
+++ src/ml_char.c	Tue Mar 12 22:14:45 2002
@@ -418,12 +418,12 @@
 	ml_char_t *  src
 	)
 {
-	ml_char_final( dst) ;
-
 	if( dst == src)
 	{
 		return  0 ;
 	}
+
+	ml_char_final( dst) ;
 	
 	memcpy( dst , src , sizeof( ml_char_t)) ;
 

[Mlterm-dev-ja] core dump around bidi

[Araki K. <j00...@ip...>]

	荒木です:-)

        まず、さきほど、ml_image* 周りの基本的なデータ構造に大幅に手を加えました。
        このため、広範囲にわたって、不具合が発生する可能性があります。
        テストしてみていただけると助かります。

        また、Nadim Shaikli さんの助言に基づいて、Bidi まわりにかなり大きな修正(*)
        を加えているのですが、どうも現在の CVS 版では、アラビア文字を表示した際に、
        core dump してしまうようです(**)。

        手元で再現できないので、困っているのですが、どなたか、再現できた方はいらっしゃ
        いますでしょうか?

        (*)
        entered      displayed
        ----------------------
        LAM-ALEF --> LAA
        のような場合への対応、および、デフォルトの左寄せ表示以外に、右寄せ表示にも
        対応。

        (**)
#0  0x1dc94 in draw_str (win=0x5c728, updated_width=0xffbeee54,
    chars=0x134ab0, num_of_chars=80, x=0, y=0, height=20,
    std_height_to_baseline=16) at ml_window.c:755
755             if( win->font == NULL || font->xfont->fid !=
win->font->xfont->fid)
(gdb) where
#0  0x1dc94 in draw_str (win=0x5c728, updated_width=0xffbeee54,
    chars=0x134ab0, num_of_chars=80, x=0, y=0, height=20,
    std_height_to_baseline=16) at ml_window.c:755
#1  0x20b80 in ml_window_draw_str_to_eol (win=0x5c728, chars=0x134ab0,
    num_of_chars=80, x=0, y=0, height=20, height_to_baseline=378664)
    at ml_window.c:3343
#2  0x28ce4 in draw_line (termscr=0x5c728, line=0x122980, y=0)
    at ml_term_screen.c:268
#3  0x29148 in redraw_image (termscr=0x5c728) at ml_term_screen.c:522
#4  0x2d39c in ml_term_screen_stop_vt100_cmd (termscr=0x5c728)
    at ml_term_screen.c:4828
#5  0x272d8 in ml_parse_vt100_sequence (vt100_parser=0x128920)
    at ml_vt100_parser.c:2453
#6  0x37f40 in receive_next_event (term_man=0xffbef208)
    at ml_term_manager.c:1818
#7  0x3883c in ml_term_manager_event_loop (term_man=0xffbef208)
    at ml_term_manager.c:2338
#8  0x309c0 in main (argc=1, argv=0xffbef404) at main.c:51
(gdb)        
        
	では
--
kiken
j00...@ip...

Re: [Mlterm-dev-ja] commit log [2002/03/06] (was: mlterm =?ISO-2022-JP?B?GyRCJV4lSyVlJSIlayEmJVohPCU4GyhCKQ==?=

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] commit log [2002/03/06] (was: mlterm マニュアル・ページ)
	From: Mike Fabian <mf...@su...>
	Message-ID: <s3t...@gr...>
	Date: Mon, 11 Mar 2002 00:58:54 +0100

> TERM の環境変数が本当に影響を与えますか。screen の中には、通常
> TERM=screen です。

        とりあえず、念のため書いてみただけですので、私もTERM 環境変数による違
        いはないと思います。
        こちらで再現できないのは、terminfo と termcap の違いのせいでしょうね。

> 今、cvs update をしました。荒木さんがパッチもう commit しましたようで
> す。

        いずれにせよ、この問題とは関係なしに、それまでのスクロール方法が xterm の
        仕様に準拠していなかったので、それを修正するという目的で commit してしまい
        ました。

> 次の部分以外、パッチの変更が現在の cvs にあるようです。
>
>> +	/*
>> +	 * The size of line_hints is scrollable region.
>> +	 * Default value is all screen. See ml_image_init() and ml_image_resize().
>> +	 */
>> +	ml_line_hints_final( &image->line_hints) ;
>> +	ml_line_hints_init( &image->line_hints , end - beg + 1) ;

        これは、現在の CVS 版では、不要となっております。

> 現在の cvs バージョンをコンパイルしてみました。問題はまだ解決されてい
> ないようです。mlterm に screen を実行して、プロンプトが screen のステー
> タス行の上にあるまで 「return」をおしました。その時 'xxxxxxxxxxxxxxx'
> を入力すると、screen のステータス行がまだ上書きされます：

        うーん、まだ直りませんか。
        すみませんが、それでも直らないとしますと、わたしもちょっと原因の想像がつ
        きません。

        もしよろしければ、src/ml_vt100_parser.c の先頭の __DEBUG , ESCSEQ_DEBUG
        マクロを define してビルドし、mlterm 2> log.txt のように、問題が発生する
        まで実行して、その際の標準エラー出力をログに取ってみていただけませんでし
        ょうか?
        
	では
--
kiken
j00...@ip...

Re: [Mlterm-dev-ja] commit log [2002/03/06] (was: mlterm =?iso-2022-jp?b?GyRCJV4lSyVlJSIlayEmJVohPCU4GyhCKQ==?=

[Mike F. <mf...@su...>]

Araki Ken <j00...@ip...> writes:

>         多分、手元の termcap の設定と fabian さんの terminfo の設定の違いのせい
>         だと思いますが、手元では、TERM=xterm,TERM=kterm いずれの場合でも、この
>         ような現象は再現できませんでした。

TERM の環境変数が本当に影響を与えますか。screen の中には、通常
TERM=screen です。

   export TERM=xterm

を使用しても、問題は同じです。

>         ただ、原因は、だいたい想像がつきますので、添付のパッチのような修正を加え
>         てみました。
>
>         これで、正常に動作するか確かめていただけると幸いです。

今、cvs update をしました。荒木さんがパッチもう commit しましたようで
す。次の部分以外、パッチの変更が現在の cvs にあるようです。

> +	/*
> +	 * The size of line_hints is scrollable region.
> +	 * Default value is all screen. See ml_image_init() and ml_image_resize().
> +	 */
> +	ml_line_hints_final( &image->line_hints) ;
> +	ml_line_hints_init( &image->line_hints , end - beg + 1) ;

現在の cvs バージョンをコンパイルしてみました。問題はまだ解決されてい
ないようです。mlterm に screen を実行して、プロンプトが screen のステー
タス行の上にあるまで 「return」をおしました。その時 'xxxxxxxxxxxxxxx'
を入力すると、screen のステータス行がまだ上書きされます：

http://www.suse.de/~mfabian/screenshots/mlterm-screen.png
http://www.suse.de/~mfabian/screenshots/mlterm-screen-2.png

荒木さんのパッチにあった以下のラインを現在の cvs バージョンに追加して
も同じです；

> +	ml_line_hints_final( &image->line_hints) ;
> +	ml_line_hints_init( &image->line_hints , end - beg + 1) ;

-- 
Mike Fabian   <mf...@su...>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。