アカウント名:
パスワード:
X Window System 上での日本語 (多国語) 入力には、XIM という標準が存在します。 (Project HEKE では IIIMF はステだそうですが、IIIMF を推進している人たち [Sun だとか Li18nux だとか] にはその問題点を伝えたのでしょうか。 将来にその問題点が改善される見込みは?) しかし、コンソール上で日本語を使いたいと思ったとき、 各々のソフトウェアが Canna/Wnn といった各々のプロトコルの API をそれぞれ実装して対処している、というのが現状です。この方法だと、
えせかんな [netfort.gr.jp]という物があります. これは基本的に日本語対応ですが, VJE等をCannaサーバに見せかけることにより, XIMに対応していない(例えばkinputプロトコル専用の場合等)プログラムでも市販の日本語フロントエンドが使えます.
なぜ? readline ライブラリだと、それを用いたアプリケーションでしか日本語を入力できないですよ。世界中のすべてのコンソールアプリを readline (のようなもの) 対応に書き換えないといけなくなります。(実際に GNU readline を使おうとするとライセンス問題が発生しそうですが)。
ぼくは、コンソールそのものが変換機能 (をプラグインできるためのインターフェース) を持つのがいいと思っています。GNU screen だとか uum/canuum/skkfep とかでも「すべてのソフトウェアで日本語 (中国語、韓国語、...) を」は実現できますが、ログインした後にそれらを起動しないといけないのが不満が残るところです。ただ、どうせ別の目的で GNU screen を起動するんだ、という人の場合は、ついでに日本語変換もサポートしてくれたら嬉しいことでしょう。また日本語表示はできるけど日本語変換はできないリモート環境での利用においても、screen/uum/canuum/skkfep 的なアプローチは有効です。
というわけで、コンソールそのものを基本とし、GNU screen のようなレイヤーにも補助的に変換機能 (のプラグインへのインターフェース) を備えるといろんな場合に対応できて、いいんじゃないかと思います。
ところで、「思われ」というのはどういうニュアンスの言葉なんでしょうか。
GNU screen の場合、相手が console だったり仮想端末だったりリアル端末 だったりするので、screen 自身で完結した機能をもった方がいいだろうなと 私は思っています。なので ああいうパッチ [daionet.gr.jp] を書きました。
screen に generic な front end をしこめるような 方法を以前から妄想はしてるんですが、なかなか実現に至りません。 一応 layer という概念が screen にはあるので、がんばれば できそうだなあという見通しだけはあるんですが...
あと、あのパッチはかなり ad-hoc な実装なので、 今後は期待しない方がいいです。私も最近はほとんどつかってませんし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
コンソール上での日本語入力 (スコア:2, 興味深い)
X Window System 上での日本語 (多国語) 入力には、XIM という標準が存在します。 (Project HEKE では IIIMF はステだそうですが、IIIMF を推進している人たち [Sun だとか Li18nux だとか] にはその問題点を伝えたのでしょうか。 将来にその問題点が改善される見込みは?) しかし、コンソール上で日本語を使いたいと思ったとき、 各々のソフトウェアが Canna/Wnn といった各々のプロトコルの API をそれぞれ実装して対処している、というのが現状です。この方法だと、
一つの解法として (スコア:2, 参考になる)
えせかんな [netfort.gr.jp]という物があります. これは基本的に日本語対応ですが, VJE等をCannaサーバに見せかけることにより, XIMに対応していない(例えばkinputプロトコル専用の場合等)プログラムでも市販の日本語フロントエンドが使えます.
GIMP (Generl Input Method Protocol) (スコア:1)
GIMP という名前は置いておいて (スコア:1)
readline ライブラリのようなものの上に実装されると嬉しいと思われ。
# mishimaは本田透先生を熱烈に応援しています
多スクリプト入力はどのレイヤーがいい? (スコア:2, 参考になる)
なぜ? readline ライブラリだと、それを用いたアプリケーションでしか日本語を入力できないですよ。世界中のすべてのコンソールアプリを readline (のようなもの) 対応に書き換えないといけなくなります。(実際に GNU readline を使おうとするとライセンス問題が発生しそうですが)。
ぼくは、コンソールそのものが変換機能 (をプラグインできるためのインターフェース) を持つのがいいと思っています。GNU screen だとか uum/canuum/skkfep とかでも「すべてのソフトウェアで日本語 (中国語、韓国語、...) を」は実現できますが、ログインした後にそれらを起動しないといけないのが不満が残るところです。ただ、どうせ別の目的で GNU screen を起動するんだ、という人の場合は、ついでに日本語変換もサポートしてくれたら嬉しいことでしょう。また日本語表示はできるけど日本語変換はできないリモート環境での利用においても、screen/uum/canuum/skkfep 的なアプローチは有効です。
というわけで、コンソールそのものを基本とし、GNU screen のようなレイヤーにも補助的に変換機能 (のプラグインへのインターフェース) を備えるといろんな場合に対応できて、いいんじゃないかと思います。
ところで、「思われ」というのはどういうニュアンスの言葉なんでしょうか。
Re:多スクリプト入力はどのレイヤーがいい? (スコア:3, 興味深い)
GNU screen の場合、相手が console だったり仮想端末だったりリアル端末 だったりするので、screen 自身で完結した機能をもった方がいいだろうなと 私は思っています。なので ああいうパッチ [daionet.gr.jp] を書きました。
screen に generic な front end をしこめるような 方法を以前から妄想はしてるんですが、なかなか実現に至りません。 一応 layer という概念が screen にはあるので、がんばれば できそうだなあという見通しだけはあるんですが...
あと、あのパッチはかなり ad-hoc な実装なので、 今後は期待しない方がいいです。私も最近はほとんどつかってませんし。
knok
Re:多スクリプト入力はどのレイヤーがいい? (スコア:1)
というか今の今まで screen というコマンドの存在を忘れていた。
実際、自分の頭の中に最初あったのはまず、
「VT100 with XIM」みたいな形で端末の規格の中にそれを押し込めてしまうものだったけど、
これにはちょっと無理がある。
その後「cursesライブラリ上に実装する方がよかろ」と思ったが、
それだと範囲が広すぎるのでは？との思いから readline に至ったわけなんだけど。
> ところで、「思われ」というのはどういうニュアンスの言葉なんでしょうか。
「思われる」「思われます」ですな。
# mishimaは本田透先生を熱烈に応援しています