>>518
> そもそもコード変換できないときの処理として
> GNU iconv は-1を返すけど
> citrus iconv は 変換できなかった文字数を返す
違うようです。GNU libiconvではマップできない文字(入力エンコードとして不正な
シーケンス)を発見した際に-1を返すのですが、Citrus iconvでは計算アルゴリズムな
どで無理矢理マップした上で非可逆変換した文字数として返しているのでしょう。この
動きはMacのiconv相当APIであるTECと似た動作です。Macの場合はSnifferという入力
シーケンスのエンコードを検証するモジュールがあるので、それを用いてそのような無
理矢理な変換を検出することができます。
# ただしiso-2022-jpについてはこのSnifferが無茶苦茶遅いという問題がありますが。

Vimの抱えている問題点の1つに、エンコードの判定をiconvに頼っていることがありま
す。GNU libiconvの場合はそれでうまく行っていますが、Citrus iconvではそうは行か
ないということでしょう。正確にはPOSIX iconvの定義ではエンコード判定に使えるか
は保証できない、というべきです。これを材料にfencs=guessみたいな仕組みを提案す
ることはできるかもしれません。

しかしCitrusにもまったく問題が無いとは言い切れません。恐らくiso-2022-jp→
euc-jpへの変換などは計算アルゴリズムでガッツリ変換するように実装されているので
はないでしょうか?。だとすると入力エンコードとして不正なシーケンスのチェックは
一切行なっていないことになり、これはCitrusをvim-devでの議論の材料にした際に弱
点になる可能性があります。

Citrusがそのあたり正確にはどうなってるかを調べて、見るべきソースの入手場所、
ファイル名、行数等を教えて貰えないでしょうか?。それがわかればvim-devへ私がメー
ルを投げることができるようになり、もしかしたらCitrusにとってもVimにとっても幸
せなソリューションが生まれるかもしれません。もしも単にVimで漢字コード変換を使
いたいだけなら、Citrusは忘れてGNU libiconvを導入したほうが手っ取り早く幸せにな
れます。
# 余談ですがVimのソースなんて綺麗な方です。