[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[FDclone-users:00393] Re: 日本語文字コード(UTF8) 環境での動作について
- Subject: [FDclone-users:00393] Re: 日本語文字コード(UTF8) 環境での動作について
- From: Takashi SHIRAI <shirai@unixusers.net>
- Date: Mon, 09 May 2005 22:22:58 +0900
しらいです。
In Message-Id <20050509134249.25680806.20633@nifty.ne.jp>
=?ISO-2022-JP?B?GyRCSXBEZyEhMGw7MBsoQg==?= <HCD02054@nifty.ne.jp>さんwrites:
> > performance 低下が致命的になるような環境ではそういう選択も
> >ないではないんですけどね。_NODOSDRIVE と _NOKANJIFCONV を指
> >定するだけでも相当高速化すると思います。
>
> ここらへん、各項目の解説はドキュメント install や TECHKNOW でも触れてらっし
> ゃいますね。
> ただ、どちらかと言うとそちらは個々の機能の解説って意味合いが強いように思うん
> で、まさに具体的にどの場面に反映されるのか?ってイメージが分かり辛いように思い
> ます。
うん、この部分は積極的にアピールする気はないので余り判り易
い説明にはなっていないと思います。「やろうと思えば実現可能」
くらいにしか捉えてませんので。
ですから、もしどうしても希望があるならばここを読んで下さい
という程度の document であって、普通の人は as is で使って下
さいというのが本音のところ。
現実問題としては、_NO... な option の有効性をを全て継続的
に維持させるのは大変なんですよ。組合せによっては compile す
ら通らないものもあるでしょうし。
> また、 FD-Clone のコンパイルオプションって、 configure で指定するのでは無く
> 、
> 直接ソースに手を加える形になりますよね。
> 正直、ソース触るってのには少なからず抵抗が・・・。いや、理屈の上では、大した
> 問題じゃないとは分かってはいるんですが。
今でこそ configure & make という作法は当たり前になって来ま
したけど、FDclone を作り始めた頃にはそう一般的でもなく、make
一発の方がよっぽど親切だったんですよ。
make 一発を実現させるために、敢えて compile 時の選択肢は無
くしてあります。選択肢を設けることで、そういう選択の必要な一
部の人のために、一般的な利用者の手間が増えてしまいますから。
既に形式的な理念と化してしまってるかも知れませんけど、飽く
までも初心者向けのツールなんですよ。
尤も、1.03 仕様で compile するだけなら「make VERSION=1」程
度の記述で実現可能なので、興味があればお試しあれ。
> こういった部分も少なからず敷居の高さに繋がってくのかもしれません。
一段目が低い分続く二段目が高いということはあるかも知れませ
ん。でも大概は一段目でこと足りてしまうんですよ。
> 確かに、いくつかの制限・・・特に、シェルとしての動作が行われる際に、不便な部
> 分もありますが、単にランチャ動作をさせる分には、いちいちパラメータマクロで引数
> を囲ってやったりする必要も無くなり、これはこれでそれなりに便利でした。
じゃあこの仕様で release しましょうか。明日辺りにでも。
> 変数で指定可能になれば、カスタマイザからの設定も出来るようになるんだと思いま
> すんで、そうなるとさらに使い勝手も良くなるかな?、と期待してます。
こっちは仕様変更になっちゃうので、revision でなく version
を上げる必要があります。pty の実装と一緒に近日中に公開します。
pty の有効性向上のために windows 最大数も増やす予定です。
> #まぁ、 Qtopia で扱ってる UTF-8 なファイルシステムがデファクトに成り得れば、
> #話も変わってくるんでしょうけど・・・なるんかな(^^;)。
個人的にはそういう方向には行って欲しくないんですよね。I18N
つっても何やっていいやら判らんので取り敢えず Unicode で逃げ
とけって安易なアプローチが非漢字圏の開発者には多いので。
CJK に日常的に接している人間から見ると Unicode というのは
飽くまでも妥協打算の産物であって、決して最適解ではないのです
が、こういうのは文化的背景がないと実感出来ないんでしょうね。
Unicode の汚い実装部分って us-ascii や Latin-1 だけ使って
る分には目に入らないしねー。
しらい たかし