アカウント名:
パスワード:
非ヨーロッパ言語系の人々から見ればかなり独善的なことをばしばし言う人ですが、なぜか、けっこう大きな発言力を持っているみたいです。
が、BiDi に関しての、実装は、BiDi に関するターミナルの動作をきちっと定義してからにしろ [xfree86.org]という意見は、まともな意見に思えます。mlterm [sourceforge.net] は「便利だったらいいや」というノリなので FriBidi を使った BiDi サポートを実装しましたが、BiDi に関しては ライブラリによって動作が微妙に違う [nmsu.edu]ということがあるようで、動作を定義しないことにはその上で動くアプリケーションソフトも作れない、といった状況に陥る可能性があります。
ちなみに、オフトピになりますが、全角文字に関して、彼はこんなこと [xfree86.org]を言ってます。つまり、全角文字を横切るようなカーソル移動コントロールコードの動作について、文字単位にすべきか、カラム単位にすべきか、ということです。MS-DOS プロンプトや N88-BASIC(86) や kterm をはじめ、ぼくが知る限りありとあらゆる日本語ターミナルが「カラム単位」の動作をしますが、それは「文字単位」であるべきだ、というのが彼の論旨です。
が、結合文字がはいってくると、ユーザインターフェースとしてどういう動作が好ましいか、ということ自体が分からなくなってきます。
M-x terminal-emulator の動作ですが、それはシェルの動作に依存するのではないですか?
ところで、\b ってカーソルを1カラム (1文字?) 左へと移動させるだけで、文字を消すのではないと思いますが、なぜ消えるのでしょうか?
\b ってカーソルを1カラム (1文字?) 左へと移動させるだけで、文字を消すのではない
だから,カーソルがどこまで動いたのかを知るためには,文字を上書きしてみせる必要があるのですよ。
たとえば,
echo 漢字文字列^H^Ha > /dev/pts/123
とかやってみて (ここで ^H は Backspace 文字を示す。入力時には Control-V Control-H と打ち込む),出力が
漢字文字a
となるか,あるいは
漢字文a列
となるかで,^H 一個で「一カラム」ぶん動いたのか,「一文字」ぶん動いたのか調べるわけです。ちなみに,手元の emacs では後者の動作を示しました。(中間に空白は入りませんでした)
しかしまあ,Backspace の動作の話題になると,毎回,
あたりの話がすべてごっちゃになって出てくるのは,何とも言えませんなあ。
ユーザインターフェース的には、文字単位の処理になっていることが必要です。というのは、Shift_JIS や EUC-JP では全角文字についてもバイト数とカラム数が一致していたので、Backspace キーを 2 回押すことでなんとかごまかしが効きましたが、UTF-8 ではそれは一致しないですし (かなやハングルや日常で使う漢字のほとんどは 2 カラム 3 バイト、ロシア文字やギリシャ文字やその他多くの文字は 1 カラム 2 バイト)、結合文字 (0 カラム) なんてのもあります。
まさしくプログラマに関係する話です。エンドユーザにはあまり関係しません。
ところで、カラムとセルってどう違うのですか?
まあ、ふつうは ASCII + JIS X 0208 しか使わないということで。
厳密には SS2 なり SS3 なりは CR やら LF やらと同じ制御シーケンスの一種と (ISO-2022 的には) 考えるべきなんじゃないですかね? もちろん、JIS X 0201 カナや JIS X 0212 補助漢字は 2 / 3 バイトと数える人が殆どでしょうし、実際そのように考えた方が便利だからこそ eucJP が使われるわけですが。
ところで、こういう用途って UTF-8 (というよりも ISO-10646 そのもの) はあんまり向いてないんじゃないですかね? 下手にきちんと扱い得る潜在能力があるだけに、却って泥沼化しそうな気がするんですけど。
厳密には SS2 なり SS3 なりは CR やら LF やらと同じ制御シーケ ンスの一種と (ISO-2022 的には) 考えるべきなんじゃないですかね?
その通りかもしれませんが、いまは、Backspace キーを押したときにシェルが内部バッファから何バイト削除しないといけないかという話ですので、それが正しく実現できさえすれば、どちらの考えに立っても構いません。
ところで、こういう用途って UTF-8 (というよりも ISO-10646 そのもの) はあんまり向いてないんじゃないですかね?下手にきちんと扱い得る潜在能力があるだけに、却って泥沼化しそうな気がするんですけど。
なにが「下手」なのか、「泥沼化」とは具体的にどういうことかが分からないのですが、EUC-JP や Shift_JIS においては偶然バイト数とカラム数が (JIS X 0208 について) 一致するという幸運に恵まれてきたわけですが、そういう幸運に頼ることのできない言語があり (タイ語など; 0 カラムの文字がありますが、それらを 0 バイトにすることはできません)、どうせ「きちんと扱」う必要が出てきます。
全角文字をどうするか、BiDiをどうするか、とかいってなかなかモデルが決まらな いことがまさに「泥沼化」なのでは。
なるほど。そうですね。
が、これは Unicode のせいではありません。現実に使われている文字が (全角はさておき) BiDi であったり結合文字であったりするので、 Unicode を使おうと、ISO-2022 や TRON コードなど別の文字コードを使おうと、 文字コードの側でそれをなかったことにすることはできません。
まあ、全部いっぺんにつめこむ「だけ」なら、できると思います。 問題は、各々の言語圏で従来まで使われてきた慣例どうしの擦り合わせでしょう。 誰がどこまで妥協すべきか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
BiDi (スコア:5, 参考になる)
非ヨーロッパ言語系の人々から見ればかなり独善的なことをばしばし言う人ですが、なぜか、けっこう大きな発言力を持っているみたいです。
が、BiDi に関しての、実装は、BiDi に関するターミナルの動作をきちっと定義してからにしろ [xfree86.org]という意見は、まともな意見に思えます。mlterm [sourceforge.net] は「便利だったらいいや」というノリなので FriBidi を使った BiDi サポートを実装しましたが、BiDi に関しては ライブラリによって動作が微妙に違う [nmsu.edu]ということがあるようで、動作を定義しないことにはその上で動くアプリケーションソフトも作れない、といった状況に陥る可能性があります。
ちなみに、オフトピになりますが、全角文字に関して、彼はこんなこと [xfree86.org]を言ってます。つまり、全角文字を横切るようなカーソル移動コントロールコードの動作について、文字単位にすべきか、カラム単位にすべきか、ということです。MS-DOS プロンプトや N88-BASIC(86) や kterm をはじめ、ぼくが知る限りありとあらゆる日本語ターミナルが「カラム単位」の動作をしますが、それは「文字単位」であるべきだ、というのが彼の論旨です。
Re:BiDi (スコア:1)
M-x terminal-emulator で動作するモードのことです。
Re:BiDi (スコア:3, 参考になる)
が、結合文字がはいってくると、ユーザインターフェースとしてどういう動作が好ましいか、ということ自体が分からなくなってきます。
M-x terminal-emulator の動作ですが、それはシェルの動作に依存するのではないですか?
Re:BiDi (スコア:2, 参考になる)
依存するのですが,terminal-emulator は kterm と同様に
ptyを作るし、依存しないはずです。
terminal-emulator で (tty;stty raw -echo;cat) としておいて
別の端末から 漢字混じりのテキストを対応するttyに
リダイレクトして送ると エミュレータ側にテキストが出ます。
そして \bを送ると、確かに一文字ずつ消えます。
手元の GNU Emacs 20.7.2(X版)で確認しました。
Re:BiDi (スコア:1)
ところで、\b ってカーソルを1カラム (1文字?) 左へと移動させるだけで、文字を消すのではないと思いますが、なぜ消えるのでしょうか?
Re:BiDi (スコア:1)
だから,カーソルがどこまで動いたのかを知るためには,文字を上書きしてみせる必要があるのですよ。
たとえば,
とかやってみて (ここで ^H は Backspace 文字を示す。入力時には Control-V Control-H と打ち込む),出力が
となるか,あるいは
となるかで,^H 一個で「一カラム」ぶん動いたのか,「一文字」ぶん動いたのか調べるわけです。ちなみに,手元の emacs では後者の動作を示しました。(中間に空白は入りませんでした)
しかしまあ,Backspace の動作の話題になると,毎回,
あたりの話がすべてごっちゃになって出てくるのは,何とも言えませんなあ。
Re:BiDi (スコア:1)
全角文字は 1文字で 2セル分なので、バックスペースで
1文字消した後 1セルしかカーソルが戻らないと半文字のところで
カーソルが止まってしまい、動作がおかしくなるという話です。
エディタ等のプログラマにしか関係ない話と言えばそれまでですが...
Re:BiDi (スコア:3, 興味深い)
ユーザインターフェース的には、文字単位の処理になっていることが必要です。というのは、Shift_JIS や EUC-JP では全角文字についてもバイト数とカラム数が一致していたので、Backspace キーを 2 回押すことでなんとかごまかしが効きましたが、UTF-8 ではそれは一致しないですし (かなやハングルや日常で使う漢字のほとんどは 2 カラム 3 バイト、ロシア文字やギリシャ文字やその他多くの文字は 1 カラム 2 バイト)、結合文字 (0 カラム) なんてのもあります。
まさしくプログラマに関係する話です。エンドユーザにはあまり関係しません。
ところで、カラムとセルってどう違うのですか?
Re:BiDi (スコア:1)
> EUC-JP では全角文字についてもバイト数とカラム数が一致していた
あの忌まわしき(いわゆる)半角カナは2バイトですよん。
#SS2 + JIS 0201 右半面(MSB on)とでも言うか。
Re:BiDi (スコア:1)
まあ、ふつうは ASCII + JIS X 0208 しか使わないということで。
Re:BiDi (スコア:1)
厳密には SS2 なり SS3 なりは CR やら LF やらと同じ制御シーケンスの一種と (ISO-2022 的には) 考えるべきなんじゃないですかね? もちろん、JIS X 0201 カナや JIS X 0212 補助漢字は 2 / 3 バイトと数える人が殆どでしょうし、実際そのように考えた方が便利だからこそ eucJP が使われるわけですが。
ところで、こういう用途って UTF-8 (というよりも ISO-10646 そのもの) はあんまり向いてないんじゃないですかね? 下手にきちんと扱い得る潜在能力があるだけに、却って泥沼化しそうな気がするんですけど。
Re:BiDi (スコア:1)
その通りかもしれませんが、いまは、Backspace キーを押したときにシェルが内部バッファから何バイト削除しないといけないかという話ですので、それが正しく実現できさえすれば、どちらの考えに立っても構いません。
なにが「下手」なのか、「泥沼化」とは具体的にどういうことかが分からないのですが、EUC-JP や Shift_JIS においては偶然バイト数とカラム数が (JIS X 0208 について) 一致するという幸運に恵まれてきたわけですが、そういう幸運に頼ることのできない言語があり (タイ語など; 0 カラムの文字がありますが、それらを 0 バイトにすることはできません)、どうせ「きちんと扱」う必要が出てきます。
Re:BiDi (スコア:0)
>Backspace キーを押したときにシェルが内部バッファから何バイト削除しないといけないかという話ですので、
UIに関しては「1文字削除」で問題ないでしょう。
現在の2バイトの日本語文字も、ちゃんと対応してない環境では2回BackSpaceを押さないといけないことがありますが、
そのような動作を本来望んでいるユーザーはいないでしょう。
まして「UTF-8でもBackSpaceは1バイト削除」なんて考えられません。
ただ、「Unicodeの1文字」が「当該スクリプトの削除単位として望ましい1文字」であるかどうかは別ですが。
ともかく、単純なバイト数より上のレイヤ
Re:BiDi (スコア:2, 興味深い)
なるほど。そうですね。
が、これは Unicode のせいではありません。現実に使われている文字が (全角はさておき) BiDi であったり結合文字であったりするので、 Unicode を使おうと、ISO-2022 や TRON コードなど別の文字コードを使おうと、 文字コードの側でそれをなかったことにすることはできません。
まあ、全部いっぺんにつめこむ「だけ」なら、できると思います。 問題は、各々の言語圏で従来まで使われてきた慣例どうしの擦り合わせでしょう。 誰がどこまで妥協すべきか。
Re:BiDi (スコア:0)
>ぼくが知る限りありとあらゆる日本語ターミナルが「カラム単位」の動作をしますが、それは「文字単位」であるべきだ、というのが彼の論旨です。