次に、Unicode の各々の文字のどれを全角、どれを半角にするか、という問題ですが、Unicode Standard Annex #11 East Asian Width [unicode.org] という文書があります。それは、すべての Unicode 文字を、「半角｣｢全角」｢文脈依存」に分けます (ほんとはもっとたくさんに分けるのですが)。で、U+00A3 は「半角｣に分類されています。
しかしそれはベンダーの思惑。こっちとしては、どうしても統一された変換表がほしい。というわけで、Unicode Consortium にこの文書 (Comments on the release of Unicode 3.1.1 の部分) を示して問い合わせたところ、11月の Unicode 技術委員会で議題にするとの返事をもらいました。まあ、問題が存在するという現状を公式に認識してくれるかどうかさえ、あまり期待できないとは思うのですが、どんな返事が返ってくるか、楽しみではあります。
ちなみに、EUC-JP ロケールにおいて、いわゆる半角カナ、
つまり、JIS X 0201 カナも使えます。
うちの Debian GNU/Linux Sid では、JIS X 0212 文字はだめでした。
ただしこれはシステムのほうのサポートがないからで、vim
そのものとしては機能はあるはずだと思っています。
EUC を自力で実装したソフトウェアの多く (emacs や kterm
を除く大部分) は、JIS X 0201 カナや JIS X 0212
はどうせ使わないからといって省略されているのが実状ですが
(いや、実際ほとんど使わないので実状としてさほど間違ってはいないと思いますが)、
vim 6.0 は Unicode を内部コードとして使っているので、
JIS X 0208 をサポートするのも JIS X 0212 をサポートするのも同じ手間で済んでしまうのです。
Microsoft のコード変換も，もともとは Windows 3.x の頃に Unicode Consortium で公開されていた変換表をそのまま使っただけのものですし，その後 JIS X 0221-1994 が出ると Unicode Consortium は自分の公開していた変換表を何のコメントもなくさっさと差し替えてしまいました．
(ほとんど JIS に合わせておいて，なぜか「―」の所だけ変換ルールを変えるのが気持ち悪い．)
実際，コード変換表は "The Unicode Standard" の一部ではないというのが，今も昔も，Unicode Cosortium の公式なスタンスだと思います．公開している変換表は，あくまでも「参考」ということです．(でもなければ，上記のようなことはできないはず．)
厳密に言うと、そのとおりです。ただ、困るバグとたいして困らないバグがあります。JIS X 0212 がサポートされていないといのはバグだって言ってあっちこっちの開発者を説得してまわったり、いろんなソフトウェアのパッチを書きまくったりするだけのモチベーションはない、というだけのこと。仕事でやってるんじゃないんだから。
実際、JIS X 0212 まわりはよく知らないけど、JIS X 0213 とのからみでどうなってくるかわからないです。技術的な興味としては、JIS X 0213 が JIS X 0208 に対して包摂規準が変更になっている文字が多数あるというところが興味深そうだが、ぼく自身はそこまで細かいことを必要としないので、純粋な技術的興味にとどまっています。第一、ぼく自身、JIS X 0212 や JIS X 0213 の文字に対する需要を今のところは持っていないし。
このあたりの技術の動向は、どうなっているのでしょうか。JIS X 0212 と JIS X 0213 (の第3・第4水準) は排他的な関係にありますが、JIS X 0213 が普及して JIS X 0212 は死んでしまうのでしょうか。それとも、JIS X 0213 は普及せずに現状のまま (JIS X 0212 が細々と生きている) で終わってしまうのでしょうか。あるいは、JIS X 0213 は Unicode Consortium に「この文字を追加しろ」と要求する際の口実としての役割を終えたら舞台から消えるのでしょうか。
このあたりの技術の動向は、どうなっているのでしょうか。JIS X 0212 と JIS X 0213 (の第3・第4水準) は排他的な関係にありますが、JIS X 0213 が普及して JIS X 0212 は死んでしまうのでしょうか。それとも、JIS X 0213 は普及せずに現状のまま (JIS X 0212 が細々と生きている) で終わってしまうのでしょうか。あるいは、JIS X 0213 は Unicode Consortium に「この文字を追加しろ」と要求する際の口実としての役割を終えたら舞台から消えるのでしょうか。
明日出荷されるMac OS X 10.1では、JIS X 0213サポートによる11,000文字対応を謳ってますので、そんなに簡単に消えられたら困るかも。Unicodeに入ってしまえば、消えてもいいのかも知れませんが。
○正規化の種別は次の三種類
a. 強制的に全部正規化
b. 正規化を設定ファイルで指定
※これでたとえばポンドを正規化する/しないとか
半角かなや全角英数字の正規化ルールが選べる
c. 全く正規化しない
○正規化の種別は個別のエンコーディングで指定可能
(指定しない場合はデフォルト)
○エディタのデフォルトは a. の強制正規化。
Re:ロケール自動認識 (スコア:4, 参考になる)
えっと、きちんと説明しましょう。EUC-JP には、ポンド記号はひとつしかありません。JIS X 0208 に含まれているもので、通常は全角文字の扱いになります。
一方、Unicode には、通常の「ポンド記号」U+00A3 £ のほかに、｢全角ポンド記号」U+FFE1 ￡ があります。EUC-JP のポンド記号「￡」をどちらに割り振るか、には、ふたとおりの考えができます。
ぼくがまとめたもの [debian.or.jp]を見てもらえるとわかるように、マイクロソフトは前者、ほかは後者の考えをとっているようです (実際には、変換テーブルの混乱が見られるのは Shift-JIS 系のコードですが、Shift-JIS と EUC-JP の JIS X 0208 部分は計算式で変換するものなので、EUC-JP もその混乱の影響を受けます)。ただし、これらの変換表は Unicode Consortium によって obsolete とされてしまいました。ちなみに、Unicode Consortium 公式と思われるこのコメント [unicode.org]は、前者の考え方に立っているようです。
次に、Unicode の各々の文字のどれを全角、どれを半角にするか、という問題ですが、Unicode Standard Annex #11 East Asian Width [unicode.org] という文書があります。それは、すべての Unicode 文字を、「半角｣｢全角」｢文脈依存」に分けます (ほんとはもっとたくさんに分けるのですが)。で、U+00A3 は「半角｣に分類されています。
｢文脈依存」に指定されている文字には、たとえば記号の多くやロシア文字があります。EUC-JP ではロシア文字や記号の多くは全角で表示されますから。
ところが、ポンド記号は、対応する全角ポンド記号が Unicode に定義されているために、半角に指定されています。これが問題のもとです。これを解決するには、
の3とおりの解決法があります。いずれにしても、全世界で統一した解決法をとるべきです。
ところで (忘れてた)、現バージョンの XTerm は、｢ポンド半角問題」のような複雑な問題だけではなく、もっと単純な問題も抱えています。それは、｢文脈依存」に指定されている文字を必ず半角に割り振っている、ということです。Robert Brady さんが作ってぼくがちょっとだけ手直しした xterm-152-27 [debian.or.jp] では、ロケール自動認識に加え、文字幅モードも複数用意するなど、いちおう使える (ただしポンド半角問題は Unicode の定義と変換テーブルの問題なので、XTerm 単体では解決しない) ところまできていました。しかし、XFree86 に巣食う、UTF-8 以外は使いにくくなければならないという信念に基づいて行動しているとしか思えない人々のせいで、それは棚上げとなっています。
というわけで、XTerm では、ポンド記号以外にも、非常に多数の記号において、全角で表示したいものが半角になってしまうという問題があるのでした。
Re:ロケール自動認識 (スコア:3, すばらしい洞察)
規格としては、変換表は規格外ということだろうと思いますが、実際にはみんなで合わせた方がいいに決まってます。まあ、｢世の中全部を一社の製品で統一したら幸せになれるよ」という意見の MS 以外は、それに賛同してくれると思います。
ところが、実情として、日本語に関する変換表の実装状況の混乱ぶりは、目に余るものがあります。過去の時点のことをいろいろと指摘することもできるでしょうが、いまや、この混乱ぶりは、自社製品の首尾一貫性を守りたいベンダー同士の激しい対立のために、ほとんど絶望的な状況にあるらしいです。
しかしそれはベンダーの思惑。こっちとしては、どうしても統一された変換表がほしい。というわけで、Unicode Consortium にこの文書 (Comments on the release of Unicode 3.1.1 の部分) を示して問い合わせたところ、11月の Unicode 技術委員会で議題にするとの返事をもらいました。まあ、問題が存在するという現状を公式に認識してくれるかどうかさえ、あまり期待できないとは思うのですが、どんな返事が返ってくるか、楽しみではあります。
というわけで、みなさん、「この問題を注目している人はたくさんいるのだ」ということを示すためにも、info＠unicode.org とか宛てに問い合わせをしてください。よろしくおねがいします。みなさん、「自分は英語が下手だし」とか「誰かがしているだろうから」と言わないでください。ぼくも最初はそう思っていたんです。こんな重大な問題は、ぼくが指摘するまでもなく有識者がすでに Unicode Consortium に問い合わせまくっていて、その結果が現状なのだと思っていたのです。それが、驚くべきことに、メールを出してみたらそれに対する動きがあったのです (このコメントとかのことを言っています)。ということは、Unicode 問題の有識者たちは日本国内で日本語で日本人相手に、Unicode Consortium には見えないところで影でこそこそとアジテーションしていただけだ、ということを意味するのではないかと思っています。
繰り返しますが、みなさん、Unicode に対して不満があれば、ここに書くだけではなくて (もちろん、ここに書くこと自体は歓迎だけど)、Unicode Consortium に直接言ってください。
ロケール自動認識 (スコア:2, 参考になる)
最大の特徴 (とぼくが考えるもの) は、ロケール自動認識です。 つまり、LANG=ja_JP.eucJP (Linux の場合) では、デフォルトの動作が EUC-JP を使った日本語になります。 というか、これ基本でしょ。 ぼくは、ロケールを認識しないソフトはすべてバグだと考えてるから、 ようやく vim もバグがとれた、という考えです。
ちなみに、EUC-JP ロケールにおいて、いわゆる半角カナ、 つまり、JIS X 0201 カナも使えます。 うちの Debian GNU/Linux Sid では、JIS X 0212 文字はだめでした。 ただしこれはシステムのほうのサポートがないからで、vim そのものとしては機能はあるはずだと思っています。 EUC を自力で実装したソフトウェアの多く (emacs や kterm を除く大部分) は、JIS X 0201 カナや JIS X 0212 はどうせ使わないからといって省略されているのが実状ですが (いや、実際ほとんど使わないので実状としてさほど間違ってはいないと思いますが)、 vim 6.0 は Unicode を内部コードとして使っているので、 JIS X 0208 をサポートするのも JIS X 0212 をサポートするのも同じ手間で済んでしまうのです。
ところで、Unicode ベースということで心配される、 JIS X 0208 のポンド記号などが半角になってしまう問題ですが、 これは、問題なく全角で表示されています。 といっても、半角になっても規格上は間違ってないのですが (そして、日本人の中でも意見が分かれるところだと思いますが)、 これまでの運用の実績を考えると、少なくとも ja_JP.eucJP ロケールにおいては全角にするのが妥当でしょう。 ちなみに、gtk 版でもきちんと全角になります。 どうやって実装してるんでしょう... と思いきや、gtk 版は XFontSet を使っているようです。 ちなみに、ja_JP.UTF-8 ロケールではどうか、ですが、 XFontSet を使っている関係上、gtk 版はうまく動いてくれません。 ちなみに、xterm -u8 上では、xterm そのものがポンド記号を半角で 表示してしまうので、vim がいくらあがいても無理です。
JIS X 0212 は使えます。 (スコア:2, 参考になる)
Debian な人は (スコア:2, 参考になる)
vim パッケージのメンテナである Wichart Akkerman さんがテストパッケージを作っていますので試してみましょう。
って、よく読むと、もうじき Debian アーカイブにも現れるって書いてあるぞ。Woody には入れるつもりですか、って変な質問してしまったなあ (反省) (現時点ではまだウェブ上のメーリングリストアーカイブには現れてないけど)。
じゃあ Emacs の宣伝をしてよ (スコア:2, 興味深い)
「そんなにいいもの？」っておっしゃいますが、ロケール自動認識はいいですよ。Rxvt もそうなりました。いま、同じ手法を使って Eterm もロケール自動認識にしたいなあと妄想中。Rxvt の該当部分のソースを流用するのもいいけど、ライセンス確認しなくちゃ。
GNU Emacs も 21 からロケール自動認識になるとか言う噂があります。というか、emacs-hogehoge＠gnu.org とかにメールして確認済み。ただ、emacs -nw 時にターミナルとのやりとりに使うエンコーディングはロケール自動認識になるそうですが、ファイルのエンコーディングについては、emacs 自身が持つ自動認識機能とのからみで、どうなるのか分かりませんが。
ついでに、X Window 上で走らせるときも、フォントセットがデフォルトになって日本語とかも設定なしで表示できるようになるらしいです。(というか、現状だと日本語はおろかロシア語もギリシャ語もポーランド語も表示できない。つまり、ISO-8859-1 しか表示されない。ダメすぎ)。
で、Emacs 派な方で、このへんとかをもうちょっと詳しく知っている方はいらっしゃいますか? 「GNU Emacs 21 はこんなにすごくなるんだから Vim なんか使うのやめなさい」とか :-)
少々ならいがみあうのも構わないとは思いますが、お互い高めあってほしいものです。
Re:じゃあ Emacs の宣伝をしてよ (スコア:2)
＞少々ならいがみあうのも構わないとは思いますが、お互い高めあってほしいものです。
同感ですね。私は Emacs にいいところがあるから好きというよりも、Emacs キーバインドが体に染み付いているので、Emacs キーバインドで vim が使えるなら多分使うでしょうね(笑)
すらど宴会SNS開放中 [e-meet.jp]
VIMを EMACS 風 にするVIMスクリプト (スコア:2, 参考になる)
そういうものも活用してみてはいかがでしょう。
Re:ロケール自動認識 (スコア:2, 参考になる)
というか，Unicode Consortium 自体， 既存のコードセットとの間の変換についてはあまり考えていなかったのではないかと思います．Round-trip conversion ができるように，文字だけは収録するけれど，変換表は勝手に自分で作れということで．
Microsoft のコード変換も，もともとは Windows 3.x の頃に Unicode Consortium で公開されていた変換表をそのまま使っただけのものですし，その後 JIS X 0221-1994 が出ると Unicode Consortium は自分の公開していた変換表を何のコメントもなくさっさと差し替えてしまいました． (ほとんど JIS に合わせておいて，なぜか「―」の所だけ変換ルールを変えるのが気持ち悪い．)
実際，コード変換表は "The Unicode Standard" の一部ではないというのが，今も昔も，Unicode Cosortium の公式なスタンスだと思います．公開している変換表は，あくまでも「参考」ということです．(でもなければ，上記のようなことはできないはず．)
ISO 8859 系の変換表でも，たとえば Kosta Kostis の ISO/IEC 8859 Character Encoding Information で指摘されているような問題があります．
Re:どうせなら (スコア:2)
viを立ち上げようとして、edモードに入ってしまった、ということでしょうか？ (^_^;;;;
Re:ロケール自動認識 (スコア:1)
厳密に言うと、そのとおりです。ただ、困るバグとたいして困らないバグがあります。JIS X 0212 がサポートされていないといのはバグだって言ってあっちこっちの開発者を説得してまわったり、いろんなソフトウェアのパッチを書きまくったりするだけのモチベーションはない、というだけのこと。仕事でやってるんじゃないんだから。
<offtopic>
つまり、バグのことを「これはバグだ」と指摘するための発言行動をあえて実行する、ということは、単なる客観的な没価値的な事実の指摘ではなく、その事実に対して意味付けを行う行動なのです。(これはぼくの発言が、というだけではなく、すべての人のありとあらゆる意味のある発言がそうなっているはずです。たとえば、ぼくがここでいきなり今日の朝食について議論を始めたらオフトピックというか意図がわからなくて「はぁ？」って思うでしょう? それはつまりあなたが、発言には意図が必要だと思っているから、意図がわからないと「はぁ？」となるわけです)
</offtopic>
実際、JIS X 0212 まわりはよく知らないけど、JIS X 0213 とのからみでどうなってくるかわからないです。技術的な興味としては、JIS X 0213 が JIS X 0208 に対して包摂規準が変更になっている文字が多数あるというところが興味深そうだが、ぼく自身はそこまで細かいことを必要としないので、純粋な技術的興味にとどまっています。第一、ぼく自身、JIS X 0212 や JIS X 0213 の文字に対する需要を今のところは持っていないし。
このあたりの技術の動向は、どうなっているのでしょうか。JIS X 0212 と JIS X 0213 (の第3・第4水準) は排他的な関係にありますが、JIS X 0213 が普及して JIS X 0212 は死んでしまうのでしょうか。それとも、JIS X 0213 は普及せずに現状のまま (JIS X 0212 が細々と生きている) で終わってしまうのでしょうか。あるいは、JIS X 0213 は Unicode Consortium に「この文字を追加しろ」と要求する際の口実としての役割を終えたら舞台から消えるのでしょうか。
Re:ロケール自動認識 (スコア:1)
表示系，入力系なども考慮して、ある文字コード体系をきちんと使って運用できるかを分けて考えないと
どこで何を実装して欲しいのかがはっきりしないような。
UnicodeにしてもJIS X 0212にしても、サポートされたんなら追加された文字を便利に使えるように
入力系も良くなっているとイイなぁ、とか思いますし。
本当かい♪本当かい♪
Re:ロケール自動認識 (スコア:1)
明日出荷されるMac OS X 10.1では、JIS X 0213サポートによる11,000文字対応を謳ってますので、そんなに簡単に消えられたら困るかも。Unicodeに入ってしまえば、消えてもいいのかも知れませんが。
そんないいいもの？ (スコア:1, フレームのもと)
ま、冗談で言ってるんだろうけど emacs なしには生きられない私にとって非常に不愉快極まりない一文だ、どうせならいいところをアピールして「んー、ちょっと使ってみようかな」と思わせる文章で締めくくった方がいいね。
vim? なにそれ？
すらど宴会SNS開放中 [e-meet.jp]
Re:そんないいいもの？ (スコア:1)
(中略)
> vim? なにそれ？
こういうのをdouble standardというのでは?
まあでも、私も件の一文にはあまり感心しなかったね。挑発的な台詞を吐いて、その場を盛り上げようという意図があるのかもしれないけど、だとしても稚拙にすぎると思う。
Re:そんないいいもの？ (スコア:1)
まぁ、それもあるけど「本当に知らない」ってのもありますね。余計な一言である事には違い無いですが。
ツールの選択肢が増えるのはありがたいのでどんなもんかチェックしてる最中だったりします。
すらど宴会SNS開放中 [e-meet.jp]
Vim and Migemo (スコア:1)
村岡さんという人が Migemo をVimに組み込むためにCのライブラリとして書き直しています。バイナリ及びソースが村岡さんのpageから入手できます。
Re:ロケール自動認識 (スコア:1)
実際にはcharsetの自動設定なんですよね。
「ロケール」というくらいなんだから、
メッセージやコマンドも日本語にしてくれないと。
:置換/ロケール/charset/
とか
# もちろん冗談ですよ^^;
ぜんぶ日本語 (スコア:1)
｢日本語変換を開始する」というコマンドが日本語なんですけど、どうやって入力したらいいですか? :-p
正確には、LC_CTYPE ロケールの自動認識ですね。
Re:ぜんぶ日本語 (スコア:1)
Re:じゃあ Emacs の宣伝をしてよ (スコア:1, 余計なもの)
すらど宴会SNS開放中 [e-meet.jp]
Re:ロケール自動認識 (スコア:1, 興味深い)
# XTerm の実装は全然知りませんでしたが(^^;
私は半角全角を区別する考え方はナンセンスだと思って
ます。えーと、変換時の考え方としては原則「後者」
ですね。あと、まあ、「ポンド記号は半角で」ってこと
になりますか。正確には「新規文書中では互換文字は
使わない」なんですけど。
なので、Unicode にしたのなら、u+00A3 にするのが
当然だろうとおもって、前の記事のような内容になった
のですが･･････ってわかった。
新規文書の時でなくて、従来の文書を開いたとき
ってことっすね? それならわかります。
内部的に Unicode にするときにも「互換文字」に
わりふるように維持するってわけだ。ふむ。
強制的なコードの正規化(互換文字排除)はスイッチ
できるようになってると良いかも。ただ、その正規化
するかしないかが、ロケールによって勝手に決まると
むしろそれは混乱の元だと思います。
(新規ファイルのエンコーディング自体はロケール
で決定してよいと思う)
ということで、
○正規化の種別は次の三種類
a. 強制的に全部正規化
b. 正規化を設定ファイルで指定
※これでたとえばポンドを正規化する/しないとか
半角かなや全角英数字の正規化ルールが選べる
c. 全く正規化しない
○正規化の種別は個別のエンコーディングで指定可能
(指定しない場合はデフォルト)
○エディタのデフォルトは a. の強制正規化。
このあたりが妥当ではないですかね。
コードの目的としては、互換文字は使わないに
こしたことはないのですから、デフォルトでは
排除方向でよいと思います。で、それが困る人は
その機能をＯＦＦにすればよろしいってことで。
しかしXTerm はこまったちゃんでのう。表示する場合には
互換維持の原則で、互換文字はそのまま表示するべき
だと思います。はい。
Re:じゃあ Emacs の宣伝をしてよ (スコア:1)
私は vi 派ですが emacs で vip や viper は使いません。まあ、これは せいぜい canna-touroku と trr にしか使ってないからでしょうね。
で、本気で日本語を打つときは vim [56].x でなく jvim 3.0 を使っています。
これは Onew のキーバインドから離れられないから。 :-)
# Vim 6.0 の日本語処理が jvim に劣っている
# という趣旨ではありません。念の為
バイナリエディタ (スコア:1)
あるいは とかもありでしょう。
Re:XF86Config壊れたら (スコア:1)
wild wild computing
Re:いいからKDE使っとけ (スコア:1)
GVim を一度お試しあらんことを。
# Windows でも X でも使えるし。
Re:キーアサイン (スコア:1)
* コード書く
* メール書く
* 文書書く
* etc.etc...テキストを扱うかぎり、同じキーアサイン、
同じマクロ、同じインデントルールを使いたいし、
いちいち全てのアプリを同じ操作感覚に再カスタ
マイズするのは面倒だし、非生産的ってのがあってEmacs使ってます。
まぁ。当時、自宅で Emacs 使いたくて Linux 入れたってくらいなので。
wild wild computing
Re:XF86Config壊れたら (スコア:1)
- XF86Setup
- xhost +
- (番外編) cp /backup-fd/XF86Config /etc/X11/
...という事で、ないわけでもないのではないかと推察します。どうでもいいことだけど (スコア:1)
Re:いいからKDE使っとけ (スコア:1)
慣れればかなりスムーズに操作できるようになるだろうなぁーと思いつつ未だにエスケープキーと漢字キーを連続で押してしまっている私(^_^;)
Re:いいからKDE使っとけ (スコア:1)
KVimという手もあるけど、バージョン古いしなぁ。
開発、まだやってるのかな。
-- Che Che - Bye Bye
Re:ロケール自動認識 (スコア:1)
現在ある EUC の文書中のポンド記号を Unicode 変換時に互換文字に変換するとしたら、新しく Unicode で入力する文書にも、互換文字のポンド記号を入力したくなると思います。「その部分はまったく同一」な文書を作る必要があるときとか。
現在のシフト JIS や EUC においても、半角カナや全角英数の使用はあまりおすすめしない、ということになっていると思いますが、Unicode における互換文字の不使用もその程度の弱い「おすすめ」しかできないと思います。
どうしてもきれいな Unicode に移行したければ、移行過程のどこかで断絶を作る必要があります。が、それを要求するのはほぼ不可能でしょう。世界中がひとつの方式に従わないと、規格の意味がないですが、そんなことは不可能です。
互換文字を排除するかどうかについては、ぼく自身はどちらでもいいという意見です。「どちらか」という問題よりかは、｢世界中がどちらかで統一される」という問題のほうがよっぽど重要なことです。「長いものに巻かれろ」に近い。そして、Unicode Consortium は｢互換文字排除」の原則を緩めつつあるような印象をぼくは持っています。
どうせなら (スコア:1)
何だかインパクトが弱いなぁ... どうせなら
ぐらいだったら大笑いできたのに(某OSではマジ話になってしまったが)。
echo, cat, ed, vi, emacs, (perl || ruby) (スコア:1)
ぐらいを場合に応じて使い分ける方がUnix的にはスマートですね.
最近はgeditあたりも, 初心者に教えるには機能が少なくていいかなどと思っています.
単機能万歳!!
Re:ロケール自動認識 (スコア:1)
それはその通りだと思います． まあ，新しいデータ形式を作ったときに，「ここでは UTF-8 以外は使うな」とか宣言してしまう以外にはうまい移行方式はないかもしれませんが．
なんせ，「ポンド記号の全角・半角問題」以外にも， 「0x5C はバックスラッシュ (REVERSE SOLIDUS) か円記号 (YEN SIGN) か問題」とか「0x7E はチルダ (TILDE) か上線 (OVERLINE) か問題」とか，いろいろありますもので．昔は YEN SIGN 問題で盛り上がったものですが，最近は TILDE 問題の方が騒がれるようなのがなんとも．
私は，YEN SIGN 問題と TILDE 問題がないというだけでも UTF-8 に移行したい気分ですけど． (もちろん，「ＭＳ 明朝」とかいったふざけたフォントは使わないという前提でね．)
Re:どうせなら (スコア:1)
# 一部の sh script が困るんじゃなかろうか。
Re:どうせなら (スコア:1)
マジ話の方は「なにそれ?」の意味がちょっと違うので強引ではありましたが...
ある日、「crontab(1)を起動したらエディタが立ち上がらない」といわれて現場にいってみました。見てみるとSolarisが走っている計算機だったのですが、動いていたのはvi(1)ではなくed(1)だったという話です。
まぁ、初めて見る人には「なにそれ?」ってことで...
Re:いいからKDE使っとけ (スコア:1)
# ウガンダは「ライセンス」じゃなくて
# 「お願い」だから関係ないという事なのかな...
Emacs って単機能ですか？ (スコア:1)
fepctrl 機能 (スコア:1)
但し、Vim の IME 制御は fepctrl とは別物 (のハズ) です。
環境変数の問題でしょう (スコア:1)
環境的にはあり得る話ではないかと。
全ての機能を使う責任は無い (スコア:1)
むしろキッチンシンクとまで言われるEmacsでも, 通常使う機能は絞った方がむしろ使いやすいって話で.
もっとも全 Emacs LISP 関数を暗記しているとでもいうなら話は全く変わりますが.
部門(オフトピック) (スコア:1)
コナミコマンドかいっ！
気づくまで５分掛かった。
Re:ロケール自動認識 (スコア:1)
EUC-JP を使っていて YEN SIGN 問題から自由でないのなら、UTF-8 を使っても YEN SIGN 問題から自由ではいられないことでしょう。
というか、EUC-JP も Shift_JIS も ISO-2022-JP も一切扱わないのなら、それでもいいですが。そういうわけには、いかないでしょう。
よく、「全角」「半角」という言葉を使うと、「全角ってなに?」「半角ってなに?」という意地悪な答えが返ってくることがありますが、でも実状として、わたしたちは全角・半角という概念に依存しているわけです。顔文字やアスキーアート、プレーンテキストで表現された図表、curses ベースのソフトウェア、などなど。こんな意地悪な質問をして楽しんでられるのは、「全角」「半角」の概念と重要性を共有している仲間内だけです。漢字文化圏じゃない人々がそれを見たらきっと、「全角・半角の概念は一部のオタクたちがこだわっているだけで、無視して構わないんだ」って思われてしまいます。
ところで、最近、Unicode にかんして CJK Han Unification についての不満を聞かなくなりましたが、どうしてなのでしょうか。不満だった人はみんな TRON とかに移行して満足してしまったのでしょうか。それともぼくが寡聞にして知らないだけ? (たぶん後者だろうけど)。
じっさい、CJK Han Unification については、統合された文字の違い (or グリフの違い) を気にするのはほんのごく一部の日本の ISO-2022 な geek たちだけだ、という主張をよく聞かされました。その意見の主は Markus Kuhn さんですが。
なにそれ? (スコア:1)
いまどきは
hjkl? なにそれ?
かもしれないとか思ったり。
Re:ロケール自動認識 (スコア:1)
そうそう，他の世界がなければいいんですけどね．
いや，もう既に外堀は埋められているのですよ． Windows を使うとか，Java を使うとか， はたまた XML を使うと言った時点で Unicode から 逃れられなくなってしまう． 今の世の中，この3つのどれからも自由でいられる人はなかなかいないでしょう．
TRON がいくらがんばったところで，外部データ表現が Unicode を基準にして決められてしまう状況ではいかんともしがたいと思います． (別に，私は TRON コードの肩を持つわけではありませんが．あれは，端的に変だ．)
それは単に Markus が知らないだけ． あいつの言うことを真に受けていては大変ですよ． まあ，字形の細かいところにこだわりすぎるのも何だとは思いますが (手書きの字形における細かな違いを明朝体の字形に反映しろと言われてもねぇ)，そういう人がこの国に多いのは事実ですから．
Re:ロケール自動認識 (スコア:1)
いや、まあ、そうなんですけど (というか、彼が XFontSet について知らないと書いたのを見て、唖然としたことがあります)、彼の影響力は絶大なものがありますし。逆に、彼の考えを改めさせることで大勢の考え方を改めさせることも可能だという (きわめて困難ですが、不可能ではないです)。
あと、予断になりますが、Unicode Consortium の公式見解を改めさせるというのも、影響力という点では大きな効果があると思います。この FAQ とか、この FAQ の U+76F4 の部分とかはぼくのつっこみの結果として追加されたものですが、それまではお寒い状況でしたから。
それから、
というか、篭城したら勝ち目はないでしょ。理想の世界について夢想して現実を嘆くよりも、現実を少しでも良くする方向へともっていかないと。ソフトウェアは動いてなんぼですから。:-)Re:ロケール自動認識 (スコア:0)
JIS X 0212を認識しないのもバグじゃないですかね。
vim6に関する質問集はココまで (スコア:0)
Re:ロケール自動認識 (スコア:0)
全体の動向次第でしょう。
技術的には、JIS X 0213 を使うときは、JIS X 0212
を使わない新しい EUC 体系(名前失念)を使うという
ことで解決するかと思います。EUC-JP213だっけ？
旧文字コードがオーバラードされて消えるのではなくて、
新規文字コードが出現するってことですね。Mule の
JIS X 0213 用の実装がそんなかんじだったと記憶
しております。
RFCのドラフトだったか、IANA に提出する資料だったか
だれかが書いたけどなんか要件みたしてなくてけられて
そのあとどうなったかってのは追跡してないので
知りません。私も知りたいので知ってる人
たれこみよろしく。
＞新EUC,新ISO-2022-JP,新SJIS