[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[FDclone-users:00374] Re: 日本語文字コード(UTF8) 環境での動作について
- Subject: [FDclone-users:00374] Re: 日本語文字コード(UTF8) 環境での動作について
- From: Takashi SHIRAI <shirai@unixusers.net>
- Date: Sat, 09 Apr 2005 03:10:17 +0900
しらいです。
In Message-Id <20050408102627.25680806.20648@nifty.ne.jp>
=?ISO-2022-JP?B?GyRCSXBEZyEhMGw7MBsoQg==?= <HCD02054@nifty.ne.jp>さんwrites:
> ただ、感覚的に、ついつい現在の端末の文字コードがそのままパススルーされてると
> 思いがちになっちゃうんだと思います。
その辺りニーズとしてはどうなんですかね?nkf にしろ何にしろ
標準入力に食わせることの出来ない出力は端末側で何とかしないと
いけない訳で。
そう言えば疑似端末ソフトでも端末出力の漢字コード変換って聞
いたことありませんね。無いということは要らないということなん
でしょうか。
> >疑似端末を使うなら、出力側の端末 emulation で漢字コード変換してやって、cat だ
> >ろうが less だろうがどんな出力もお望みの漢字コードで表示可能ですけど。
> ># 疑似端末機能は全然反応が無かったので暫く棚上げ。
>
> シェルとしての側面を持つ現在の FD Clone では、本来、重要な機能になる筈なんで
> すけどねぇ。
screen(1) で画面分割して並列作業してると、interface の使い
づらさに閉口してしまうので、「画面 2 つ持った pty」ってだけ
なら自分で作っちゃった方が便利かなと思って手慰みに開発に着手
してみました。
元々は MHpopd 用に pty module を作ったのがきっかけなんです
が、実際やってみると pty よりも terminal emulation の方が面
倒で往生してます。
pty の難しさというのは OS 依存性だけなので、幾つかのパター
ンでコツを掴んでしまえばそう複雑な仕組みではないんですが、vt
100 程度の端末であっても結構機能が多いので emulation は力技
になってしまいます。
# しかも OS によって「vt100」の挙動が全然違うというのは一
#体どういうことなんでしょうねー。
# 本物の vt100 で確認する術がないのが悔しいところですが、
#もしそれが出来たなら、端末 login した時の相手が例えば Free
#BSD か Linux かで key bind が全然違う筈。
# DEL と BS は挙動が逆になるし、一方での 10 key が他方では
#function key として扱われるし。じゃあ端末 emulator はどの
#「vt100」を模倣したら良いのやら。
> ただ、このへん現実問題としては、旧来のランチャとしての側面から見られることが
> まだまだ主だと思うんで、今一つ反応に結びつき難くなってるんじゃないかと。
launcher として考えても、起動したアプリが画面の半分しか使
わなかったり、その残りの半面で別のアプリを同時に起動出来たり
すると便利なんじゃないかと思ったんですけどね。
本当は左右に画面分割した方が色々と便利なんですけど、それば
まりはちと無理そう。右半分だけ画面 scroll って出来たらいいん
ですが。
> > あ、これウソでした。ちゃんと開けます。source 良く見たら対
> >応してありました。
>
> あ、そうなんですか。
> そのへんも日本語ファイル名と同じく”使えなくて当たり前”みたいな感覚あったん
> で考えたことも無かったです(^^;)。
launcher ってそもそも、そういった手入力の煩わしさを解消す
るために作られてると思うので、いちいち escape したり "" で括
ったりなんてことから user を解放する必要がある訳です。
なので、そういう illegal な文字を用いた filename に対して
も対応出来て然るべきですね。
# 実装する側は大変ですけど :-)
しらい たかし