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

[Mlterm-dev-ja] mlconfig writes every settings

[Tomohiro K. <ku...@de...>]

久保田です。

mlconfig で、OK を選択すると、~/.mlterm/main に (変更しない
項目も含めて) すべての設定項目が書き込まれてしまいます。

ソースを読んだ結果、原因はだいたい分かったのですが、
なぜこういう実装になっているのかが分からないので、手が
出せずにいます。

いくつか質問があります。

1. ぼくはバグだと思ってるので修正したいのですが、じつはこれは
   仕様だとかいうことはないでしょうか。

2. doc/en/PROTOCOL を見ると、「set&save」というのがあるのに、
   mlconfig で OK ボタンを押したときにそれを使わずに、
   set してから save するのは、なにか理由がありますか?
   (set したときに、たとえば mc_char_encoding.c の old_encoding
   が更新されてしまうために、save するときに変更があったか
   どうかを判別できなくなってしまうという不都合があります)。

3. mc_io.c で、save_str と set_str があるのはなぜでしょうか。
   言い換えれば、save_str と set_str の両方が同時に非 NULL に
   なることは、あるのでしょうか? あるいは、将来的にそんな状況を
   作る可能性はあるでしょうか? というのは、これは今回の件とは
   直接は関係ないのですが、doc/en/PROTOCOL の値を mc_io.h で
   #define して、たとえば mc_set_flag_value() に与える save
   引数などにそれを使うようにできないかなと思っていたのです。
   そうすると、一度の mc_flush() 呼び出しで save と set の
   両方を行うということができなくなってしまうので。


できるだけ荒木さんの設計思想に反しないような形で修正したいので、
よろしくおねがいします。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/

Re: [Mlterm-dev-ja] Xft2

[Tomohiro K. <ku...@de...>]

久保田です。

From: MINAMI Hirokazu <mi...@ch...>
Subject: Re: [Mlterm-dev-ja] Xft2
Date: Wed, 19 Feb 2003 23:09:12 +0900

> > それは、将来的には一部になるはず、ということでしょうか?
> 
> パッケージとして統合されるかどうかはわかりませんが、配布は
> 一緒にされていたはずです。つまり XF86 がインストールできれば
> 必ず libxft2 も入れられるはずで、mlterm が libxft2 への依存性を
> 持つためにインストールできなくなる事態は起きないと思います。

インストールできなくなる、ということはないと思います。
単に、同じ機能を実現するのにディスクスペースを余分に食うのは
よくない、というくらいの意味です。


> > すみません、言いたかったのは、README.Debian には ~/.xftconfig
> > ファイルの書き方が載っている、ということです。
> 
> 現在の debian の fonts.conf 利用時には /usr/share/fonts 以下に
> 置かれたフォントは自動的に検出されるはずなので、実際に
> ユーザが~/.fonts.conf を書く必要はほとんどないのでは。
> 
> see fontconfig(3) だけではまずいですか?

Xft2 を意識して使うのは初めてなので、いろいろと試してみました。
すると、TrueType フォントパッケージ (たとえば ttf-baekmuk) を
インストールし、root で fc-cache を実行するとよいことが分かりました。
(パッケージのインストールだけでは、だめでした)。というわけで、
このことを README.Debian に書くつもりでいます。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/

Re: [Mlterm-dev-ja] Xft2

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

みなみです。

On Wed, 19 Feb 2003 22:11:06 +0900 (JST)
Tomohiro KUBOTA <ku...@de...> wrote:

> > libxft2 は Xfree86 の一部になるはずなので、
> > Depends は実質的には増えないと思います。
> 
> それは、将来的には一部になるはず、ということでしょうか?

パッケージとして統合されるかどうかはわかりませんが、配布は
一緒にされていたはずです。つまり XF86 がインストールできれば
必ず libxft2 も入れられるはずで、mlterm が libxft2 への依存性を
持つためにインストールできなくなる事態は起きないと思います。

> すみません、言いたかったのは、README.Debian には ~/.xftconfig
> ファイルの書き方が載っている、ということです。

現在の debian の fonts.conf 利用時には /usr/share/fonts 以下に
置かれたフォントは自動的に検出されるはずなので、実際に
ユーザが~/.fonts.conf を書く必要はほとんどないのでは。

see fontconfig(3) だけではまずいですか?

Re: [Mlterm-dev-ja] Xft2

[Tomohiro K. <ku...@de...>]

久保田です。

From: MINAMI Hirokazu <mi...@ch...>
Subject: Re: [Mlterm-dev-ja] Xft2
Date: Wed, 19 Feb 2003 20:11:19 +0900

> Xft2(というか fontconfig) の設定と ~/.mlterm/aafont の関係は
> Xft1 の設定と ~/.mlterm/aafont の関係と 同じはずです。
> 
> Xft1 では利用可能なフォントは  XftConfig
>  (debian だと  /etx/X11/XftConfig とか)に記述されており、
> これらのうちどれを使うかを aafont で指定していたわけですが、
> Xft2 では fonts.conf (/etx/fonts/fonts.config とか)で指定される
> ようになるのだと理解してます。

了解しました。


> libxft2 は Xfree86 の一部になるはずなので、
> Depends は実質的には増えないと思います。

それは、将来的には一部になるはず、ということでしょうか?


> > また、README.Debian に、Xft 設定のための手引きが書いてありますが、
> > それを書き換える必要があります。そのためには、ぼくが、Xft2 の設定を
> > 理解する必要があります。
> 
> fontconfig は確か coverage を見てフォントを置換できるところまで
> 賢いはずなので、fonts.conf で alias が設定できているエンコーディングの
> フォントについては、 ~/mlterm/aafont としては
> 
> 「とりあえず
> JISX0208_1978=Serif-iso10646-1:50;
> ISO10646_UCS4_1_BIWIDTH=Serif-iso10646-1;
> のように、全て Serif または Sans-Serif を指定」
> 
> でよくなるはずです。(ここまでは確認済)

すみません、言いたかったのは、README.Debian には ~/.xftconfig
ファイルの書き方が載っている、ということです。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/

Re: [Mlterm-dev-ja] Xft2

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

みなみです

On Wed, 19 Feb 2003 19:06:43 +0900 (JST)
Tomohiro KUBOTA <ku...@de...> wrote:
 
> > > Xft2 を使うメリットって、なんでしょうか？
> > 
> > ユーザから見える改善としては、
> >  gtk2 とか Qt3 (あとは Xft2 サポートの mozilla 系ブラウザ)では
> >  フォントの管理をXft2+fontconfig で行なっているはずなので、
> > これらと設定が共用できるようになるはずです。
> 
> Xft2 の設定って、やったことがないのですが、~/.mlterm/aafont
> の設定と、どのような関係になるのでしょうか。(競合する? どちらかが
> 優先される?)

Xft2(というか fontconfig) の設定と ~/.mlterm/aafont の関係は
Xft1 の設定と ~/.mlterm/aafont の関係と 同じはずです。

Xft1 では利用可能なフォントは  XftConfig
 (debian だと  /etx/X11/XftConfig とか)に記述されており、
これらのうちどれを使うかを aafont で指定していたわけですが、
Xft2 では fonts.conf (/etx/fonts/fonts.config とか)で指定される
ようになるのだと理解してます。

両者で同じフォントを同じ名前で記述していれば
(debian のデフォルトはそうなっていると思います)
 Xft1->Xft2 に伴うaafont の変更は必要ないはずです。
 
> 基本的には、ソフトウェアごとにいちいち設定しなければならない
> というのは良くないことなので、設定が共用できるようになる
> ことは、良いことだと思います。たんにぼくが理解してないだけです。
> 
> 
> > xft2 を使うのを避ける理由も特にない気がしますが、いかがでしょう。
> 
> いちばん大きな理由は、メリットがなければ Depends: を増やすのは
> いやだ、ということです。が、ちょっとでもメリットがあれば、
> かまわないと思っています。

libxft2 は Xfree86 の一部になるはずなので、
Depends は実質的には増えないと思います。

> また、README.Debian に、Xft 設定のための手引きが書いてありますが、
> それを書き換える必要があります。そのためには、ぼくが、Xft2 の設定を
> 理解する必要があります。

fontconfig は確か coverage を見てフォントを置換できるところまで
賢いはずなので、fonts.conf で alias が設定できているエンコーディングの
フォントについては、 ~/mlterm/aafont としては

「とりあえず
JISX0208_1978=Serif-iso10646-1:50;
ISO10646_UCS4_1_BIWIDTH=Serif-iso10646-1;
のように、全て Serif または Sans-Serif を指定」

でよくなるはずです。(ここまでは確認済)

デフォルトで alias が設定されてない領域を
使いたい場合には  fontconfig(3) 参照ということになると思いますが、
特になにもしなくても 日本語は扱えてしまったので確認はしてません。

> それから、よくわからない不具合として、Depends: のなかに、
> xlibs (>> 4.1.0) と xlibs (>>4.2.0) が存在してしまっています。
> これは、Xft2 を使わずにコンパイルすれば、回避できるのです。

depends: がどのようにつけられるのかはよくわかってないのですが、
build-dependsに libxft2-dev を足すと xlibs(>>4.2.0)だけになったりしません?

このへんはまだ安定してないようなので、
とりあえずは xft1 を使うようにするということでもいいとは思います。
その場合 debian の都合にあわせて configure.in で xft の CFLAGS/LIBS を
設定しているところを修正しておく必要があるかと。
(xft1 は pkg-config をサポートしてないので、たぶん 決め打ちすることに)  

Re: [Mlterm-dev-ja] Xft2

[Tomohiro K. <ku...@de...>]

久保田です。

From: MINAMI Hirokazu <mi...@ch...>
Subject: Re: [Mlterm-dev-ja] Xft2
Date: Wed, 19 Feb 2003 09:38:01 +0900

> みなみです。

どうもです。:-)

> #こうしないと 手許の環境でコンパイルが通らなかったので

なるほど、そういうことだったのですか。でもなんでだろう。

> > Xft2 を使うメリットって、なんでしょうか？
> 
> ユーザから見える改善としては、
>  gtk2 とか Qt3 (あとは Xft2 サポートの mozilla 系ブラウザ)では
>  フォントの管理をXft2+fontconfig で行なっているはずなので、
> これらと設定が共用できるようになるはずです。

Xft2 の設定って、やったことがないのですが、~/.mlterm/aafont
の設定と、どのような関係になるのでしょうか。(競合する? どちらかが
優先される?)

基本的には、ソフトウェアごとにいちいち設定しなければならない
というのは良くないことなので、設定が共用できるようになる
ことは、良いことだと思います。たんにぼくが理解してないだけです。


> xft2 を使うのを避ける理由も特にない気がしますが、いかがでしょう。

いちばん大きな理由は、メリットがなければ Depends: を増やすのは
いやだ、ということです。が、ちょっとでもメリットがあれば、
かまわないと思っています。

また、README.Debian に、Xft 設定のための手引きが書いてありますが、
それを書き換える必要があります。そのためには、ぼくが、Xft2 の設定を
理解する必要があります。

それから、よくわからない不具合として、Depends: のなかに、
xlibs (>> 4.1.0) と xlibs (>>4.2.0) が存在してしまっています。
これは、Xft2 を使わずにコンパイルすれば、回避できるのです。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/

Re: [Mlterm-dev-ja] Xft2

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

みなみです。

On Wed, 19 Feb 2003 08:35:45 +0900 (JST)

Tomohiro KUBOTA <ku...@de...> wrote:
> Debian パッケージの話題ですみませんが、Xft2 に依存するように
> なっています。「なっています」というのは、うっかりそうなって
> しまったからです。また、パッケージの「Depends」の行には Xft2
> 関連パッケージが載っているものの、実際に Xft2 を使っているか
> どうかは未確認です。

12月ころに  Xft のライブラリ/ヘッダのためのコンパイラオプションに
pkg-config に登録されている "xft" の情報を使うようにしました。

これに伴ない、xft2 のヘッダ(debian では libxft2-dev パッケージ) が
インストールされている環境では xft2 が xft1 より優先して使われるはずです。

#こうしないと 手許の環境でコンパイルが通らなかったので

> Xft2 が実際に使われていて、Xft2 移行に何かメリットがあれば、
> そのまま行こうと思っていますが、特になければ、元に戻そうと
> 思っています。
> 
> Xft2 を使うメリットって、なんでしょうか？

ユーザから見える改善としては、
 gtk2 とか Qt3 (あとは Xft2 サポートの mozilla 系ブラウザ)では
 フォントの管理をXft2+fontconfig で行なっているはずなので、
これらと設定が共用できるようになるはずです。

xft2 を使うのを避ける理由も特にない気がしますが、いかがでしょう。

[Mlterm-dev-ja] Xft2

[Tomohiro K. <ku...@de...>]

久保田です。

Debian パッケージの話題ですみませんが、Xft2 に依存するように
なっています。「なっています」というのは、うっかりそうなって
しまったからです。また、パッケージの「Depends」の行には Xft2
関連パッケージが載っているものの、実際に Xft2 を使っているか
どうかは未確認です。

Xft2 が実際に使われていて、Xft2 移行に何かメリットがあれば、
そのまま行こうと思っていますが、特になければ、元に戻そうと
思っています。

Xft2 を使うメリットって、なんでしょうか？
（将来的には、mlconfig を GTK2 ベースにしたいと思っているので、
その際には Xft2 に移行したほうがいいと思いますが）。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/

Re: [Mlterm-dev-ja] Fwd: Bug#181318: mlterm can not work with bitchx ( cjk input )

[Nobuyoshi N. <nob...@so...>]

なかだです。

At Tue, 18 Feb 2003 11:25:47 +0900 (JST),
Tomohiro KUBOTA wrote:
> どうやら、ひとつのマルチバイト文字を構成するバイトとバイトの間に、
> カーソル移動のエスケープシーケンスが割り込んでいる場合にも、
> マルチバイト文字をきちんと表示して欲しい、ということだと思います。

ということのようですね。

> >   So I launch the program "script" to see what happens. I found that the
> >   echo from bitchx work in this way: a vt100 sequence moving the cursor,
> >   then a single character(half the multibyte character), then sequence
> >   again, .... , and so on. 

これは、このbitchxというプログラムがマルチバイト化されていない
という問題であって、mltermで対応する話ではないと思います。

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

Re: [Mlterm-dev-ja] mlterm segfaults because of ptsname()

[Tomohiro K. <ku...@de...>]

久保田です。

From: Seiichi SATO <ss...@sh...>
Subject: Re: [Mlterm-dev-ja] mlterm segfaults because of ptsname()
Date: Tue, 18 Feb 2003 00:53:19 +0900

> 2.4.x では -c を指定した時、同時に -q が指定された場合でも
> 条件にマッチする行数が出力されるのですが、2.5.x では -q を同時に指定すると
> -c は無視される(というか -q に従う)みたいです。
> (RedHat 7.3 の 2.4.2 と Debian sid の 2.5.1 で確認しました。)

Debian の Bug#181409 として、きのう報告されたようです。
http://bugs.debian.org/181409

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/

[Mlterm-dev-ja] Fwd: Bug#181329: mlterm_2.6.3.cvs20030216-1(mipsel/unstable): configure built with broken libtool.m4

[Tomohiro K. <ku...@de...>]

久保田です。

またまた、Debian のバグ報告の転送です。

libtool 関係のバージョンをあげてくれ、とのことだそうです。
mips/mipsel アーキテクチャでのコンパイルを可能にするために、
バージョンを 1.4.2-7 以上にしろとのこと。「-7」の部分は Debian
パッケージ固有のバージョン番号なので、一般的には 1.4.3 以上に
すればいいと思います。(最新版は 1.4.3 のようです)。

こっちでも試してみますが、libtool の使い方があまりよくわかって
いないので、でたらめな変更を加えてしまう恐れがあります。
ですので、もしよろしければ、荒木さんのほうでやっていただけると
うれしいです。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/



From: Ryan Murray <rm...@de...>
Subject: Bug#181329: mlterm_2.6.3.cvs20030216-1(mipsel/unstable): configure built with broken libtool.m4
Date: Sun, 16 Feb 2003 22:58:32 -0800

> Package: mlterm
> Version: 2.6.3.cvs20030216-1
> Severity: serious
> 
> There was an error while trying to autobuild your package:
> 
> > Automatic build of mlterm_2.6.3.cvs20030216-1 on repeat.rfc822.org by sbuild/mipsel 1.170
> > Build started at 20030216-0735
> 
> [...]
> 
> > ** Using build dependencies supplied by package:
> > Build-Depends: debhelper (>> 3.0.0), libgdk-pixbuf-dev, libgtk1.2-dev, libtool, xlibs-dev, libfribidi-dev, ncurses-bin
> 
> The version of libtool used to build this source package is too old to
> correctly support shared libraries for the Debian mips and mipsel
> architectures.  At least version (1.4.2-7) and higher correctly supports
> them.  You need to update all of the libtool related files by running
> the following on your source tree:
> 
> 	autoreconf --force
> 
> You may need to use the --install option as well.  You can also try the
> individual commands needed yourself:
> 
> 	libtoolize --force --copy
> 	aclocal
> 	autoheader
> 	automake -a
> 	autoconf
> 
> autoheader may not be needed, and you may need to use versioned binaries
> (autoconf2.13, automake-1.{4,5,6,7}, aclocal-1.{4,5,6,7}, etc)
> 
> The correct 'configure' script will have output that looks like this:
> # This must be Linux ELF.
> linux-gnu*)
>   case $host_cpu in
>   alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* )
>     lt_cv_deplibs_check_method=pass_all ;;
>   *)
> 
> It is important that both mips and mipsel are listed in the configure script
> here.
>   
> Older versions of libtool used a file_magic check for the pattern
> file_magic ELF [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib )
> 
> The output of file(1) on a shared library on MIPS does not match this
> regular expression, however.  Earlier versions of file had been
> modified to match this regular expression, but the latest version uses
> the same output as upstream once again.  The file check often causes
> problems, and results on a build-dep on file that you might not
> otherwise be aware of.  The new method doesn't need file(1) at all,
> and is far less fragile, so it is best to upgrade the configure script
> with proper mips support.
> 

[Mlterm-dev-ja] Fwd: Bug#181318: mlterm can not work with bitchx ( cjk input )

[Tomohiro K. <ku...@de...>]

久保田です。

Debian へのバグ報告の転送です。

どうやら、ひとつのマルチバイト文字を構成するバイトとバイトの間に、
カーソル移動のエスケープシーケンスが割り込んでいる場合にも、
マルチバイト文字をきちんと表示して欲しい、ということだと思います。

# おそらく、カーソル移動というよりはカーソル位置指定のエスケープ
# シーケンスのことを言っているのではないかと思います。たんに
# 文字列をふつうに表示するために、ひと文字出力するたびにいちいち
# カーソル位置指定を入れるソフトウェアって、存在したりするので。
# ちなみに、ぼくが初めて PC Unix 関連でパッチを書いたのが、
# minicom という BBS Client みたいなソフトウェアの、まさしく
# この問題の解決でした。

ぼく自身はあまり優先順位は高くないかなと思っていますが、こういう
要望があります、ということです。というのは、これは一見便利なように
見えますが、バイト数とカラム数が一致しないような場合に、
アルゴリズムが破綻するからです。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/


---------以下、バグ報告の内容です。

From: Wang WenRui <wa...@ma...>
Subject: Bug#181318: mlterm can not work with bitchx ( cjk input )
Date: Mon, 17 Feb 2003 10:39:56 +0800

> Package: mlterm
> Version: 2.6.3.cvs20030216-1
> Severity: normal
> Tags: upstream
> 
>   In the irc client bitchx, when you input a word in Chinese(I guess all
>   the multibyte-characters have this problem), the cursor moves but
>   the echo is nothing. Then press CR, the correct word is sent.
> 
>   So I launch the program "script" to see what happens. I found that the
>   echo from bitchx work in this way: a vt100 sequence moving the cursor,
>   then a single character(half the multibyte character), then sequence
>   again, .... , and so on. 
> 
>   Then I could draw a conclution that mlterm doesn't merge two halfs of
>   a multibyte-character when there is vt100 sequences between them.
>   Isn't it?
> 
> -- System Information:
> Debian Release: testing/unstable
> Architecture: i386
> Kernel: Linux winter 2.4.18-686 #1 Sun Apr 14 11:32:47 EST 2002 i686
> Locale: LANG=zh_CN.GBK, LC_CTYPE=zh_CN.GBK (ignored: LC_ALL set)
> 
> Versions of packages mlterm depends on:
> ii  libc6                         2.3.1-11   GNU C Library: Shared libraries an
> ii  libfontconfig1                2.1-14     generic font configuration library
> ii  libfreetype6                  2.1.3-9    FreeType 2 font engine, shared lib
> ii  libfribidi0                   0.10.4-0.1 Free Implementation of the Unicode
> ii  libgdk-pixbuf2                0.22.0-1   The GdkPixBuf image library, gtk+ 
> ii  libglib1.2                    1.2.10-6   The GLib library of C routines
> ii  libgtk1.2                     1.2.10-14  The GIMP Toolkit set of widgets fo
> ii  libxft2                       2.1-7      advanced font drawing library for 
> ii  xlibs                         4.2.1-5    X Window System client libraries
> ii  zlib1g                        1:1.1.4-9  compression library - runtime
> 
> -- no debconf information
> 
> 

Re: [Mlterm-dev-ja] mlterm segfaults because of ptsname()

[Seiichi S. <ss...@sh...>]

佐藤です。

On Mon, Feb 17, 2003 at 07:54:00PM +0900,
 Tomohiro KUBOTA wrote:

> # どこでこけてるかが分かれば、BTS 行きなんですけど。
> # 佐藤さん、分かりますか? って、ここで議論するのは

/etc/init.d/devpts.sh では

    devpts_avail=`grep -qci '[<[:space:]]devpts' /proc/filesystems || true`

みたいなことをしてカーネルが devpts をサポートしているかとか
既に mount 済みかとかを調べているのですが
GNU の grep が 2.4.x -> 2.5.x で -qc の動きが変わったため devpts.sh
の期待する結果が得られないようです。

2.4.x では -c を指定した時、同時に -q が指定された場合でも
条件にマッチする行数が出力されるのですが、2.5.x では -q を同時に指定すると
-c は無視される(というか -q に従う)みたいです。
(RedHat 7.3 の 2.4.2 と Debian sid の 2.5.1 で確認しました。)

-- 
Seiichi SATO <ss...@sh...>

Re: [Mlterm-dev-ja] mlterm segfaults because of ptsname()

[Tomohiro K. <ku...@de...>]

久保田です。

佐藤さん情報がビンゴでした。

> 僕の環境(Debian sid)でも再現しました。
>
> Debian の /etc/init.d/devpts.sh がおかしいみたいです。
> (途中でこけるため /dev/pts/ が mount されていない)
>
> 試しに手で
>
>     # mount -t devpts none /dev/pts/
>
> した後に mlterm を起動したら segfault しなくなりました。

Debian 固有の問題です。

# どこでこけてるかが分かれば、BTS 行きなんですけど。
# 佐藤さん、分かりますか? って、ここで議論するのは
# 場違いですね。

ただし、x_sb_screen_delete() の2回呼び問題は未解決ですが。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/

[Mlterm-dev-ja] mlterm segfaults because of ptsname()

[Tomohiro K. <ku...@de...>]

久保田です。

mlterm が、segfault します。じつはこちらの環境のせいである
可能性が高いのですが (mlterm 側に問題がある可能性は皆無では
ないと思うのですが)、pty 関連のところで問題が起きているっぽい
ので、ここで質問させてもらいます。

じつは、最新の CVS 版 mlterm だけではなく、過去のバージョン
(たとえば、2.6.2 とか) でも segfault します。きのうまで
そんなことはなかったのに。昔に作った (コンパイルした)
Debian パッケージでも segfault するので、こちらの環境が
なにか変化してしまっていることは確実です。Debian unstable
(sid) ですので、どこかのパッケージの更新が原因になっている
可能性があります。一方で、こちらの環境が変化したのは確か
なんだけれども、それは正常な変化で、mlterm がその変化に
ついていけないのがおかしい、との可能性もあると思います。


とにかく、原因を調べてみました。原因は、ふたつあるようです。

まずひとつめですが、x_term_manager.c の open_term() で、
open_pty_intern() を呼んでいますが、これが失敗しています。
その原因は、kiklib/src/kik_pty_streams.c の kik_pty_fork()
の失敗です。その原因は、ptsname() の失敗です。NULL が返って
います。

open_pty_intern() の失敗を受け、goto error するのですが、
そのエラー処理に問題があり、単に終了するのではなく、segfault
するようになってしまっているようです。これがふたつめの問題です。
その原因は、x_sb_screen_delete() が同じ引数で 2 回呼ばれている
ことです。1回目は、open_term() のエラー処理部分の x_display_close()
から。2回目は、同じくx_sb_screen_delete() からです。


---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/

Re: [Mlterm-dev-ja] ISO-8859-11 cannot be used

[Tomohiro K. <ku...@de...>]

久保田です。

From: Araki Ken <ara...@us...>
Subject: Re: [Mlterm-dev-ja] ISO-8859-11 cannot be used
Date: Sat, 15 Feb 2003 15:27:59 +0900

>         すみません、いい機会だったので、あれから mlconfig を全面的に改造
>         しちゃいました。
>         外部設定プログラムとの通信が doc/en/PROTOCOL ベースになる前から
>         の設計をずっとひきずってたので...
> 
>         一応、メンテナは久保田さんということになってたかと思いますが、
>         UI 的なところは一切いじっていませんので、勝手に commit しちゃっ
>         てます ^_^;

そのほうがいいです。最近ほとんど時間がとれないので、cvs commit したいと
思うことはめったになくなると思うので、ぼくのことを気にせずに、
どんどんいじってください。

ところで、いくつか気付いたことです。


・設定ファイル main の encoding に、「ロケールに従う」という意味の
  設定が出来るようにしたほうがいいのではないでしょうか。というのは、
  mlconfig が main に書き込んでしまうようになったので、従来の
  「encoding が指定されていなければロケールに従う」だけだと、
  mlconfig からその設定が出来ないためです。たとえば、
  「encoding = locale」と指定すると「ロケールに従う」という設定に
  なるようにするなど。mlconfig のエンコーディングのところにも、それに
  対応する項目が必要ですが、「locale (currently %s)」というふうに
  なっていると分かりやすくていいと思います。ただし、mlterm の側が、
  現在のエンコーディングは明示的に設定されたのか、それともロケールに
  従って決めたものかを覚えておいて、mlconfig に伝える必要があります。

・mlconfig のエンコーディング一覧で、「EUC-CN」を「EUC-CN (GB2312)」
  と変更したほうがいいかも。EUC-CN はエンコーディング、GB2312 は
  符号化文字集合で、ほんらい別物ですので、EUC-CN のことを GB2312
  と呼ぶのは誤りですが、分からないと意味がないですから。

・mlconfig の、エンコーディング一覧が、どんな順に並んでいるのかが
  分かりにくいです。すべてのエンコーディング名を知っている人しか、
  それを理解できません。完全にアルファベット順にしてしまうか、
  言語を注釈で書くようにするか、すればよいと思います。アルファベット
  順にするほうが簡単ですが、「TIS-620 がない」「GB2312 がない」
  といった苦情がきそう。

  言語注釈ですが、「EUC-JP (Japanese)」というふうにすべてに書くか
  (Japanese というところは gettext にするのもよいと思います)、
  現在の言語ごとにまとまっているというのを生かして「--- Japanese ---」
  というようなダミー項目 (これも gettext にしたほうがいい) を
  入れるかが良いと思います。前者の場合には、
  「EUC-CN (GB2312) (simplified Chinese)」などの項目が長くなりすぎて、
  あまりよくないかも。後者の場合は、GTK のコンボボックスで、ダミー
  項目を選べないように設定することが出来たほうがいいですが、それって
  できましたっけ?

・たぶん US ASCII フォントが見つからない場合に相当すると思うのですが、
  mlterm -E ISO-8859-6 などとすると、何も言わずに終了してしまいます。
  終了させるにしても、なぜ終了したのかが分かるようなメッセージを
  出力するほうがいいと思います。

・make distclean 問題ですが、残ってしまうファイルをすべて rm -f
  するように Debian パッケージ作成スクリプトを作ることで、対応
  できそうです。この方法のほうがいいかもしれません。というのは、
  Makefile そのものを消すのは、最後にまとめてのほうが安全ですので。
  (もし make distclean が途中でエラーを起こしたり、Ctrl-C で中断
  した場合、Makefile が消えていると再開できなくなってしまいます)。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/

Re: [Mlterm-dev-ja] ISO-8859-11 cannot be used

[Araki K. <ara...@us...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] ISO-8859-11 cannot be used
	From: Tomohiro KUBOTA <ku...@de...>
	Message-ID: <200...@tm...>
	Date: Sat, 15 Feb 2003 10:41:41 +0900 (JST)

        すみません、いい機会だったので、あれから mlconfig を全面的に改造
        しちゃいました。
        外部設定プログラムとの通信が doc/en/PROTOCOL ベースになる前から
        の設計をずっとひきずってたので...

        一応、メンテナは久保田さんということになってたかと思いますが、
        UI 的なところは一切いじっていませんので、勝手に commit しちゃっ
        てます ^_^;

        # 久保田さんが framework 的なところを変更されることはないと思いま
        # すので。
        
        都合がわるそうでしたら、差分を元に戻してくださいませ。

        今日のところは、これで体力が切れたので、久保田さんのパッチ等々に
        ついては、また後日に _o_

	では
--
Araki Ken
ara...@us...

Re: [Mlterm-dev-ja] ISO-8859-11 cannot be used

[Tomohiro K. <ku...@de...>]

久保田です。

From: Araki Ken <ara...@us...>
Subject: Re: [Mlterm-dev-ja] ISO-8859-11 cannot be used
Date: Sat, 15 Feb 2003 09:00:32 +0900

> > 不具合が見つかりました。ISO-8859-11 (TIS-620) が、使えないのです。
> > mlconfig で選んでも違うエンコーディングになってしまいますし、
> > また、mlterm -E ISO-8859-11 とやってもだめです。
> 
>         mlconfig の表示がおかしいだけで、mlterm 本体は、正常に動作してます。
>         mlconfig も修正しましたので直っていると思います。

じつは、こちらでも mlconfig の修正作業をやってました。mlconfig が
encoding を ~/.mlterm/main に出力する際、スペース (0x32) 以下を
無視するようにしてみました。が、荒木さんの修正のほうが早かったようです。

荒木さんの修正も見てみました。ぼくのやりかたが、mc_io.c で出力時に
エンコーディング名を修正するのに対して、荒木さんのやりかたは、
mc_char_encoding.c 内に収まっているので、荒木さんのほうが、より
正しい方法だと思います。

ただ、完全に regularized してしまうと、~/.mlterm/main が読みにくくなる
(たとえば、ISO885916 ってのは、ちょっと読みにくい) かなとも思います。
この点については、ぼくのやりかたのほうがいいかなと思います。

それから、添付したパッチでは、char regularized[] を不要にする変更が
はいっています。今後、エンコーディングを増やしたりしたときに、
バグが混入する可能性を減らせると思います。(最近の gnome-terminal は、
windows-???? とかグルジア語といったエンコーディングをサポートしている
ようです)。

適当に取捨選択していただければうれしいです。



それから、./configure ; make ; make distclean したとき、アーカイブの
もとの状態に戻りません。詳しく調査してないのですが、mkf/kiklib という
シンボリックリンクや、tools/mlconfig/po/*.gmo というファイルや、
Makefile や configure 関連ファイルが残ってしまいます。Debian の
パッケージ作成時、make distclean してから、オリジナルのソースツリーと
Debian 用にカスタマイズしたソースツリーの diff をとり、ソース
パッケージの一部とする、ということをします。このとき、configure
関連ファイルが残っていると diff が巨大化しますし、シンボリックリンクや
バイナリファイル (*.gmo) があると diff がエラーで停止してしまいます。
また、Debian 用にどのようにカスタマイズしたのかということを、
diff を読むと分かるはずなのに、それが configure 関連ファイルに埋もれて
分からなくなってしまうという弊害もあります。

ちなみに、Debian パッケージ作成時に、diff をとる前に実行するコマンドは、
パッケージ作成者が自由に設定できます。たとえば、*.gmo ファイルについては、
make -C tools/mlconfig maintainer-clean とすれば消せることを突き止めた
ので、それで対処できます。

configure 関連はよくわからないので、すみませんが、ちょっと調べて
いただけないでしょうか。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/

Re: [Mlterm-dev-ja] Pseudo-tabbed mlterm

[Araki K. <ara...@us...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] Pseudo-tabbed mlterm
	From: hs...@mt... (Hironori SAKAMOTO)
	Message-ID: <200...@mt...>
	Date: Wed, 12 Feb 2003 01:15:17 +0900 (JST)

> あるウィンドウ上で OPEN_PTY で新しい pty を開くと、現在の
> pty は非アクティブになるのですが、その後、 mlclient すると、
> その非アクティブな pty が立ち上がってきます。
> そういうものなのでしょうか。

        そうしないようにしました。

> ついでに、mlcient のちょっとした修正です。

        merge させていただきました _o_

> あと、xwindow/x_term_manager.c の
>        if( argc >= 2 && strncmp( argv[1] , "pty_list" , 4) == 0)
>                                                         ↑
> は、わざとですか？
> # mlcient -P = mlclient pty_list でも良い気がしますがどうでしょうか。

        -P,--ptylist オプションにしました。

	では
--
Araki Ken
ara...@us...

Re: [Mlterm-dev-ja] Pseudo-tabbed mlterm

[Araki K. <ara...@us...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] Pseudo-tabbed mlterm
	From: Seiichi SATO <ss...@sh...>
	Message-ID: <20030211170830.GA23463%ss...@sh...>
	Date: Wed, 12 Feb 2003 02:08:31 +0900

> 窓のサイズを変更した後で background の pty に
> 切替えると変更前のサイズに戻されてしまいます。
>
> # サイズは 各 pty 毎 に持っているから?
>
> サイズが変更された時は background の pty にも適用されるのが
> 自然な気がするのですが、いかがでしょうか?

        それやると、たとえば、Window A(50x25) と Window B(70x30) がある
        場合に、どうするか、っちゅー問題が発生してしまいます。
        background の pty は、どの Window にも表示されえますから、サイズ
        変更を background pty に適用することは考えていません。

	では
--
Araki Ken
ara...@us...

Re: [Mlterm-dev-ja] ISO-8859-11 cannot be used

[Araki K. <ara...@us...>]

	荒木です:-)

	Subject: [Mlterm-dev-ja] ISO-8859-11 cannot be used
	From: Tomohiro KUBOTA <ku...@de...>
	Message-ID: <200...@tm...>
	Date: Thu, 13 Feb 2003 01:54:33 +0900 (JST)

> 不具合が見つかりました。ISO-8859-11 (TIS-620) が、使えないのです。
> mlconfig で選んでも違うエンコーディングになってしまいますし、
> また、mlterm -E ISO-8859-11 とやってもだめです。

        mlconfig の表示がおかしいだけで、mlterm 本体は、正常に動作してます。
        mlconfig も修正しましたので直っていると思います。
        ついでに、5380 シーケンスで、返すエンコーディング名を TIS620 から
        ISO885911 に変更しました。

> それとは別に、us ascii 用フォントが見つからないというメッセージが
> 出るような場合に segfault するという問題が発生しています。
> こちらでは、たとえば ISO-8859-6 を指定するとこの症状が起きます。

        ほんとですね ^_^;
        下手に頑張ってもしかたないので、素直に exit(1) するようにしました。

	では
--
Araki Ken
ara...@us...

Re: [Mlterm-dev-ja] ISO-8859-11 cannot be used

[Tomohiro K. <ku...@de...>]

久保田です。

From: Tomohiro KUBOTA <ku...@de...>
Subject: [Mlterm-dev-ja] ISO-8859-11 cannot be used
Date: Thu, 13 Feb 2003 01:54:33 +0900 (JST)

> 不具合が見つかりました。ISO-8859-11 (TIS-620) が、使えないのです。
> mlconfig で選んでも違うエンコーディングになってしまいますし、
> また、mlterm -E ISO-8859-11 とやってもだめです。

mlconfig の問題について調べてみました。mlconfig で ISO-8859-11
を選んで OK すると、~/.mlterm/main に、「ENCODING = ISO-8859-11 (TIS-620)」
との行が書き込まれます。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/

Re: [Mlterm-dev-ja] substitution between declaretion

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

みなみです

On Thu, 13 Feb 2003 11:49:10 +0900
KATO Kazuyoshi <ka...@zb...> wrote:

> コンパイルが通らなかったので、なにかと思ったら 宣言部の途中に代入があ
> りました。

ありがとうございます。修正しておきました。

[Mlterm-dev-ja] substitution between declaretion

[KATO K. <ka...@zb...>]

こんにちは。

コンパイルが通らなかったので、なにかと思ったら 宣言部の途中に代入があ
りました。

こんなパッチで良いでしょうか。

Index: xwindow/x_imagelib_gdk.c
===================================================================
RCS file: /cvsroot/mlterm/mlterm/xwindow/x_imagelib_gdk.c,v
retrieving revision 1.44
diff -u -r1.44 x_imagelib_gdk.c
--- xwindow/x_imagelib_gdk.c	12 Feb 2003 13:00:52 -0000	1.44
+++ xwindow/x_imagelib_gdk.c	13 Feb 2003 02:37:25 -0000
@@ -1278,8 +1278,8 @@
 			XColor *  color_list ;
 			int num_cells ;
 			u_int8_t *  data ;
-			data = (u_int8_t *)(image->data) ;
 			Colormap  cmap = DefaultColormap( display, screen) ;
+			data = (u_int8_t *)(image->data) ;
 			
 			num_cells = DisplayCells( display , screen) ;
 			color_list = malloc( num_cells * sizeof(XColor)) ;

[Mlterm-dev-ja] ISO-8859-11 cannot be used

[Tomohiro K. <ku...@de...>]

どうも。久保田です。

Debian の mlterm パッケージをもうそろそろ更新しようと思って、
いろいろとテストしています。（というほどでもないですが）。

不具合が見つかりました。ISO-8859-11 (TIS-620) が、使えないのです。
mlconfig で選んでも違うエンコーディングになってしまいますし、
また、mlterm -E ISO-8859-11 とやってもだめです。

もしかしたら、こちらの環境のせい（たとえばフォント）かもしれませんが、
同様の症状が起きているかどうか、試していただけないでしょうか？


それとは別に、us ascii 用フォントが見つからないというメッセージが
出るような場合に segfault するという問題が発生しています。
こちらでは、たとえば ISO-8859-6 を指定するとこの症状が起きます。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/