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

[Mlterm-dev-ja] encoding change and input

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

久保田です。

mlconfig でエンコーディングを変更した直後に、XIM での入力が
できなくなることがあります。入力はできている (入力した内容が
シェルに渡っている) のに、表示されていないのです。何文字か
入力していると直ったりします。ペーストについても同様で、
表示されていないけどシェルには渡っている、という症状が出ます。
(ASCII 文字は入力もペーストも問題ないようです)。

調べてみると、cvs 2001-12-10 からこの不具合があるようです。
2001-12-08 までは不具合はありません。

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

[Mlterm-dev-ja] Big5, selection, Xutf8LookupString, mlconfig

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

久保田です。

Big5 テストをしているのですが、いくつかの点について。

 - まず、Big5 なペーストの受け入れですが、--big5buggy で切り替えるの
   ではなく、いつでも何でも受け入れる、というのがいいと思います。
   mlterm 以外にも、COMPOUND_TEXT を独自に生成しているソフトウェアが
   あります (たとえば emacs)。そういうソフトウェアが生成する
   COMPOUND_TEXT に対応するには、そうするのがいいと思います。

 - ペーストのテストをしていたら、ごくたまに、segfault することがありま
   す。感覚的には 20 回から 100 回に 1 回くらいの割合で。

 - ペーストのとき、COMPOUND_TEXT を Unicode にいったん変換する (そして
   さらに現在のエンコーディングに変換する) というオプションがあります
   が、
   それがオフのときでも、Unicode でやってきたセレクションを現在の
   エンコーディングに変換する、というのは、やったほうがいいと思います。
   これで、たとえば xterm -u8 から Big5 mlterm へのペーストが可能に
   なります。COMPOUND_TEXT から Unicode に変換するというオプションを
   オンにしてもこれは可能になりますが、そうすると、ISO-2022-JP-3 など
   で漢字がごっちゃになってしまうという副作用が現れてしまうので。

   あるいは、エンコーディングごとに Unicode のサブセットになっているか
   どうか、という情報を持たせ、もしサブセットになっているなら Unicode
   変換を使う、そうでなければ使わない、という切り分けでもいいと思い
   ます。Unicode のサブセットであるようなエンコーディングは、
   UTF-8, EUC-JP, Shift_JIS, EUC-CN, EUC-KR, Big5, ISO-2022-KR,
   ISO-8859-*, TIS-620 などで、そうでないエンコーディングは、
   ISO-2022-JP, ISO-2022-JP-2 などです。

   まとめると、
   mlterm encoding が Unicode のサブセットのとき 
     selection(XCTorUCS) -> Unicode -> (mlterm encoding)
   mlterm encoding が Unicode のサブセットでないとき
     selection(XCTorUCS) -> (mlterm encoding)
   というぐあいにするモードがあればと思います。

それから、Xutf8LookupString() パッチですが、うまく動いています。
LANG=ja_JP.eucJP な状態で mlterm -E TIS620 あるいは mlterm -E UTF8
として、setxkbmap th やって、タイ文字を入力できています。

また、mlconfig 起動状態での動作も快適です。(mlconfig の二重起動も
ないですし)。

---
久保田智広 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 , xpg4 and Xutf8LookupString

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

坂本です。

> 荒木です:-)
> この、libkik.so.* を作る時に -lxpg4 が必要という話ですが、Qt や gtk など
> を見てみたところ、それら、内部でsetlocale()しているライブラリが、明示的に
> -lxpg4 している様子はなかったので、他に原因があるような気がしまして、まだ

やっぱりダメなのですが、簡単なテストプログラムでは lib*.so.* を
作る時には、-lxpg4 は必要でありませんでした。
ただ、古い gtk の ports では -lxpg4 を追加したりしていますので、
何かあるのかもしれません。
-----------------------------------
坂本 浩則 <hs...@mt...>
 http://www2u.biglobe.ne.jp/~hsaka/

[Mlterm-dev-ja] commit log , xpg4 and Xutf8LookupString

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

	荒木です:-)

        以下の修正をcommitしました。
        
* mlconfig is replaced by the new one designed by Kubota Tomohiro san(thanks)
* mlconfig works asynchronous.
* documentation for big5_buggy option is added.
* memory leaks when pre_conv_xct_to_ucs option is changed more than twice. fixed.

        久保田さんのご指摘にそう形で、mlconfig を非同期で実行するようにしました。
        これで、mlterm 本体の再描画がされずに見苦しい表示なる問題は解決していると
        思います。

        ついでに、各 pty ウィンドウごとの mlconfg を、同時に起動できるようになっ
        ていると思いますので、そちらもご確認下さい。

        それから、
        
	Subject: [Mlterm-dev-ja] -lxpg4 is needed when libkik.so is created.
	From: hs...@mt... (Hironori Sakamoto)
	Message-ID: <200...@mt...>
	Date: Wed, 12 Dec 2001 21:54:42 +0900 (JST)

        この、libkik.so.* を作る時に -lxpg4 が必要という話ですが、Qt や gtk など
        を見てみたところ、それら、内部でsetlocale()しているライブラリが、明示的に
        -lxpg4 している様子はなかったので、他に原因があるような気がしまして、まだ
        修正はしておりません。ただ、

> それから、src/Makefile での -lkik -lmkf ですが、
> make の時は、TOPDIR/kiklib/src/, TOPDIR/mkf/lib/ を最優先
> すべきですので、以下の様に最初に持って来るべきかと。
> --- src/Makefile.in.orig	Tue Dec 11 01:38:30 2001
> +++ src/Makefile.in	Wed Dec 12 20:26:44 2001
> @@ -33,8 +33,9 @@
>  	-DLIBDIR=\"$(LIBDIR)\" -DLIBEXECDIR=\"$(LIBEXECDIR)\" -DSYSCONFDIR=\"$(SYSCONFDIR)\" \
>  	-I/usr/X11R6/include -I/usr/local/include
>  LIBS=$(CFLAGS_LOCAL) \
> +	$(LKIK) $(LMKF) \
>  	@X_EXTRA_LIBS@ @XPG4_LIBS@ @DL_LIBS@ @IMLIB_LIBS@ @AA_LIBS@ @FRIBIDI_LIBS@ \
> -	$(LKIK) $(LMKF) -lX11 \
> +	-lX11 \
>  	-L/usr/X11R6/lib -L/usr/local/lib
>  
>  PROG = mlterm

        ↑このパッチをみていて気づいたのですが、@XPG4_LIBS@ より前に、$(LKIK) を
        もってこないと、setlocale のシンボル解決がうまく行かない可能性がありそう
        な(ranlibしてない.aアーカイブ以外でもありえるのかしら)気がしましたので、
        XPG4_LIBS を後ろにもってくる修正は加えさせていただきました_o_

        これで解決しませんでしょうか?

        最後に、Xutf8LookupString()をどうするか、という話ですが、とりあえず、

        XmbLookupString => XLookupString => Xutf8LookupString()

        という順番で検索するパッチを添付しておきます。
        わたしの環境では、setxkbmap を使う方法はもとより、kinput2 からすら、
        Xutf8LookupStringでは、さっぱり入力を受け取れませんので、テストして
        いただけると幸いです。

        # ./configure --enable-wide-chars して作った xterm-164 -u8 でも、kinput2
        # 入力できていません。何かミスってるんでしょうけれど、よくわからない....

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

Index: ml_window.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_window.c,v
retrieving revision 1.201
diff -u -r1.201 ml_window.c
--- ml_window.c	2001/12/13 15:35:44	1.201
+++ ml_window.c	2001/12/14 13:41:58
@@ -2625,11 +2625,16 @@
 		return  len ;
 	}
 	 
-	*parser = NULL ;
-
 	if( ( len = XLookupString( event , seq , seq_len , keysym , NULL)) > 0)
 	{
+		*parser = NULL ;
+
                 return  len ;
+	}
+
+	if( ( len = ml_xic_get_utf8_str( win , seq , seq_len , parser , keysym , event)) > 0)
+	{
+		return  len ;
 	}
 
 	return  0 ;
Index: ml_xic.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_xic.c,v
retrieving revision 1.13
diff -u -r1.13 ml_xic.c
--- ml_xic.c	2001/12/13 06:28:21	1.13
+++ ml_xic.c	2001/12/14 13:36:56
@@ -9,11 +9,17 @@
 #include  <kiklib/kik_str.h>	/* kik_str_alloca_dup */
 #include  <kiklib/kik_mem.h>	/* malloc */
 #include  <kiklib/kik_locale.h>	/* kik_get_locale */
+#include  <mkf/mkf_utf8_parser.h>
 
 #include  "ml_window_intern.h"
 #include  "ml_xim.h"		/* refering mutually */
 
 
+/* --- static variables --- */
+
+static mkf_parser_t *  utf8_parser ;
+
+
 /* --- static functions --- */
 
 static void
@@ -511,6 +517,43 @@
 	}
 
 	return  len ;
+}
+
+size_t
+ml_xic_get_utf8_str(
+	ml_window_t *  win ,
+	u_char *  seq ,
+	size_t  seq_len ,
+	mkf_parser_t **  parser ,
+	KeySym *  keysym ,
+	XKeyEvent *  event
+	)
+{
+#ifdef  X_HAVE_UTF8_STRING
+	Status  stat ;
+	size_t  len ;
+
+	if( win->xic == NULL || win->use_xim == 0)
+	{
+		return  0 ;
+	}
+	
+	if( ( len = Xutf8LookupString( win->xic->ic , event , seq , seq_len , keysym , &stat)) == 0)
+	{
+		return  0 ;
+	}
+	
+	if( ! utf8_parser)
+	{
+		utf8_parser = mkf_utf8_parser_new() ;
+	}
+
+	*parser = utf8_parser ;
+
+	return  len ;
+#else
+	return  0 ;
+#endif
 }
 
 int
Index: ml_xic.h
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_xic.h,v
retrieving revision 1.5
diff -u -r1.5 ml_xic.h
--- ml_xic.h	2001/12/13 06:28:21	1.5
+++ ml_xic.h	2001/12/14 13:43:01
@@ -42,7 +42,10 @@
 
 int  ml_xic_set_spot( ml_window_t *  win) ;
 
-size_t  ml_xic_get_str(	ml_window_t *  win , u_char *  seq , size_t  seq_len ,
+size_t  ml_xic_get_str( ml_window_t *  win , u_char *  seq , size_t  seq_len ,
+	mkf_parser_t **  parser , KeySym *  keysym , XKeyEvent *  event) ;
+
+size_t  ml_xic_get_utf8_str( ml_window_t *  win , u_char *  seq , size_t  seq_len ,
 	mkf_parser_t **  parser , KeySym *  keysym , XKeyEvent *  event) ;
 
 int  ml_xic_set_focus( ml_window_t *  win) ;

Re: [Mlterm-dev-ja] mlconfig window design

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

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] mlconfig window design
	From: Tomohiro KUBOTA <tk...@ri...>
	Message-ID: <200...@si...>
	Date: Fri, 14 Dec 2001 17:47:37 +0900

> ぼくがひとつだけ迷った点があります。
...
> というわけで、あまりかっこよくないのですが、フレームで囲わないように
> してあります。

        わたしはむしろ、フレームで囲っていないのを見て、うまいやり方だなぁ、と思
        いました。

> それから、CANCEL ボタンは押した瞬間に効いてしまいますが、APPLY と同様、
> 離した瞬間に効くのがいいと思います。

        あ、ホントですね。
        
        他のボタンについても、pressed イベントでなく、clicked イベントを拾うよう、
        修正致しました。

> もうひとつ、これは mlconfig じゃなくて mlterm 側の作り方だと思いますが、
> mlconfig 動作中は mlterm の再描画がなされません。ので、mlterm に他の
> ウィンドウが重なってそれが移動したりすると、内容が消えてしまいます。

        はい。問題としては認識していましたが、あまり重要な問題でもないだろう、と
        いうことで、無視していました。
        
> (使用上問題が生じるわけではないにもかかわらず、mlterm にかなりな変更を
> 加えることになると思うので、優先順位がすご〜く低い TODO という扱いで
> いいと思います。)

        いえ、実は大して変更は必要ないはずです。
        
        実際、さっき、さらっとプロトタイプを実装してみたところ、とりあえず簡単に
        いけそうですので、後程ちゃんと実装して、commit します。

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

Re: [Mlterm-dev-ja] mlconfig window design

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

久保田です。

At 14 Dec 2001 10:39:53 +0900,
Araki Ken wrote:

> encoding タブのチェックボタンの左端が揃わない点と、不要な変数宣言につい
> て、添付のパッチのように修正したいのですが、問題ありませんでしょうか?
> もし、問題ないようでしたら、このまま commit しようと思います。

はい。細かい点は (というか、細かくなくても) ご自由に変更してください。
ぼくがひとつだけ迷った点があります。それは、さまざまなアプリケーション
の画面のデザインを見ていると、タブに直接さまざまな部品を配置するのでは
なく、タブの中はフレームで囲ってから部品を配置しているのです。そうした
ほうがかっこいいのですが、フレームで囲うのは部品の数が多いときに、
それをいくつかに分類して整理するためだと思うのですが、mlconfig の場合
には、囲うほどもありません。encoding タブの中に encoding フレームを
作っても冗長なだけだし。

というわけで、あまりかっこよくないのですが、フレームで囲わないように
してあります。

それから、CANCEL ボタンは押した瞬間に効いてしまいますが、APPLY と同様、
離した瞬間に効くのがいいと思います。

もうひとつ、これは mlconfig じゃなくて mlterm 側の作り方だと思いますが、
mlconfig 動作中は mlterm の再描画がなされません。ので、mlterm に他の
ウィンドウが重なってそれが移動したりすると、内容が消えてしまいます。
(使用上問題が生じるわけではないにもかかわらず、mlterm にかなりな変更を
加えることになると思うので、優先順位がすご〜く低い TODO という扱いで
いいと思います。)

---
久保田智広 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] mlconfig window design

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

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] mlconfig window design
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: 14 Dec 2001 10:11:52 +0900

>         とりあえず、わたしは、main.c.tab を採用したいなぁと思うのですけれど、他
>         の方はどうでしょうか?

        encoding タブのチェックボタンの左端が揃わない点と、不要な変数宣言につい
        て、添付のパッチのように修正したいのですが、問題ありませんでしょうか?
        もし、問題ないようでしたら、このまま commit しようと思います。

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

--- /home/ken/work/main.c.tab	Fri Dec 14 09:17:08 2001
+++ main.c	Fri Dec 14 10:37:39 2001
@@ -289,11 +289,8 @@
 	GtkWidget *  notebook ;
 	GtkWidget *  frame ;
 	GtkWidget *  label ;
-	GtkWidget *  vboxl ;
-	GtkWidget *  vboxr ;
 	GtkWidget *  hbox ;
 	GtkWidget *  config_widget ;
-	GtkWidget *  button ;
 	GtkWidget *  separator ;
 	
 	window = gtk_window_new( GTK_WINDOW_TOPLEVEL) ;
@@ -303,6 +300,7 @@
 	gtk_container_set_border_width(GTK_CONTAINER(window) , 0) ;
 	gtk_widget_show(window) ;
 	gdk_window_move(window->window , x , y) ;
+	gtk_window_set_policy(GTK_WINDOW(window) , 0 , 0 , 0) ;
 
 	vbox = gtk_vbox_new( FALSE , 10) ;
 	gtk_widget_show(vbox) ;
@@ -357,17 +355,21 @@
 	if (!(config_widget = mc_bidi_config_widget_new(use_bidi)))
 		return  0 ;
 	gtk_widget_show(config_widget) ;
-	gtk_box_pack_start(GTK_BOX(hbox) , config_widget , TRUE , FALSE , 0) ;
+	gtk_box_pack_start(GTK_BOX(hbox) , config_widget , TRUE , TRUE , 0) ;
 
 	if (!(config_widget = mc_char_combining_config_widget_new(is_combining_char)))
 		return  0 ;
 	gtk_widget_show(config_widget) ;
-	gtk_box_pack_start(GTK_BOX(hbox) , config_widget , TRUE , FALSE , 0) ;
+	gtk_box_pack_start(GTK_BOX(hbox) , config_widget , TRUE , TRUE , 0) ;
 
+	hbox = gtk_hbox_new(TRUE , 5) ;
+	gtk_widget_show(hbox) ;
+	gtk_box_pack_start(GTK_BOX(vbox) , hbox , FALSE , FALSE , 0) ;
+	
 	if (!(config_widget = mc_pre_conv_config_widget_new(pre_conv_xct_to_ucs)))
 		return  0 ;
 	gtk_widget_show(config_widget) ;
-	gtk_box_pack_start(GTK_BOX(vbox) , config_widget , FALSE , FALSE , 0) ;
+	gtk_box_pack_start(GTK_BOX(hbox) , config_widget , TRUE , TRUE , 0) ;
 
 	/* contents of the "appearance" tab */
 
@@ -404,11 +406,11 @@
 	if (!(config_widget = mc_aa_config_widget_new(is_aa)))
 		return  0 ;
 	gtk_widget_show(config_widget) ;
-	gtk_box_pack_start(GTK_BOX(hbox) , config_widget , TRUE , FALSE , 10) ;
+	gtk_box_pack_start(GTK_BOX(hbox) , config_widget , TRUE , TRUE , 0) ;
 	if (!(config_widget = mc_transparent_config_widget_new(is_transparent)))
 		return  0 ;
 	gtk_widget_show(config_widget) ;
-	gtk_box_pack_start(GTK_BOX(hbox) , config_widget , TRUE , FALSE , 10) ;
+	gtk_box_pack_start(GTK_BOX(hbox) , config_widget , TRUE , TRUE , 0) ;
 
 	/* contents of the "others" tab */
 

Re: [Mlterm-dev-ja] mlconfig window design

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

	荒木です:-)

	Subject: [Mlterm-dev-ja] mlconfig window design
	From: Tomohiro KUBOTA <tk...@ri...>
	Message-ID: <200...@si...>
	Date: Fri, 14 Dec 2001 09:45:57 +0900

> mlconfig の画面が 640x480 を越えて大きくなりすぎる問題ですが、
> (現状でもまだ 480 ピクセルを越えている)、それへの対処を考えて
> みました。

        main.c.tab とても格好よいですね ^_^ すばらしいです。

        # すごいなぁ... わたしは、GUI デザインは(HTMLさえ)ひたすら苦痛ですので、
        # 助かります_o_

        とりあえず、わたしは、main.c.tab を採用したいなぁと思うのですけれど、他
        の方はどうでしょうか?

> ところで、GTK で、画面サイズ変更禁止をウィンドウマネージャに
> 伝えるには、どうすればいいのでしょうか? (Tcl/Tk は、けっこう
> いじり倒したことがあるので、わかるのですが)。

        手元で調べてところ、添付のパッチのような感じでよさそうかと。

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

--- /home/ken/work/main.c.tab	Fri Dec 14 09:17:08 2001
+++ main.c	Fri Dec 14 10:10:06 2001
@@ -303,6 +303,7 @@
 	gtk_container_set_border_width(GTK_CONTAINER(window) , 0) ;
 	gtk_widget_show(window) ;
 	gdk_window_move(window->window , x , y) ;
+	gtk_window_set_policy(window , 0 , 0 , 0) ;
 
 	vbox = gtk_vbox_new( FALSE , 10) ;
 	gtk_widget_show(vbox) ;

[Mlterm-dev-ja] mlconfig window design

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

久保田です。

mlconfig の画面が 640x480 を越えて大きくなりすぎる問題ですが、
(現状でもまだ 480 ピクセルを越えている)、それへの対処を考えて
みました。

画面のデザインにかかわること (というか、デザインだけ) なので、
いくつか候補を作ってみました。どちらがいいでしょうか。

以下のアーカイブには、main.c.tab と main.c.wide というふたつの
ファイルが入っています。それぞれ、tool/mlconfig/main.c に置き
換えて使います。

main.c.tab は、タブを使ったデザインになっています。もうちょっと
かっこよくできる (タブの中に frame を導入するなど) こともできる
と思います。こちらの利点は、将来設定項目がかなり増えても画面の
大きさをそれほど大きくしないで保てることです。欠点は、タブを
導入した関係上、ソースがちょっとややこしくなっています。

main.c.wide は、もとの mlconfig の画面を上下で半分に割り、下
半分を右に持ってきたようなデザインとなっています。ただし、
フォントサイズの大小と壁紙指定だけは、APPLY - CANCEL の制御から
外れているので、分けて下に持ってきてあります (これは、main.c.tab
でもそうなっています)。これの利点はソースへの変更が少ないこと
ですが (といってもけっこうある)、今後設定項目が増えたときの
画面のデザインの自由度は低くなっています。

ソースの保守性とか将来への自由度とは別に、そのものの見てくれが
気に入るかそうでないか、という問題もあります。みなさんの意見を
おねがいします。

ところで、GTK で、画面サイズ変更禁止をウィンドウマネージャに
伝えるには、どうすればいいのでしょうか? (Tcl/Tk は、けっこう
いじり倒したことがあるので、わかるのですが)。

---
久保田智広 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] =?ISO-2022-JP?B?GyRCJW0lMSE8JWskSBsoQg==?= mlterm =?ISO-2022-JP?B?GyRCJE4lKCVzJTMhPCVHJSMlcyUwJCwwYyQmPmw5ZyROGyhC?= =?ISO-2022-JP?B?GyRCRn5OTxsoQg==?=

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

	荒木です:-)

	Subject: [Mlterm-dev-ja] ロケールと mlterm のエンコーディングが違う場合の入力
	From: Tomohiro KUBOTA <tk...@ri...>
	Message-ID: <200...@si...>
	Date: Tue, 11 Dec 2001 21:57:46 +0900

> 1. ロケールによってしかエンコーディングを決められないようにする。
>    つまり、ロケールが指定する以外のエンコーディングを使いたいと
>    考えるユーザのほうが悪い、という立場をとる。
>    (mlconfig 等からエンコーディングの設定を廃止する)。
>    これだと、ロケールにないエンコーディングが使えなくなってしまいます。
> 
> 2. mlconfig でエンコーディングを変えたとき、相当するロケールに
>    自動的に変更するようにする。
>    XIM の変更と同じようにする、ということです。が、これも、
>    利用できるロケールがなければそのエンコーディングは使えません。
> 
> 3. Xutf8LookupString() を使う。
>    ぼくはこれがいちばんきれいな解のように思えます。CJK Han Unification
>    などに原理的に対応できなくなりますが、どうせ現状でも対応できている
>    OS などありませんし (つまり、XmbLookupString() を使うことで、
>    CJK の漢字を使い分けることが可能な OS ってないでしょう、ということ)。

        で、これ、どうしましょう?

        1 は、ちょっとアレとしても、1 に近い解として、入力はできないけど、表示は
        できる、という現状のまま、というのもアリかと思います。
        
        2 については、複数の pty ウィンドウを立ち上げている場合に、他の端末のロ
        ーケールにも影響してしまうことを考えますと、苦労の割に実りのない選択肢
        だなぁ、と思い直しました。

        3 は、UTF8 エンコーディングのときだけ Xutf8LookupString() する、というこ
        とでしたら、別にいいかなと思います。

        3 に近い解として、エンコーディングに限らず、
        XmbLookupString() => XLookupString() => Xutf8LookupString()
        のように、三段構えで文字入力を受け取るというのでも問題は解決できるのではない
        か、と思います。

        個人的には、(もしそれで問題が解決できるのなら)一番後者のやり方がいいなぁ、
        と思っていますが、どうでしょうか?

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

Re: [Mlterm-dev-ja] commit log

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

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] commit log
	From: MINAMI Hirokazu <mi...@ch...>
	Message-ID: <200...@ch...>
	Date: Thu, 13 Dec 2001 20:15:29 +0900

> 1. Test of cursor movements の三番目
>  Test of cursor-control characters inside ESC sequences.
>  Below should be two identical lines:
> 
> で
> 
>  A B C D E F G H I J K L M N O P Q R S
>  A B C D E F G H I J K L M N O P Q R S
> 
> となるべきところ
> 
>  A B C D E F G H I J K L M N O P Q R S
>  ABCDEFGHIJKLMNOPQRS
> 
> になりました。

        あらら、本当ですね。気づいていませんでした。

> シーケンス中にコントロールコードのある場合の処理ですが rxvt-2.7.7 では
> 
> * ESC - [ - 2 - <0x08> ... => BackSpace +  ESC - [ - 2 - ...  
>  (画面端では順序を気にするべき?)
> * <0x08> は高々一つしかない
>  (複数でも対応する?)
> 
> として処理しているようなので、手元では下のようにしてみました。

        こんな変態なシーケンス流すアプリケーションなどほとんどないでしょうから、
        あまり深く考えなくてもよさそうに思います。

        いただいたパッチをそのまま取り込ませていただきます_o_

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

Re: [Mlterm-dev-ja] -lxpg4 is needed when libkik.so is created.

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

	荒木です:-)

        ごたごたしていて返事が遅くなりました。

        まず最初に、別件ですが、XIM 周りを中心とする修正を commit しました。
        
* memory leaks around encoding parsers. fixed.
* XIM codes are rewritten. XRegisterIMInstantiateCallback() is used.

        XRegisterIMInstantiate() を使うよう修正しております。

        # "Edward G.J. Lee" <ed...@ms...> からも、わたしあてに、うまく
        # 動作した旨報告をいただきました。

        で、本題ですが。
        
	Subject: [Mlterm-dev-ja] -lxpg4 is needed when libkik.so is created.
	From: hs...@mt... (Hironori Sakamoto)
	Message-ID: <200...@mt...>
	Date: Wed, 12 Dec 2001 21:54:42 +0900 (JST)

> kik_locale.c の kik_locale_init() の 182行目の strcmp
> で sys_locale が NULL で渡されて落ちました。

        すみません、わたしのミスでした。
        修正致しました。

> それを何とかしようとして、まず setlocale( LC_CTYPE , "") が
> NULL になってしまうのに、はまってしまったのですが、結局、
> libxpg4 があるシステムでは、libkik.so* を作る時に -lxpg4 が
> 必要なことが分かりました。

        そのように致します。

        # なんでなんでしょうね...

> それから、src/Makefile での -lkik -lmkf ですが、
> make の時は、TOPDIR/kiklib/src/, TOPDIR/mkf/lib/ を最優先
> すべきですので、以下の様に最初に持って来るべきかと。

        現状の

LIBS=$(CFLAGS_LOCAL) \
        @X_EXTRA_LIBS@ @XPG4_LIBS@ @DL_LIBS@ @IMLIB_LIBS@ @AA_LIBS@ @FRIBIDI_LIBS@ \
        $(LKIK) $(LMKF) -lX11 \
        -L/usr/X11R6/lib -L/usr/local/lib

        これで、-L/usr/X11R6/lib や、-L/usr/local/lib より、$(LKIK) $(LMKF) を先
        に見るようになっていると思うのですが、何かわたしが勘違いしていますでしょ
        うか?

        ただ、少なくとも、普通に configure した場合、

LKIK = /home/ken/src/mlterm/autoconf/../kiklib/src/libkik.la
LMKF = /home/ken/src/mlterm/autoconf/../mkf/lib/libmkf.la

        このように、フルパスで指定されると思いますので、どっちを先にみるか、とい
        う問題は生じないような気がします。

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

Re: [Mlterm-dev-ja] commit log

[MINAMI H. <mi...@ch...>]

南です

On 12 Dec 2001 04:27:30 +0900
Araki Ken <j00...@ip...> wrote:

>         o 1. Test of cursor movements
>           すべてパス

たぶんだれも使わない部分ではありますが、

1. Test of cursor movements の三番目
 Test of cursor-control characters inside ESC sequences.
 Below should be two identical lines:

で

 A B C D E F G H I J K L M N O P Q R S
 A B C D E F G H I J K L M N O P Q R S

となるべきところ

 A B C D E F G H I J K L M N O P Q R S
 ABCDEFGHIJKLMNOPQRS

になりました。

シーケンス中にコントロールコードのある場合の処理ですが rxvt-2.7.7 では

* ESC - [ - 2 - <0x08> ... => BackSpace +  ESC - [ - 2 - ...  
 (画面端では順序を気にするべき?)
* <0x08> は高々一つしかない
 (複数でも対応する?)

として処理しているようなので、手元では下のようにしてみました。

--- CVS-orig/mlterm/src/ml_vt100_parser.c       Thu Dec 13 19:47:18 2001
+++ CVS/mlterm/src/ml_vt100_parser.c    Thu Dec 13 19:56:32 2001
@@ -944,7 +944,24 @@
 
                        #ifdef  ESCSEQ_DEBUG
+				if( *str_p < 0x20 || 0x7e < *str_p) 
+    				{ 
+        				fprintf( stderr , "<%x>" , *str_p) ;
+				}else{
     					fprintf( stderr , "%c" , *str_p) ;
+                               }
                        #endif
 
+				if( *str_p == 0x8 )
+				{
+					cursor_back( vt100_parser , 1) ;
+					if( increment_str( &str_p , &left) == 0)
+					{
+						return  0 ;
+					}
+                               }
                                if( *str_p < 0x20 || 0x7e < *str_p) 
                                { 

[Mlterm-dev-ja] Re: character shaping

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

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

-bi $B$N;~$K$A$i$D$-$,5$$K$J$k7o$G$9$,!"$$$D$N4V$K$+D>$C$F$^$9(B(^^)$B!#(B

PS.
mlterm $B$C$F(B 20pt $B$N(B font $B$H$7$F(B 18pt $B$d(B 16pt $B$J$s$+$N(B font $B$r;XDj(B
$B$7$F$b6uGr$rE,Ev$KF~$l$FI=<($7$F$/$l$k$N$G$9$M!#$3$lJXMx$G$9$M!#(B

PS(2).
FreeBSD $B$N(B ports $B$K(B mlterm-2.0.0 $B$,F~$j$^$7$?!#%a%s%F%J$O(B w3m $B$HF1$8J}!#(B
----------------------------------- 
$B:dK\(B $B9@B'(B <hs...@mt...> 
 http://www2u.biglobe.ne.jp/~hsaka/

[Mlterm-dev-ja] -lxpg4 is needed when libkik.so is created.

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

坂本です。

kik_locale.c の kik_locale_init() の 182行目の strcmp
で sys_locale が NULL で渡されて落ちました。

それを何とかしようとして、まず setlocale( LC_CTYPE , "") が
NULL になってしまうのに、はまってしまったのですが、結局、
libxpg4 があるシステムでは、libkik.so* を作る時に -lxpg4 が
必要なことが分かりました。

それから、src/Makefile での -lkik -lmkf ですが、
make の時は、TOPDIR/kiklib/src/, TOPDIR/mkf/lib/ を最優先
すべきですので、以下の様に最初に持って来るべきかと。
# libkik のバージョンが上がっておれば問題無かったのかな。
-----------------------------------
坂本 浩則 <hs...@mt...>
 http://www2u.biglobe.ne.jp/~hsaka/

--- src/Makefile.in.orig	Tue Dec 11 01:38:30 2001
+++ src/Makefile.in	Wed Dec 12 20:26:44 2001
@@ -33,8 +33,9 @@
 	-DLIBDIR=\"$(LIBDIR)\" -DLIBEXECDIR=\"$(LIBEXECDIR)\" -DSYSCONFDIR=\"$(SYSCONFDIR)\" \
 	-I/usr/X11R6/include -I/usr/local/include
 LIBS=$(CFLAGS_LOCAL) \
+	$(LKIK) $(LMKF) \
 	@X_EXTRA_LIBS@ @XPG4_LIBS@ @DL_LIBS@ @IMLIB_LIBS@ @AA_LIBS@ @FRIBIDI_LIBS@ \
-	$(LKIK) $(LMKF) -lX11 \
+	-lX11 \
 	-L/usr/X11R6/lib -L/usr/local/lib
 
 PROG = mlterm

[Mlterm-dev-ja] commit log

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

        Hi,
        I committed changes below.

* garbages can be left on screen in scrolling. fixed.
* The implementation of VT102 INS/DEL lines functions was buggy. fixed.
* If XMODIFIERS's xim is executed after mlterm started , mlterm won't use it
  even if XIM_OPEN key is pressed. fixed.

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

Re: [Mlterm-dev-ja] commit log

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

	荒木です:-)

	Subject: [Mlterm-dev-ja] commit log
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: 12 Dec 2001 04:27:30 +0900

>         o 以下については、テストしていません。
>           が、少なくとも 3,4 に関しては、kterm とほぼ同様の動きをするようです。
>           3. Test of character sets
>           4. Test of double-sized characters
>           5. Test of keyboard
>           6. Test of terminal reports
>           7. Test of VT52 mode
>           8. Test of VT102 features (Insert/Delete Char/Line)
>           9. Test of known bugs
>           10. Test of reset and self-test
>           11. Test non-VT100 (e.g., VT220, XTERM) terminals
>           12. Modify test-parameters
> 
>         ちゃんと動作しているか、おためし下さい。

        8. Test of VT102 features (Insert/Delete Char/Line)

        のバグフィクスです。src/ml_image_scroll.c に当てて下さい。
        
        多分、これでいいと思うんですが、ESC [ r で、スクロール領域が設定されてい
        る場合の仕様がいまいちわからないので、間違っているかも知れません。

        # 少なくともテストはパスします。

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

Index: ml_image_scroll.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_image_scroll.c,v
retrieving revision 1.41
diff -u -r1.41 ml_image_scroll.c
--- ml_image_scroll.c	2001/12/11 18:11:32	1.41
+++ ml_image_scroll.c	2001/12/12 05:10:44
@@ -397,28 +397,38 @@
 	)
 {
 	u_int  copy_rows ;
+	int  start_row ;
 
-	if( image->cursor.row >= image->scroll_region_beg && image->scroll_region_end < END_ROW(image))
+	if( image->cursor.row < image->scroll_region_beg)
 	{
-		copy_rows = image->scroll_region_end + 1 - image->cursor.row ;
+		start_row = image->scroll_region_beg ;
+	}
+	else
+	{
+		start_row = image->cursor.row ;
+	}
+	
+	if( image->scroll_region_end < END_ROW(image))
+	{
+		copy_rows = image->scroll_region_end + 1 - start_row ;
 
-		if( copy_rows + image->cursor.row + 1 > image->scroll_region_end + 1)
+		if( copy_rows + start_row > image->scroll_region_end)
 		{
 			copy_rows -- ;
 		}
 		
-		copy_lines( image , image->cursor.row + 1 , image->cursor.row , copy_rows , 1) ;
+		copy_lines( image , start_row + 1 , start_row , copy_rows , 1) ;
 	}
 	else
 	{
-		copy_rows = image->num_of_filled_rows - image->cursor.row ;
+		copy_rows = image->num_of_filled_rows - start_row ;
 		
-		if( copy_rows + image->cursor.row + 1 > image->num_of_rows)
+		if( copy_rows + start_row >= image->num_of_rows)
 		{
 			copy_rows -- ;
 		}
 		
-		copy_lines( image , image->cursor.row + 1 , image->cursor.row , copy_rows , 1) ;
+		copy_lines( image , image->cursor.row + 1 , start_row , copy_rows , 1) ;
 
 		if( image->num_of_filled_rows < image->num_of_rows)
 		{
@@ -426,7 +436,7 @@
 		}
 	}
 	
-	ml_image_clear_lines( image , image->cursor.row , 1) ;
+	ml_image_clear_lines( image , start_row , 1) ;
 
 	return  1 ;
 }
@@ -436,22 +446,28 @@
 	ml_image_t *  image
 	)
 {
-	if( image->cursor.row >= image->scroll_region_beg && image->scroll_region_end < END_ROW(image))
+	int  start_row ;
+
+	if( image->cursor.row < image->scroll_region_beg)
 	{
-		copy_lines( image , image->cursor.row , image->cursor.row + 1 ,
-			image->scroll_region_end - image->cursor.row , 1) ;
-			
-		ml_image_clear_lines( image , image->scroll_region_end , 1) ;
+		start_row = image->scroll_region_beg ;
 	}
-	else if( image->cursor.row < END_ROW(image))
+	else
 	{
-		copy_lines( image , image->cursor.row , image->cursor.row + 1 ,
-			END_ROW(image) - image->cursor.row , 1) ;
+		start_row = image->cursor.row ;
+	}
 
-		ml_image_clear_lines( image , END_ROW(image) , 1) ;
+	if( image->scroll_region_end < END_ROW(image))
+	{
+		copy_lines( image , start_row , start_row + 1 ,
+			image->scroll_region_end - start_row , 1) ;
+			
+		ml_image_clear_lines( image , image->scroll_region_end , 1) ;
 	}
-	else /* if( image->cursor.row == END_ROW(image)) */
+	else
 	{
+		copy_lines( image , start_row , start_row + 1 , END_ROW(image) - start_row , 1) ;
+
 		ml_image_clear_lines( image , END_ROW(image) , 1) ;
 	}
 	

[Mlterm-dev-ja] commit log

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

	荒木です:-)

        vttest の主要な項目はパスするようになりましたので、修正分を先程commitい
        たしました。

* the number of redrawing in bidi mode is reduced.
* ml_image modules is cleaned up.
* INDEX/RINDEX vt100 implementation was wrong. fixed.
* ESC # , ESC E , ESC [ ? l 3 , ESC [ ? l 5 , ESC [ ? h 3 , ESC [ ? h 5 are supported.
* "ESC [ ; ..." is regarded as "ESC [ 0 ; ..."
* buffer overflow in parsing ESC [ ... sequence is fixed.
* the size of mlconfig window is shrunk.

        現在、vttest のテスト状況は、

        o 1. Test of cursor movements
          すべてパス
          
        o 2. Test of screen features
          Test of TAB setting/resetting. => ダメ
          それ以外 => パス
          
        o 以下については、テストしていません。
          が、少なくとも 3,4 に関しては、kterm とほぼ同様の動きをするようです。
          3. Test of character sets
          4. Test of double-sized characters
          5. Test of keyboard
          6. Test of terminal reports
          7. Test of VT52 mode
          8. Test of VT102 features (Insert/Delete Char/Line)
          9. Test of known bugs
          10. Test of reset and self-test
          11. Test non-VT100 (e.g., VT220, XTERM) terminals
          12. Modify test-parameters

        ちゃんと動作しているか、おためし下さい。

        また、これにあわせ、ml_image_xxx モジュールをクリーンアップしましたので、
        新しいバグが入ったかも知れません。

        # まだもう少し整理したいんですが、他への影響を考えると段階的にやらざるを
        # えないので、もう何度か、この辺には手が入ると思います。
        # プチ破綻するたびにクリーンアップしながら、汚いところを減らしていきます...

        それから、久保田さんが指摘された問題については、全く手付かずです。

        # UTF8 エンコーディングのときだけ Xutf8LookupString() を使う (+ 案 2 に
        # ついても実装してもいいかも)というのが、いいかなぁ、と思っています。

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

Re: [Mlterm-dev-ja] =?ISO-2022-JP?B?GyRCJW0lMSE8JWskSBsoQm1sdGVy?= =?ISO-2022-JP?B?bRskQiROJSglcyUzITwlRyUjJXMlMCQsMGMkJj5sOWckTkZ+Tk8bKEI=?=

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

久保田です。

At Tue, 11 Dec 2001 23:04:00 +0900 (JST),
sakamoto hironori wrote:

> > 3. Xutf8LookupString() を使う。
> >    ぼくはこれがいちばんきれいな解のように思えます。CJK Han Unification
> >    などに原理的に対応できなくなりますが、どうせ現状でも対応できている
> 
> XFree86 と、そうでない X とで動作が変わってしまいますよ。
> # XFree86 の xterm のコードを使えばいいのかもしれませんが。

それは、その通りです。この案の欠点です。XFree86 の XTerm のコードを
使ったところで、Xutf8LookupString() がない環境では機能が制限されて
しまいます。

# XTerm の実装では、Xutf8LookupString() がない環境では Latin-1 しか
# 入力できません。ですので、Xutf8LookupString() がない環境では
# mlterm の現状を使うというふうにするのがいいと思います。


> それに根本的な解決にはなりません。
> # それこそ X<encoding>LookupString() が必要になるかと。
> # パーサはあるから出来そうな気もする。

これもその通りで、mlterm はパーサを自前で持つソフトウェアつまり
Code Set Independent ではないソフトウェアなので、そのパーサの性能と
見比べながら Xutf8LookupString() を使っても構わないということになる
と思います。Xutf8LookupString() を嫌う理由としては、CSI ではない、
ということだと思うのですが、どうせ mlterm はもとから CSI ではない
のですから。(もうひとつ、Unicode のサブセットでないエンコーディングが
ロケールでサポートされていたときに機能が劣るという問題がありますが、
Unicode のサブセットでないエンコーディング [ISO-2022-JP-2 とか
TRON コードとか] がロケールでサポートされている実例って、ぼくは
ひとつも知りません)。

# CSI では、ロケールとエンコーディングは絶対に一致しなければ
# なりませんね。

> >    OS などありませんし (つまり、XmbLookupString() を使うことで、
> >    CJK の漢字を使い分けることが可能な OS ってないでしょう、ということ)。
> 
> これはどういうことでしょうか？
> ISO-2022-JP-2 を使えば使い分けることが出来そうですが。

そうですが、それを実装した実例がないなら、存在しないものへの対応を
謳うことにどれだけの意味があるのか、ということです。それと比べて、
ロケールと mlterm のエンコーディングが一致しないとき、XIM を使わない
言語 (CJK 以外ぜんぶ) が入力できないという問題の解決と、どちらを
優先させるのがいいか、という価値観の問題です。ぼくとしては、仮想的な
問題よりは、現実に存在する問題のほうを優先させたいと思います。
もちろん、この問題を解決できるなら、Xutf8LookupString() の使用に
こだわるつもりはありませんが、どんな解決策があるでしょうか?

> とりあえず、
> ISO-2022-* の様にロケールには無いエンコーディングもありますし、
> ロケールとエンコーディングは切り離して考えた方がいいと思います。
> 入力できないからって表示すら使えなくなるのは困る。

そうですね。だから、ぼくの (1) の案は却下ということで。なにか
対案はありますか?

---
久保田智広 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] Re: cut&paste Big5 and UCS - Big5 convertion.

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

久保田です。

At 11 Dec 2001 10:29:16 +0900,
Araki Ken wrote:

> strcasecmp() すでに使ってるんですが、特に今まで問題がでなかったということ
> は、そちらは、あまり問題にならないのでしょうか...

strcasecmp() があれば、strncasecmp() もあるだろうと思います。
というわけで、今のところバグ報告がないということは、とりあえず
strncasecmp() を使ってしまってもかまわない、ということだと思い
ます。もちろん、使わないほうがいいですが、とりあえずはその部分の
portability は todo list 行きということでいいと思います。

代替関数を手で書いてしまってもそれほど手間じゃないですけど、
まずは Big5 のテストというのがさしあたっての目的なので。

---
久保田智広 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] $B%m%1!<%k$H(Bmlterm$B$N%(%s%3!<%G%#%s%0$,0c$&>l9g$NF~NO(B

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

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

> $B5WJ]ED$G$9!#(B
> 3. Xutf8LookupString() $B$r;H$&!#(B
>    $B$\$/$O$3$l$,$$$A$P$s$-$l$$$J2r$N$h$&$K;W$($^$9!#(BCJK Han Unification
>    $B$J$I$K86M}E*$KBP1~$G$-$J$/$J$j$^$9$,!"$I$&$;8=>u$G$bBP1~$G$-$F$$$k(B

XFree86 $B$H!"$=$&$G$J$$(B X $B$H$GF0:n$,JQ$o$C$F$7$^$$$^$9$h!#(B
# XFree86 $B$N(B xterm $B$N%3!<%I$r;H$($P$$$$$N$+$b$7$l$^$;$s$,!#(B

$B$=$l$K:,K\E*$J2r7h$K$O$J$j$^$;$s!#(B
# $B$=$l$3$=(B X<encoding>LookupString() $B$,I,MW$K$J$k$+$H!#(B
# $B%Q!<%5$O$"$k$+$i=PMh$=$&$J5$$b$9$k!#(B

>    OS $B$J$I$"$j$^$;$s$7(B ($B$D$^$j!"(BXmbLookupString() $B$r;H$&$3$H$G!"(B
>    CJK $B$N4A;z$r;H$$J,$1$k$3$H$,2DG=$J(B OS $B$C$F$J$$$G$7$g$&!"$H$$$&$3$H(B)$B!#(B

$B$3$l$O$I$&$$$&$3$H$G$7$g$&$+!)(B
ISO-2022-JP-2 $B$r;H$($P;H$$J,$1$k$3$H$,=PMh$=$&$G$9$,!#(B

$B$H$j$"$($:!"(B
ISO-2022-* $B$NMM$K%m%1!<%k$K$OL5$$%(%s%3!<%G%#%s%0$b$"$j$^$9$7!"(B
$B%m%1!<%k$H%(%s%3!<%G%#%s%0$O@Z$jN%$7$F9M$($?J}$,$$$$$H;W$$$^$9!#(B
$BF~NO$G$-$J$$$+$i$C$FI=<($9$i;H$($J$/$J$k$N$O:$$k!#(B
----------------------------------- 
$B:dK\(B $B9@B'(B <hs...@mt...> 
 http://www2u.biglobe.ne.jp/~hsaka/

Re: [Mlterm-dev-ja] Response for ESC [ c

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

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] Response for ESC [ c
	From: MINAMI Hirokazu <mi...@ch...>
	Message-ID: <200...@ch...>
	Date: Tue, 11 Dec 2001 15:02:00 +0900

> これは、ESC-D では画面の下端以外ではスクロールしないことにするとまずいですか?
> # http://vt100.net/docs/vt100-ug/chapter3.html#IND とかには
> # いつもスクロールしろとはかかれてないですし。

        すっかり勘違いしておりましたが、どうもそういうことのようですね。
        スクロール動作ありのカーソル上下移動という位置付けが正しいようです。

        とりあえず、手元では、

        Test of cursor movements

        の一発目は、正常表示されるようになりました。

        後程 commit します。

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

[Mlterm-dev-ja] =?ISO-2022-JP?B?GyRCJW0lMSE8JWskSBsoQg==?= mlterm =?ISO-2022-JP?B?GyRCJE4lKCVzJTMhPCVHJSMlcyUwJCwwYyQmPmw5ZyRORn5OTxsoQg==?=

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

久保田です。

ちょっとやっかいな問題を見つけてしまいました。とりあえず mlterm を
起動し、それから mlconfig を使って現在のロケール以外のエンコーディングに
切り替えたとき、そのエンコーディングの文字が入力できないのです。

たとえば、ja_JP.eucJP ロケールで mlterm を起動し、mlconfig を使って
EUC-JP から UTF-8 に切り替え、setxkbmap il などの状態で AltGr と
他のキーを押しても、何も入力されません。

あるいは、ja_JP.eucJP ロケールで、mlterm -E UTF8 と起動しても、同じ
ことになります。

この原因は明らかで、キー入力に使っている XmbLookupString() は
ロケールが指示するエンコーディングで文字列を取得します。上記の例なら
EUC-JP エンコーディングで文字列を得ます。とうぜん、ヘブライ文字を
EUC-JP で表現することはできないので、入力することができません。


いくつか解決策があります。

1. ロケールによってしかエンコーディングを決められないようにする。
   つまり、ロケールが指定する以外のエンコーディングを使いたいと
   考えるユーザのほうが悪い、という立場をとる。
   (mlconfig 等からエンコーディングの設定を廃止する)。
   これだと、ロケールにないエンコーディングが使えなくなってしまいます。

2. mlconfig でエンコーディングを変えたとき、相当するロケールに
   自動的に変更するようにする。
   XIM の変更と同じようにする、ということです。が、これも、
   利用できるロケールがなければそのエンコーディングは使えません。

3. Xutf8LookupString() を使う。
   ぼくはこれがいちばんきれいな解のように思えます。CJK Han Unification
   などに原理的に対応できなくなりますが、どうせ現状でも対応できている
   OS などありませんし (つまり、XmbLookupString() を使うことで、
   CJK の漢字を使い分けることが可能な OS ってないでしょう、ということ)。

ちなみに、XTerm は、ja_JP.eucJP ロケールで xterm -u8 と起動しても、
その状態でヘブライ文字の入力ができます。それは、Xutf8LookupString()
を使っているからです。

いかがでしょうか。

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

[Mlterm-dev-ja] character shaping

[MINAMI H. <mi...@ch...>]

南です。

On Tue, 11 Dec 2001 16:22:59 +0900 (JST)
Hironori Sakamoto <hs...@mt...> wrote:

> カラーや bold, underline 等の効果があると顕著です。
> GNU-ls で ls --color /dev 等を表示した画面で
> コマンドライン編集をすると動作がもたつきませんか？

手元ではtime で計った ls --color /dev 85回分の所要時間はだいたい

--deisble-fribidi で作って	         14 s
--enable-fribidi でオプションなしで  14 s 
--enabele-fribidi で -km utf8 -bi    16 s
(+-0.5s)
で、bidi の有無で一割くらいはかわるようでした。
もっと劇的な違いがあるのでしょうか?

Re: [Mlterm-dev-ja] character shaping

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

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

> $B9SLZ$G$9(B:-)
> > $B$=$l$+$i!"(Bbidi $B$rM-8z$K$9$k$H(B(w3m-m17n $B$G(B)$B%+!<%=%k0\F0$4$H$K(B
> > $B$A$i$D$$$FF0:n$,CY$/$J$j$^$9!#(B
> > $B$H$3$m$G!":F8=$7$F$$$^$9$+!)(B
> $B$I$N$h$&$J>u67$+:#0l$D$o$+$i$J$$$N$G$9$,!">/$J$/$H$b!"A02s$N%Q%C%A$NM-L5(B
> $B$K4X$o$i$:!"$A$i$D$-$,5$$K$J$k$H$$$&$h$&$J$3$H$O$J$$$G$9!#(B
> $B%Q%C%A$rEv$F$k$H!":FIA2h$N2s?t$O$+$J$j8:$j$^$9$N$G!"$o$?$7$N$H$3$m$G:F8=(B
> $B$7$J$$$N$O!"%^%7%s%Q%o!<$H$+$J$K$+!"JL$NLdBj$+$7$i!"$H;W$C$?$N$G$9$,!"$=(B
> $B$&$$$&OC$G$O$J$5$=$&$G$9$M!#(B

$B%+%i!<$d(B bold, underline $BEy$N8z2L$,$"$k$H82Cx$G$9!#(B
GNU-ls $B$G(B ls --color /dev $BEy$rI=<($7$?2hLL$G(B
$B%3%^%s%I%i%$%sJT=8$r$9$k$HF0:n$,$b$?$D$-$^$;$s$+!)(B
# $B3N$+$K<j$b$H$N4D6-$OIO<e$G$9$,!D(B
----------------------------------- 
$B:dK\(B $B9@B'(B <hs...@mt...> 
 http://www2u.biglobe.ne.jp/~hsaka/