Thread: [Mlterm-dev-ja] commit log [2001/12/25]

	Hi,

        I committed changes below.
        
* wraparound word can be selected.
* mlterm core dumps if XMODIFIERS variable is empty or illegal value. fixed.

--
kiken
j00...@ip...

	荒木です:-)

        commit log です。

* memory leaks if you use both -m and -bi options under utf8 encoding. fixed.
* mkf/mkf_ucs4_xxx.c are thread-safe.
* Shift + Mouse Button operations under console apps useing mouse tracking
  are supported.

        一応、2.1.0 リリース直前の最終ベータだと思っております。
        28 or 29日ころをメドに rel-2_1_0 tag をうつつもりですので、それまでに、コ
        ンパイル&動作確認レポートをいただけると幸いです。

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

南です。

cursesを使うアプリケーションで、画面の一部をスクロールする際に
末尾に一つ余計な改行が挿入されてしまうことがあるようです。

手元では
 biew, lynx -color でスクロールさせていくと表示がずれることがあって、
 w3m-m17n, lynx -nocolor では正常動作しているように見えました。

手が回らなくてあまり追えてないのですが、再現しますでしょうか。

	荒木です:-)

	Subject: [Mlterm-dev-ja] excess linefeed with curses?
	From: MINAMI Hirokazu <mi...@ch...>
	Message-ID: <200...@ch...>
	Date: Wed, 26 Dec 2001 21:17:49 +0900

> cursesを使うアプリケーションで、画面の一部をスクロールする際に
> 末尾に一つ余計な改行が挿入されてしまうことがあるようです。
> 
> 手元では
>  biew, lynx -color でスクロールさせていくと表示がずれることがあって、
>  w3m-m17n, lynx -nocolor では正常動作しているように見えました。

        lynx では、libslang-1.4.4 + lynx-2.8.3 / ncurses-5.3 + lynx-2.8.4 とも、
        表示がずれることはありませんでした。

        # mlterm は、cvs 20011225-2 版 と、cvs 20011226 版で試してみました。

        biew は、NetBSD 1.5 Y current にて、コンパイルが通りませんでしたので、
        テストしておりません_o_

        cursesの種類/バージョン、lynx のバージョン、問題のでるサイトなどの情報を
        いただけると、こちらでも確認できるかもしれません。

        # 引続き、こちらでも試行錯誤しますが、とりあえず、経過報告まで。

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

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] excess linefeed with curses?
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: 26 Dec 2001 23:55:16 +0900

> > cursesを使うアプリケーションで、画面の一部をスクロールする際に
> > 末尾に一つ余計な改行が挿入されてしまうことがあるようです。
>         biew は、NetBSD 1.5 Y current にて、コンパイルが通りませんでしたので、
>         テストしておりません_o_

        packages にありましたので、インストールして使ってみました(with libslang-1.4.4)

        Up/DownキーおよびPageUp/PageDownキーによる画面スクロールで、改行が余計に
        入ってしまうというような症状を再現することはできませんでした;_;

        # mlterm -term xterm 上で、biew を実行しました。

        が、ご指摘いただいた問題以前に、カラー表示させた場合に、空白文字の背景色
        が青色にならないという問題があるみたいですね。

        背景色が青色にならない原因は、biew が、

        +-------------------+
        |abcde*             |
        |                   |
        ("*"はカーソル位置、abcde の背景色は青)

        このような状況で、
        
        ESC [ 8 C

        シーケンスを出すことによって、

        +-------------------+
        |abcde@@@@@@@@*     |
        |                   |
        ("*"はカーソル位置、"@"は、背景色が青の空白、abcde の背景色は青)

        となることを期待している一方で、現状の mlterm では、このような期待に沿え
        る実装にはなっていないためです。
        
        カーソルが動いた領域は片っ端から、ESC [ m で設定した属性に変更せねばなら
        ない、ということっぽいですが、ちゃんと調べていませんので、まだよくわかり
        ません。

        いずれにせよ、この問題については、現時点では見なかったことに致します_o_

        # kterm 上で使うと(mlterm とは症状は異なりますが)発狂しますので、結構ク
        # セのあるソフトのようにも思えますが。

        それから、わたしの手許では、端末タイプが kterm の mlterm 上で実行した場
        合、および、kterm上で実行した場合に、画面の再描画もうまくいかないようで
        すね。画面にゴミが残ってしまいます。
        
	では
--
kiken
j00...@ip...

On 27 Dec 2001 01:52:03 +0900
Araki Ken <j00...@ip...> wrote:

>
>         それから、わたしの手許では、端末タイプが kterm の mlterm 上で実行した場
>         合、および、kterm上で実行した場合に、画面の再描画もうまくいかないようで
>         すね。画面にゴミが残ってしまいます。

lynx 2.8.5-dev + ncurses 5.2 で使っているのですが、
問題が起きるのは端末タイプが kterm の場合のみのようです。

手元の terminfo は infocap kterm で
#       Reconstructed via infocmp from file: /usr/share/terminfo/k/kterm
kterm|kterm kanji terminal emulator (X window system),
        am, eslok, hs, km, mir, msgr, xenl,
        colors#8, cols#80, it#8, lines#24, ncv#3, pairs#64,
        acsc=++\,\,--..00II``aaffgghhjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
        bel=^G, bold=\E[1m, clear=\E[H\E[2J, cr=^M,
        csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
        cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
        cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
        dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M,
        dsl=\E[?H, ed=\E[J, el=\E[K, enacs=, fsl=\E[?F, home=\E[H,
        ht=^I, hts=\EH, il=\E[%p1%dL, il1=\E[L, ind=^J,
        is2=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>, kbs=^H,
        kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
        kdch1=\E[3~, kf1=\E[11~, kf10=\E[21~, kf11=\E[23~,
        kf12=\E[24~, kf13=\E[25~, kf14=\E[26~, kf15=\E[28~,
        kf16=\E[29~, kf17=\E[31~, kf18=\E[32~, kf19=\E[33~,
        kf2=\E[12~, kf20=\E[34~, kf3=\E[13~, kf4=\E[14~,
        kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
        kfnd=\E[1~, kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
        kslt=\E[4~, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM,
        rmacs=\E(B, rmcup=\E[2J\E[?47l\E8, rmir=\E[4l,
        rmkx=\E[?1l\E>, rmso=\E[m, rmul=\E[m,
        rs2=\E7\E[r\E8\E[m\E[?7h\E[?1;3;4;6l\E[4l\E>, sc=\E7,
        setab=\E[4%p1%dm, setaf=\E[3%p1%dm, sgr0=\E[m,
        smacs=\E(0, smcup=\E7\E[?47h, smir=\E[4h, smkx=\E[?1h\E=,
        smso=\E[7m, smul=\E[4m, tbc=\E[3g, tsl=\E[?E\E[?%i%dT,
        u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?1;2c, u9=\E[c,

なのですが、これがいけないということはあり得るでしょうか?

	荒木です:-)

	Subject: [Mlterm-dev-ja] Re: excess linefeed with curses?
	From: MINAMI Hirokazu <mi...@ch...>
	Message-ID: <200...@ch...>
	Date: Thu, 27 Dec 2001 20:30:45 +0900

> lynx 2.8.5-dev + ncurses 5.2 で使っているのですが、
> 問題が起きるのは端末タイプが kterm の場合のみのようです。
>
> 手元の terminfo は infocap kterm で
...

        terminfo でしたか。
        わたしの手許では、termcap を使っておりますので、こちらで問題が再現できな
        い原因は其の辺にありそうですね。

        xterm/kterm の terminfo の差分がわかると助かりますので、xterm の terminfo
        エントリもみせていただけるとありがたいです。

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

On 27 Dec 2001 22:28:14 +0900
Araki Ken <j00...@ip...> wrote:

>         terminfo でしたか。
>         わたしの手許では、termcap を使っておりますので、こちらで問題が再現できな
>         い原因は其の辺にありそうですね。

mlterm --term=xterm と
mlterm --term=kterm で LANG,LC_ALL を ともに ja_JP.eucJP として
lynx の吐くシーケンスを比べてみました。

画面最下行の書き換えで term=xterm(横幅73)では

RECEIVED ESCAPE SEQUENCE: ESC - [ - 30 - m
RECEIVED ESCAPE SEQUENCE: ESC - [ - 47 - m
RECEIVED ESCAPE SEQUENCE: ESC - [ - K
flushing chars(73)...==> [h]%X%%W[o]@ D[p]0:[g]0\F0[m]%%$%2	LL[q]=*N; /=8!: [Delete]=M   <===
DEBUG: [ml_image_overwrite_chars()] overwriting 73 chars at char index 0 col 0 row 29(30/30 len 1) ->  -> char index 73 col 73 row 29(30/30 len 74)

となっているところが term=kterm(横幅80) では

RECEIVED ESCAPE SEQUENCE: ESC - [ - 30 - m
RECEIVED ESCAPE SEQUENCE: ESC - [ - 47 - m
DEBUG: [parse_vt100_escape_sequence()] receiving BS

flushing chars(59)...==> [h]ヘルプ[o]設定[p]印刷[g]移動[m]メイン画面[q]終了 /=検索 [Delete]=履歴       <===
DEBUG: [ml_image_overwrite_chars()] overwriting 59 chars at char index 0 col 0 row 29(30/30 len 80) ->  -> char index 59 col 79 row 29(30/30 len 60)
DEBUG: [ml_cursor_go_back()] going back from 59 29, then ->  -> char index 58 col 78 row 29
DEBUG: [parse_vt100_escape_sequence()] receiving BS

flushing chars(1)...==> <===
DEBUG: [ml_image_overwrite_chars()] overwriting 1 chars at char index 58 col 78 row 29(30/30 len 60) ->  -> char index 59 col 79 row 29(30/30 len 60)
DEBUG: [ml_cursor_go_back()] going back from 59 29, then ->  -> char index 58 col 78 row 29
RECEIVED ESCAPE SEQUENCE: ESC - [ - 4 - h
RECEIVED ESCAPE SEQUENCE: ESC - [ - 4 - l
flushing chars(1)...==> <===
DEBUG: [insert_chars_intern()] inserting 1 chars at char index 58 row 29(30/30 len 60) ->  -> char index 59 row 28(29/30 len 60)

となっていました。
どうやら term=xterm では ESC-[-K で行を空白にしているところを
term=kterm ではスペースを上書きしているようです。

この辺りの処理は追いきれていないのですが、画面の右下角(term=ktermの結果では79,29)
に文字(空白)が描かれたときには無条件で改行されるように処理されてますか?

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] Re: excess linefeed with curses?
	From: MINAMI Hirokazu <mi...@ch...>
	Message-ID: <200...@ch...>
	Date: Fri, 28 Dec 2001 03:31:34 +0900

> mlterm --term=xterm と
> mlterm --term=kterm で LANG,LC_ALL を ともに ja_JP.eucJP として
> lynx の吐くシーケンスを比べてみました。

        ありがとうございます。ご面倒おかけします_o_

> となっているところが term=kterm(横幅80) では
>
....
>
> flushing chars(1)...==> <===
> DEBUG: [insert_chars_intern()] inserting 1 chars at char index 58 row 29(30/30 len 60) ->  -> char index 59 row 28(29/30 len 60)
> 
> となっていました。

> どうやら term=xterm では ESC-[-K で行を空白にしているところを
> term=kterm ではスペースを上書きしているようです。
> 
> この辺りの処理は追いきれていないのですが、画面の右下角(term=ktermの結果では79,29)
> に文字(空白)が描かれたときには無条件で改行されるように処理されてますか?

        無条件というわけではないのですが、このようなシーケンスでは、確かに改行(
        スクロール)されてしまうと思います。

        添付のパッチを src/ml_image.c にあてるとどうなりますでしょうか?

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

Index: ml_image.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_image.c,v
retrieving revision 1.197
diff -u -r1.197 ml_image.c
--- ml_image.c	2001/12/24 17:24:50	1.197
+++ ml_image.c	2001/12/27 18:51:07
@@ -639,22 +642,12 @@
 
 	overwrite_lines( image , buffer , filled_len , 1) ;
 
+	/* this is necessary since insert_chars_intern() should affect only this line */
+	reset_wraparound_checker( image) ;
+
 	/* wraparound_ready_line member is set in this function */
 	get_pos( image , &new_row , &new_char_index , image->cursor.row , 0 ,
 		ml_get_num_of_lines_by_hints( &image->line_hints) + image->cursor.row - 1 , cursor_index) ;
-
-	/* for wraparound line checking */
-	if( image->wraparound_ready_line != NULL)
-	{
-		if( num_of_ins_chars == 1)
-		{
-			ml_char_copy( &image->prev_recv_ch , ins_chars) ;
-		}
-		else
-		{
-			reset_wraparound_checker( image) ;
-		}
-	}
 	
 	cursor_goto_by_char_index( image , new_char_index , new_row , BREAK_BOUNDARY) ;
 

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] Re: excess linefeed with curses?
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: 28 Dec 2001 03:57:50 +0900

>         添付のパッチを src/ml_image.c にあてるとどうなりますでしょうか?

        たびたびすみません、さきほどのパッチは、ちょっとまずいことに気づきましたので、
        このメールに添付しましたパッチでお願い致します_o_

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

--- ml_image.c.orig	Fri Dec 28 04:05:24 2001
+++ ml_image.c	Fri Dec 28 04:05:34 2001
@@ -639,6 +639,9 @@
 
 	overwrite_lines( image , buffer , filled_len , 1) ;
 
+	/* this is necessary before get_pos() since insert_chars_intern() should affect only this line */
+	reset_wraparound_checker( image) ;
+
 	/* wraparound_ready_line member is set in this function */
 	get_pos( image , &new_row , &new_char_index , image->cursor.row , 0 ,
 		ml_get_num_of_lines_by_hints( &image->line_hints) + image->cursor.row - 1 , cursor_index) ;

南です。

On 28 Dec 2001 04:08:11 +0900
Araki Ken <j00...@ip...> wrote:
 
>         添付のパッチを src/ml_image.c にあてるとどうなりますでしょうか?

残念ながら 変化はない(改行されてしまう)ようです。
とりあえず報告まで。

南です。

確認だけですが、

lynx を -color で LANG=ja_JP.eucJP で使っていても
* 起動直後
* mlterm の縦サイズ変更後
は表示がずれないのですが、このときは

flushing chars(34)...==>]移動[m]メイン画面[q]終了 /=検索 [Delete]=履歴 <===
DEBUG: [ml_image_overwrite_chars()] overwriting 34 chars at char index 19 col 26 row 29(30/30 len 73) ->  -> char index 53 col 73 row 29(30/30 len 60)

が送られてました。改行されてしまうときは

flushing chars(59)...==> [h]ヘルプ[o]設定[p]印刷[g]移動[m]メイン画面[q]終了 /=検索 [Delete]=履歴       <===
DEBUG: [ml_image_overwrite_chars()] overwriting 59 chars at char index 0 col 0 row 29(30/30 len 80) ->  -> char index 59 col 79 row 29(30/30 len 60)

が送られていたので、問題を起こすのがここだというのは間違っていないと思います。

	荒木です:-)

        わたしも確認だけですが。

	Subject: Re: [Mlterm-dev-ja] Re: excess linefeed with curses?
	From: MINAMI Hirokazu <mi...@ch...>
	Message-ID: <200...@ch...>
	Date: Fri, 28 Dec 2001 04:58:42 +0900

> 改行されてしまうときは
> flushing chars(59)...==> [h]ヘルプ[o]設定[p]印刷[g]移動[m]メイン画面[q]終了 /=検索 [Delete]=履歴       <===
> DEBUG: [ml_image_overwrite_chars()] overwriting 59 chars at char index 0 col 0 row 29(30/30 len 80) ->  -> char index 59 col 79 row 29(30/30 len 60)
> 
> が送られていたので、問題を起こすのがここだというのは間違っていないと思います。

        はい、わたしもそう思います。
        ここで、画面右下隅にカーソルがきた状態で、このあとに続く

quoted from <200...@ch...>
> flushing chars(1)...==> <===
> DEBUG: [ml_image_overwrite_chars()] overwriting 1 chars at char index 58 col 78 row 29(30/30 len 60) ->  -> char index 59 col 79 row 29(30/30 len 60)
> DEBUG: [ml_cursor_go_back()] going back from 59 29, then ->  -> char index 58 col 78 row 29
> RECEIVED ESCAPE SEQUENCE: ESC - [ - 4 - h
> RECEIVED ESCAPE SEQUENCE: ESC - [ - 4 - l

        ここまではよいとして、

quoted from <200...@ch...>
> flushing chars(1)...==> <===
> DEBUG: [insert_chars_intern()] inserting 1 chars at char index 58 row 29(30/30 len 60) ->  -> char index 59 row 28(29/30 len 60)

        これがあきらかにおかしいのですよね。

        row 29(30/30 len 60) ->  -> row 28(29/30 len 60)

        になっているということは、insert_chars_intern() の間でスクロール処理が行
        われてしまっているという気がするのですが、get_pos() 関数の、

======
        if( IMAGE_LINE(image,end_row).num_of_filled_cols == image->num_of_cols &&
                *char_index > ml_imgline_end_char_index( &IMAGE_LINE(image,end_row)))
        {
                if( image->wraparound_ready_line == &IMAGE_LINE(image,end_row))
                {
                        IMAGE_LINE(image,*row).is_continued_to_next = 1 ;

                        if( *row == image->num_of_rows - 1)
                        {
                                ml_imgscrl_scroll_upward( image , 1) ; <= ココ

                                if( break_row_boundary( image , 1) != 1)
                                {
                                #ifdef  DEBUG
                                        kik_warn_printf( KIK_DEBUG_TAG
                                                " it failed to break_row_boundary.\n") ;
                                #endif

                                        return  0 ;
                                }
                        }
                        else
                        {
                                if( ++ (*row) > END_ROW(image))
                                {
                                        if( break_row_boundary( image , 1) != 1)
                                        {
                                        #ifdef  DEBUG
                                                kik_warn_printf( KIK_DEBUG_TAG
                                                        " it failed to break_row_boundary.\n") ;
                                        #endif

                                                return  0 ;
                                        }
                                }
                        }
======

        ml_imgscrl_scroll_upward( image , 1) が実行されてしまっているのではない
        か、と疑いました。
        
	では
--
kiken
j00...@ip...

南です。

On 28 Dec 2001 05:10:46 +0900
Araki Ken <j00...@ip...> wrote:

>         ml_imgscrl_scroll_upward( image , 1) が実行されてしまっているのではない
>         か、と疑いました。

ここにブレークポイントを仕掛けてみましたが、引っ掛からないようです。
ml_image_scroll_upward も通らないですが、scroll_upward_regionは通っているようです。

mlterm のリサイズ後のような scroll しないときには regionは呼ばれません。

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] Re: excess linefeed with curses?
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: 28 Dec 2001 05:10:46 +0900

        多分、原因分かったと思います。

> quoted from <200...@ch...>
> > flushing chars(1)...==> <===
> > DEBUG: [insert_chars_intern()] inserting 1 chars at char index 58 row 29(30/30 len 60) ->  -> char index 59 row 28(29/30 len 60)
> 
>         これがあきらかにおかしいのですよね。
> 
>         row 29(30/30 len 60) ->  -> row 28(29/30 len 60)
> 
>         になっているということは、insert_chars_intern() の間でスクロール処理が行
>         われてしまっているという気がするのですが、get_pos() 関数の、
...
>         ml_imgscrl_scroll_upward( image , 1) が実行されてしまっているのではない
>         か、と疑いました。

        ml_imgscrl_scroll_upward() が実行されてしまうというのは正しかったと思いま
        すが、これが実行されるのは、render_chars() 関数の中でだと思います。

        添付のパッチで解決しますでしょうか?

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

Index: ml_image.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_image.c,v
retrieving revision 1.197
diff -u -r1.197 ml_image.c
--- ml_image.c	2001/12/24 17:24:50	1.197
+++ ml_image.c	2001/12/27 20:37:48
@@ -189,7 +189,8 @@
 	ml_image_t *  image ,
 	int  start_row ,
 	ml_char_t *  chars ,
-	u_int  num_of_chars
+	u_int  num_of_chars ,
+	int  do_scroll
 	)
 {
 	int  bol ;		/* index of the beginning of line */
@@ -275,7 +276,7 @@
 				}
 			}
 
-			if( scroll_size)
+			if( do_scroll && scroll_size)
 			{
 				ml_imgscrl_scroll_upward( image , scroll_size) ;
 			}
@@ -290,7 +291,8 @@
 	ml_image_t *  image ,
 	ml_char_t *  chars ,
 	u_int  num_of_chars ,
-	u_int  max_lines
+	u_int  max_lines ,
+	int  do_scroll
 	)
 {
 	int  counter ;
@@ -298,7 +300,7 @@
 	int  beg_char_index ;
 	u_int  num_of_lines ;
 	
-	if( ! render_chars( image , image->cursor.row , chars , num_of_chars))
+	if( ! render_chars( image , image->cursor.row , chars , num_of_chars , do_scroll))
 	{
 		return  0 ;
 	}
@@ -636,8 +641,11 @@
 	/*
 	 * overwriting.
 	 */
+
+	overwrite_lines( image , buffer , filled_len , 1 , 0) ;
 
-	overwrite_lines( image , buffer , filled_len , 1) ;
+	/* this is necessary before get_pos() since insert_chars_intern() should affect only this line */
+	reset_wraparound_checker( image) ;
 
 	/* wraparound_ready_line member is set in this function */
 	get_pos( image , &new_row , &new_char_index , image->cursor.row , 0 ,
@@ -1192,7 +1200,7 @@
 	 * overwriting
 	 */
 
-	overwrite_lines( image , buffer , filled_len , image->num_of_rows) ;
+	overwrite_lines( image , buffer , filled_len , image->num_of_rows , 1) ;
 
 	/* wraparound_ready_line member is set in this function */
 	get_pos( image , &new_row , &new_char_index , image->cursor.row , 0 ,

	荒木です:-)

        commit log です。

* screen can be scrolled when characters are inserted at the end of screen. fixed.

	Subject: Re: [Mlterm-dev-ja] Re: excess linefeed with curses?
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: 28 Dec 2001 05:43:18 +0900

>         多分、原因分かったと思います。

        これで正解でした。
        御協力いただきありがとうございました_o_ > 南さん
        
        実際に commit したものは、さきほどのパッチとは異なりますが、問題は修正で
        きていると思います。

        試してみていただけると幸いです。

        あとは、HP-UX + kinput2 問題だけですね。
        ただ、申し訳ありませんが、こちらでは、当面、remote 接続でないケースでの
        テストが行える状況にありません。
        もし、坂本さんの方でも、追試していただく余裕がありませんでしたら、とりあ
        えず HP-UX はステて、先に 2.1.0 を出してしまってもよいかな、と思っており
        ます。

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

南です。

On 28 Dec 2001 08:43:34 +0900
Araki Ken <j00...@ip...> wrote:

>         実際に commit したものは、さきほどのパッチとは異なりますが、問題は修正で
>         きていると思います。

現在の CVS で、手元では問題なく動きました。
#遅くまでありがとうございました。

        Hi,

        I committed changes below.

* typos in mlterm.1 are fixed.(thanks to Kubota Tomohiro san)
* something like "ESC [ 34 ; 0 ; m" sequence is parsed incorrectly.fixed.
  (thanks to Sakamoto Hironori san)
* cursor is not repainted under transparent mode. fixed.
  (thanks to Uebayashi Masao san)
  
--
kiken
j00...@ip...

	荒木です:-)

        commit log です。
        
* if pty encoding is stateless , state of pty encoding parser is not
  reset when key is pressed.
* "ESC [ ? 25 h" , "ESC [ ? 25 l" sequences are supported.

        これまでは、キー入力や paste がある度に、tty の 文字コードパーサの状態
        を初期化していましたが、stateless なエンコーディング(EUC-JPなど)な場合
        には、初期化するのをやめました。
        こうしないと、biew の setup 画面のキー入力の際に、Backspaceで文字を消す
        と "a" が出力されてしまうという問題が生じたためです。

        stateless なエンコーディングであれば、キー入力や paste によって、ISO2022
        の状態が不正になる(EUC-JPなのにG0にKSC1001が指示されてしまうなど)ことは
        ありえないようになっておりますので、これでも問題ないと思います。

        ただ、stateful なエンコーディングの場合、0x00 - 0x7f の範囲が、必ずしも
        US-ASCII とは限らなくなるため、単にコマンド入力したい場合であっても、エ
        スケープシーケンスを付加する必要が生じたりして、シェルにうまくコマンド文
        字列がわたらなくなったりするなど、いろいろ面倒なことが起こってしまいます。
        そこで、この場合は、従来通り、キー入力の度に状態を初期化、すなわち、キー
        入力時の初期状態として 0x00 - 0x7f が必ず US-ASCII になるようにしています。

        # つまり、biew の問題は解決されません。

        
        ESC [ ? 25 h , ESC [ ? 25 l は、カーソルの visual/invisual 切替えシーケン
        スです。
        biew 使用時に、ちゃんと、カーソルが表示されなくなると思います。

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

	Hi,

        I committed changes below.
        
* cursor form is changed when window is focused or unfocused.
* when a character whose color is reversed is drawn under wall paper or tranparent mode ,
  not background image but the background color of the charcter is used.
  (thanks to Masao Uebayashi san)
* ESC ] 20 ; pt BEL sequence is supported.(thanks to Minami Hirokazu san)

--
kiken
j00...@ip...

	荒木です:-)

* fade_ratio can be dynamically changed.
* ESC]5379;fade_ratio=<value>BEL , ESC]5380;fade_ratioBEL , ESC]5380;wall_pictureBEL
  are supported.(see doc/en/PROTOCOL)
* FocusIn/FocusOut events to windows except a top window are ignored.

        fade_ratio を動的変更できるようにしました。
        この設定は、Appearance タブにおいたのですが、そうしますと、Appearance タブが
        おおきくなりすぎますので、一番 Appearance と関係なさそうな Bel Mode の設定を、
        Others に移動しました。
        
        また、anti alias して、fade_ratio を 100 未満に設定している場合、画面の再
        描画にかなりのコストがかかることに気付きましたので、FocusIn/FocusOut イベ
        ントの処理回数を圧縮しました。
        Wnn7 の Xwnmo を使った場合や、XFree86 以外などでは問題がでるかもしれません。

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

南です

> * ESC]5380;wall_pictureBEL are supported.(see doc/en/PROTOCOL)

ESC]5379;wall_pictureBEL では相対 path をそのまま利用しているとおもいます。
#というか手を抜いた覚えが ^^;

しかし ESC]5380;wall_pictureBEL の返値が相対だと
(mlterm の current directory がどこだったか自明でないので)
 どこの画像だったか知ることができません。

副作用がなければ full path をかえすようにしていただけると嬉しいです。

#設定時の value と 直後に問い合わせた value が異なって美しくない位?

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] commit log [2002/01/14]
	From: MINAMI Hirokazu <mi...@ch...>
	Message-ID: <200...@ch...>
	Date: Mon, 14 Jan 2002 03:49:53 +0900

> ESC]5379;wall_pictureBEL では相対 path をそのまま利用しているとおもいます。

        はい。

> しかし ESC]5380;wall_pictureBEL の返値が相対だと
> (mlterm の current directory がどこだったか自明でないので)
>  どこの画像だったか知ることができません。
> 副作用がなければ full path をかえすようにしていただけると嬉しいです。

        一瞬、そのとおりだ、と思い、一度は実装したのですが、

> #設定時の value と 直後に問い合わせた value が異なって美しくない位?

        そもそも、ユーザは、mlterm の current working directory を知っていない
        と、ESC]5380;wall_pictureBEL でパスを取得する以前に、
        ESC]5379;wall_picture=<path>BEL で相対パス指定すること自体不可能ですよ
        ね。

        それに、パスの相対<=>絶対変換って、単に、getcwd() の結果と相対パスをく
        っつけるだけか、"//" を "/" に直すなどの cleanup 処理までするのか、
        ".."や"." の解決や、シムリンクの解決などまでするのか、などいろいろポリ
        シーがありえますので、mlterm の中で勝手なことをされるより、その辺を外部
        から制御できたほうがやりやすくないですか?
        
        などを考えますと、mlterm の current working directory を通知するシーケ
        ンスを別途作ることで対処したほうが、mlterm 内部で下手なことをするよりよ
        いように思いました。
        mlterm の current working directory は、実行時に変更されることはありえ
        ませんし。
        
	では
--
kiken
j00...@ip...

南です。

> > 副作用がなければ full path をかえすようにしていただけると嬉しいです。

>         などを考えますと、mlterm の current working directory を通知するシーケ
>         ンスを別途作ることで対処したほうが、mlterm 内部で下手なことをするよりよ
>         いように思いました。

はい。たしかにその方が使い勝手が良さそうだと思います。

それから お約束の(^^; 設定ツールですが、とりあえず curses-perl を使った
プロトタイプを一応動くようにしました。

  http://minami.obi.ne.jp/pub/mlterm/mlconf_curses.pl
においたので、よろしければテストをお願いいたします。

必要なものは perl 5 (5.6?) + perl の cursesモジュール + curses で、
手元では perl 5.6.1 + curses-perl 1.05 + ncurses 5.2 で動かしています。

#まだ画面の更新がぜんぜん最適化できてないので遅いですけど

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] commit log [2002/01/14]
	From: MINAMI Hirokazu <mi...@ch...>
	Message-ID: <200...@ch...>
	Date: Mon, 14 Jan 2002 21:48:54 +0900

> それから お約束の(^^; 設定ツールですが、とりあえず curses-perl を使った
> プロトタイプを一応動くようにしました。

        ありがとうございます _o_

>   http://minami.obi.ne.jp/pub/mlterm/mlconf_curses.pl
> においたので、よろしければテストをお願いいたします。
>
> 必要なものは perl 5 (5.6?) + perl の cursesモジュール + curses で、
> 手元では perl 5.6.1 + curses-perl 1.05 + ncurses 5.2 で動かしています。

        perl 5.6.0 + curses-perl 1.06 + NetBSD libcurses.so.4.2

        ですと、mlconf_curses.pl 中の halfdelay() をコメントアウトすれば、なんとか
        起動して初期画面(モノクロ)を表示することまではできましたが、それ以降、ま
        ともに画面表示できませんでしたのでステました。

        で、
        
        perl 5.6.0 + curses-perl 1.06 + ncurses 5.2

        で試してみましたところ(curses-perl のコンパイルが難儀でしたが)、かっこいい
        画面を拝ませていただくことができました:)
        
        あとは、再描画をチューニングして、設定項目を整備すれば、かなり便利になり
        そうですね:)

        とりあえず、現時点での再現する不具合としましては、左ウィンドウの項目で、
        Cut & Paste メニュー より下に移動しようとして、下カーソルキーを押下した
        とたん、キー入力がきかなくなることくらいでしょうか。
        
        # curses-perl のコンパイルで、ちょこちょこ無理なことをしました (そもそも
        # NetBSD + ncurses というコンパイルオプションがない;_;) ので、わたしの環境
        # が腐ってるのだと思いますが。

        このため、Configuration メニューに到達できず^_^;、設定の apply はもちろ
        ん、ほとんどまだテストできておりません _o_
        
	では
--
kiken
j00...@ip...