Vim6 Part10
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@w3m
NGNGhttp://www.vim.org/
前スレ
http://pc5.2ch.net/test/read.cgi/unix/1086135625/
関連情報は>>2-7あたり。
0766名無しさん＠お腹いっぱい。
05/02/13 16:15:37日本語キーボードしか使ったことないからわからん。
0767名無しさん＠お腹いっぱい。
05/02/13 16:16:26ありがとう。そうします。
0768名無しさん＠お腹いっぱい。
05/02/13 18:18:390769名無しさん＠お腹いっぱい。
05/02/13 18:24:32意味が判りません
0770名無しさん＠お腹いっぱい。
05/02/13 18:25:41判ります
0771名無しさん＠お腹いっぱい。
05/02/13 19:12:500772名無しさん＠お腹いっぱい。
05/02/13 19:24:41なんで違う配置にしたんだろう
コロン、セミコロン、括弧とか &^'"*[] あたり、いつも打ち間違えるよ
0773名無しさん＠お腹いっぱい。
05/02/13 21:05:50Enterの隣にバックスラッシュがあったり
チルダが見つからなかったり
0774名無しさん＠お腹いっぱい。
05/02/13 21:28:260775名無しさん＠お腹いっぱい。
05/02/13 21:32:580776名無しさん＠お腹いっぱい。
05/02/13 21:43:020778名無しさん＠お腹いっぱい。
05/02/13 23:27:510779名無しさん@Vim%Chalice
05/02/13 23:31:22多用するキーなので使ってるうちに違和感など
微塵も無くなる．
vimは英語キーボードを基に考えられたキーバインド
なので(あたりまでだが…)，英語キーボードの方が
つじつまが合っている．
例えば前方検索の*と後方検索の#，英語キーボードでは
shiftを押しながらそれぞれ右手・左手の中指を延ばした
所にあるキーであるとかね．
(ここからはまったく個人的な意見だが)，そもそも(vimに関係なく)配列は
英語キーボードの方がつじつまが合ってると思う．
'をshift押しながらだと"になったり，;をshift押しながらだと:に
なったり，なんか理論整然としてると思うのは私だけ?
ただ人間工学的には日本語配列の方が優れているという記事を
読んだ覚えもあるけどね．
ま，要は各々で使いやすい方で良いという結論なわけだが…
0780名無しさん＠お腹いっぱい。
05/02/13 23:34:470781名無しさん＠お腹いっぱい。
05/02/13 23:47:020782名無しさん＠お腹いっぱい。
05/02/13 23:48:46○理路整然
0783名無しさん＠お腹いっぱい。
05/02/13 23:57:140784名無しさん＠お腹いっぱい。
05/02/14 00:02:47のをロジカルペアリングっていうんだってさ。
http://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%BC%E9%85%8D%E5%88%97
0785名無しさん＠お腹いっぱい。
05/02/14 00:06:33そんなに相性悪くないと思うが
0786名無しさん＠お腹いっぱい。
05/02/14 00:44:45なるほど、じゃあJIS配列の方が理路整然としてるね。
0787名無しさん＠お腹いっぱい。
05/02/14 00:45:40ただ、今となっては慣れただけのような気がするがな。
qwertyでUnixコマンドは打てるけど、viは使えないな。
0788名無しさん＠お腹いっぱい。
05/02/14 01:39:220789名無しさん＠お腹いっぱい。
05/02/14 09:05:19一応どんなキーボードでも 慣れれば 使えそうな気がする
0790名無しさん＠お腹いっぱい。
05/02/14 19:31:540791KoRoN@Vim%Chalice ◆8XALICEsdk
05/02/14 19:39:350792名無しさん＠お腹いっぱい。
05/02/14 20:29:560793名無しさん＠お腹いっぱい。
05/02/14 20:39:50いやいや、まてまて苦笑
0794名無しさん＠お腹いっぱい。
05/02/14 20:47:340795名無しさん＠お腹いっぱい。
05/02/14 21:06:360796名無しさん＠お腹いっぱい。
05/02/14 21:06:460797名無しさん＠お腹いっぱい。
05/02/14 21:09:070798名無しさん＠お腹いっぱい。
05/02/15 00:37:56挿入やコマンドでは貼り付けってあまりしないものなのかな
0799名無しさん＠お腹いっぱい。
05/02/15 05:32:33挿入モードで貼り付ける場面ってそんなにないような。
0800名無しさん＠お腹いっぱい。
05/02/15 09:58:280801KoRoN@Vim%Chalice ◆8XALICEsdk
05/02/15 10:16:15実行してその出力を、ということであれば :help :r! を参照してください。
0802名無しさん＠お腹いっぱい。
05/02/15 10:52:24ご回答ありがとう御座います。
ちょっと違うようです。説明がへたくそで吸いません。
たとえば、あるmp3をvimのコマンドラインからひらいて音をならすとと言うようなことです。
:e であるディレクトリを開いて該当のファイルの上で x をおすと実際に実行できるのですがこれを
コマンドラインからできないでしょうか？
0803名無しさん＠お腹いっぱい。
05/02/15 11:26:00とかいう話?
0804名無しさん＠お腹いっぱい。
05/02/15 11:27:32>:e であるディレクトリを開いて該当のファイルの上で x をおすと実際に実行できるのですがこれを
vim のファイルブラウザはスクリプトで出来てるんだから、おんなじことやってるはず。
explorer.vim 見ろ。
0805名無しさん@Vim%Chalice
05/02/15 11:27:41<S-UP>などが使用できません。これは仕方がないんでしょうか。
今はmapしているので問題ないのですが・・・
0806名無しさん＠お腹いっぱい。
05/02/15 11:35:120807KoRoN@Vim%Chalice ◆8XALICEsdk
05/02/15 11:36:10環境がUNIXで、利用するプログラムが決まっているならば803さんの方法です。
Windowsで、そのデフォルト設定に従いたいのならば、ちょっとややこしいのですが
:!start rundll32 url.dll,FileProtocolHandler "ファイル名"
ってな感じです。
詳細は $VIMRUNTIME/plugin/explorer.vim の115行目あたりからを読んでください。
0808名無しさん＠お腹いっぱい。
05/02/15 20:28:020809名無しさん＠お腹いっぱい。
05/02/15 20:31:25カーソル？ を移動させないで(カーソルがスクロールさせる前の文字の上のまま)
移動させることはできますか？
w3mで言う J みたいなことがしたいです
0810名無しさん＠お腹いっぱい。
05/02/15 21:08:16↓<C-E>
憶えにくいキーではある
0811名無しさん＠お腹いっぱい。
05/02/15 21:52:270812名無しさん＠お腹いっぱい。
05/02/15 22:07:070813名無しさん＠お腹いっぱい。
05/02/16 02:02:58_vimrcで
:cnoremap <c-j> <left>
とマップしてあると
VC6から起動させようとすると
:drop hogehoge.cp:123p
の様にコマンドラインに表示されるだけになってしまいます。
VisVimの方で対処してもらうってことは無理ですか？
0814KoRoN@Vim%Chalice ◆8XALICEsdk
05/02/16 03:04:20詳細までは調べていませんが、恐らくVim本体のOLEインターフェースに問題があるの
で、VisVimでの対応はしたくありません。ヘタにVisVim側だけで対応してしまうと、
別のキーマップで同じようなことが起こる可能性があるのです。
実際の修正をどうするかはわかりません。また申し訳ないですが、いついつまでに対
応できるというお約束もできません。
この件に限らず、既存のキーマップを書き換えるようなmapを利用する場合は、公開
されているスクリプトやマクロやツールが動かなくなってしまうことが十分に予想さ
れます。そのリスクを認識した上で、ある程度は覚悟の上でmapするようにしてくだ
さい。
# できればそういったキーについてはmapしないことを推奨しておきます。
0815名無しさん＠お腹いっぱい。
05/02/16 03:45:510816名無しさん＠お腹いっぱい。
05/02/16 07:19:280817名無しさん＠お腹いっぱい。
05/02/16 15:43:00文章を後で( V}gq などで)整形するとちゃんと禁則を処理してくれるのに
、入力中の場合はこのように句読点が先頭になってしまいまつ。
後でもう一度gqすればいいのではありますが、これなしで最初からちゃん
と禁則処理できるようにはならないでしょうか。
0818KoRoN@Vim%Chalice ◆8XALICEsdk
05/02/16 16:02:39残念ながらなりません。スクリプトレベルでは実現が難しいのに加えて、かといって
本体にそのような仕組みを組み込むというのも現状では(主に政治的な理由で)容易で
はありません。将来、状況が変われば実装可能ですが、直近では難しいとお考えくだ
さい。
0819813
05/02/17 01:17:48normal!的に処理することは出来ないのかなと思い、聞いてみたのですが
インターフェースの問題と言うならあきらめます。
># できればそういったキーについてはmapしないことを推奨しておきます。
私もそうしたいのですがcmapって特に余ってるkeyが少なくありませんか？
<right>と<left>をcmapさせるのに都合の良いkeyってありませんかねー？
0820KoRoN@Vim%Chalice ◆8XALICEsdk
05/02/17 02:27:26> normal!的に処理することは出来ないのかなと思い、聞いてみたのですが
私もそう思ったんですよ。でもいざ掘り返してみると歴史的(!)な事情で、できない
ようになっていることがわかりました。
> <right>と<left>をcmapさせるのに都合の良いkeyってありませんかねー？
http://vim.mydns.jp/?%A5%AD%A1%BC%A5%D0%A5%A4%A5%F3%A5%C9
とりあえずココ見て考えるのが良いでしょう。
0821名無しさん＠お腹いっぱい。
05/02/17 03:56:05> 歴史的(!)な事情で、できない
とかまるで自分が作ったかのような態度ってどうよ？
0822名無しさん＠お腹いっぱい。
05/02/17 09:06:37820の文章をどう読めば821のように思えるのかがわからん。
0823名無しさん＠お腹いっぱい。
05/02/17 10:21:37じゃあレス返すなよ
821 From:名無しさん＠お腹いっぱい。 Date:05/02/17 03:56:05 Mail:sage
Vim製作者でもないのに
> 歴史的(!)な事情で、できない
とかまるで自分が作ったかのような態度ってどうよ？
きっとKoRoNさんのファンなんでしょう。
0824名無しさん＠お腹いっぱい。
05/02/17 11:05:36＿＿＿＿
∧ ∧ ／;;;;;;;;;;;;;;;;;;;;;i＼ , -``-､ , -``-､
/ ヽ ./ .∧ ＼;;;;;;;;;;;;;;;;;;;/ ヽ ＼ ／ ）
/ ｀､ / ∧ ｀､;;;;;;;;;;;;;;/ ＼ ＼ ／ ／
／ ￣￣￣ ヽ ヽ ￣￣ /
（￣￣￣￣￣祭り命￣￣￣￣）￣祭り命￣￣￣） ￣祭り命￣￣￣）
/￣￣￣￣￣￣￣￣￣￣￣.＼￣￣￣￣￣￣ ＼ ￣￣￣￣￣￣ ＼
/:::::::::: ヽ-=・=-′ ヽ-=・=- /=・- -==・- |・=- -=・=- |
ヽ::::::::::: ＼＿＿_／ / ＼＿＿_／ / ＼＿＿_／ /
ヽ__:::::::::::::: ＼／ /:::::::: ＼／ /::::::: ＼／ /
／＼＼ ／/＼＼ ／/＼＼ ／/＼
｜ ＼＼ ／／ |＼＼ ／／ |＼＼ ／／ |
0825名無しさん＠お腹いっぱい。
05/02/17 12:18:36813 は KoRoN 氏にレスを期待したのだから、KoRoN 氏がどう答えようと、813 の捉え方次第であって、
たまたま 821 がそのレスを、嫉妬感情で捉えただけなんじゃ？
0826名無しさん＠お腹いっぱい。
05/02/17 14:49:06整合性保ったままでもかなりのカスタマイズができるよ
他のアプリに対してもワンショットトグルでvim風操作とか
vim風操作モード作って切り替えたりとかさ
0827名無しさん＠お腹いっぱい。
05/02/17 18:11:09それはそうだけど、gvim じゃないと無理じゃないか?
0828名無しさん＠お腹いっぱい。
05/02/18 00:45:46マーク使わなきゃダメなんでしょうか？
0829名無しさん＠お腹いっぱい。
05/02/18 01:02:03<C-o>
''
``
0830名無しさん＠お腹いっぱい。
05/02/18 01:17:260831名無しさん＠お腹いっぱい。
05/02/18 21:40:49何度も重複して検索している単語から印刷して、勉強したい。
0832KoRoN@Vim%Chalice ◆8XALICEsdk
05/02/18 22:09:45申し訳ありませんが、KaoriYaで配布するdicwinにそのような機能を実装する予定は
ありません。
0833名無しさん＠お腹いっぱい。
05/02/18 22:12:270834名無しさん＠お腹いっぱい。
05/02/18 22:22:03漏れは昔棒辞書ソフトにその機能要望したら無視された
便利と思うんだがなあ
0835名無しさん＠お腹いっぱい。
05/02/18 22:23:010836KoRoN@Vim%Chalice ◆8XALICEsdk
05/02/18 22:34:52dicwinは学習支援を目的としてはいないからです。またそうする予定もありません。
本当に勉強する気ならば、いきなり人が書くスクリプトには頼らず、まず手動で履歴
を残していくという手段を取ってみてはいかがでしょう。手動でやることが面倒にな
れば、キーボードマクロとして定義するのも良いでしょう。
<C-K><C-W>yj<C-W><C-P>:sp +$ ~/dichist.txt<CR>p<C-W><C-C>
こんな感じですかね。
# 個人的には、紙の辞書でひいたほうが遥かに覚えが良い、と考えています。
0837名無しさん＠お腹いっぱい。
05/02/18 23:07:39switch
case
case
とか
if
else if
else if
とかって対応できますか?
とりあえずこんなかんじで書いてみたものの、ifと最初のelseで行
ったり来たりしてしまう。
let b:match_words =
\ '\%(^\s*\)\@<=\%(if\|switch\)\>:' .
\ '\<\%(else\|else\s\+if\|case\)\>'
0838名無しさん@Vim%Chalice
05/02/19 00:09:26>>831
> dicwin で、検索した単語の履歴保存してくれませんか？
s:OpenDictionary(dic, word) 関数の、「Output result」と書いてあるとこらへん。
sp + ~/dichist.txt
call append('$', a:word)
xit
0839名無しさん@Vim%Chalice
05/02/19 00:15:33ヒント
autocmd FileType vim let b:match_ignorecase=0 | let b:match_words=
\ '\<if\>:\<elsei\%[f]\>:\<el\%[se]\>:\<en\%[dif]\>,' .
\ '\<wh\%[ile]\>:\<con\%[tinue]\>:\<brea\%[k\]>:\<endw\%[hile]\>,' .
\ '\<fu\%[nction]\>:\<retu\%[rn]\>:\<endf\%[unction]\>,' .
\ '\<try\>:\<cat\%[ch]\>:\<fina\%[lly]\>:\<endt\%[ry]\>'
0840名無しさん＠お腹いっぱい。
05/02/19 00:32:46改行してもcaseの位置までインデントが戻りません。これは正常な動作ですか？
0841名無しさん＠お腹いっぱい。
05/02/19 00:45:300842名無しさん＠お腹いっぱい。
05/02/19 01:06:08うーん。if else if elseはなんとかできたけど、最後のelseがな
い場合はうまくいかない。switchは全然だめ。
let b:match_words =
\ '\%(\%(^\|;\)\s*\)\@<=if\>:' .
\ '\<else\s\+if\>:' .
\ '\<else\>\%(\s\+\<if\>\)\@!,' .
\ '\<switch\>:' .
\ '\<case\>'
0843名無しさん＠お腹いっぱい。
05/02/19 01:10:10次のcaseで元に戻るからいいじゃん。
0844名無しさん＠お腹いっぱい。
05/02/19 01:44:28> # 個人的には、紙の辞書でひいたほうが遥かに覚えが良い、と考えています。
ソースコードを編集するときもVimなんて使わずに
紙にプリントアウトして鋏と糊で切り貼りすればいいじゃん。
0845名無しさん＠お腹いっぱい。
05/02/19 02:18:45epwing の辞書引きながら履歴残してくやつ。
重要単語なのに何度も引いてるような単語を重点的に覚えたりできたので、
使えないことはなかった。
0846名無しさん@Vim%Chalice
05/02/19 02:23:53勘違いしているね。
Vim の if には必ず endif が付いている。
C の if には、そういうものがない。
if( 1 ) puts("hello world");
だから C の if には、match_words の定義がない。
0847842
05/02/19 02:33:34まあそうなんだけど、elseやelse ifがあったときはそこを経由し
て巡回したいなと思って。
特にswitch文でcaseを辿りたいときは便利かなと。
0848名無しさん@Vim%Chalice
05/02/19 02:57:49>>847
>まあそうなんだけど、elseやelse ifがあったときはそこを経由し
>て巡回したいなと思って。
"else if のない if" と、"else if のある if" が入れ子になったらどうなる？
> 特にswitch文でcaseを辿りたいときは便利かなと。
case は１つですか？ 複数の場合があるでしょ。
switch に、一意に対応しない。
:h 'matchpairs'
ここからはじまったの
0849847
05/02/19 11:08:17caseはもちろん複数あるよ。
switch -> case 'a' -> case 'b' -> case 'c' -> switch
switch (a) {
case 'a':
case 'b':
case 'c':
たぶんmatchitではできないんだろね。あきらめるよ。
0850849
05/02/19 11:13:35がどのswitchに対応するかわからないということですね。
switch
case
case
switch
case
case
case
case
0851850
05/02/19 11:32:43ど、まあいいや。
\ '\<switch\>:' .
\ '\<case\>:' .
\ '\<default>\:'
0852名無しさん＠お腹いっぱい。
05/02/19 11:34:39if exists("loaded_matchit")
if !exists("b:match_words")
let b:match_ignorecase = 0
let b:match_words =
\ '\%(\%(^\|;\)\s*\)\@<=if\>:' .
\ '\<else\s\+if\>:' .
\ '\<else\>\%(\s\+\<if\>\)\@!,' .
\ '\<switch\>:' .
\ '\<case\>:' .
\ '\<default\>'
endif
endif
0853名無しさん＠お腹いっぱい。
05/02/19 19:03:07- help ファイルが 'fileencodings' に対応してない
- 'encodings' に指定されてるエンコードを 'fileencodings' に含めると動作が変
というのを改善するパッチを書いてみました。
vim-6.x を使い始めて日が浅いということと(今までは vim-3.0を使用)、
iconv を使ったプログラムに触れるのが初めてなので変な所があったら教えてください。
こちらの環境は OS:NetBSD-1.6.2、vim-6.3(patch1-62、iconv 使用) です。
なお iconv は GNU libiconv 1.9 を使ってます。
パッチと説明が以下に続きます。
0854853
05/02/19 19:10:10#define IS_THIS_NECESSARY 1 とかすると、前と同じになります。
begin 644 vim_fileio.patch
M*BHJ(&9I;&5I;RYC+F]R9PE3870@1F5B(#$Y(#`Q.C(P.C4T(#(P,#4*+2TM
M(&9I;&5I;RYC"5-A="!&96(@,3D@,3@Z,#(Z-#(@,C`P-0HJ*BHJ*BHJ*BHJ
M*BHJ*BH**BHJ(#<W,2PW-S8@*BHJ*@HM+2T@-S<Q+#<W-R`M+2TM"B`@"69E
M;F,@/2`H8VAA<E]U("HI(B(["0DO*B!B:6YA<GDZ(&1O;B=T(&-O;G9E<G0@
M*B\*("`)9F5N8U]A;&QO8V5D(#T@1D%,4T4["B`@("`@('T**R`C:69D968@
M25-?5$A)4U].14-%4U-!4ED*("`@("`@96QS92!I9B`H8W5R8G5F+3YB7VAE
M;'`I"B`@("`@('L*("`)8VAA<E]U"2`@("!F:7)S=&QI;F5;.#!=.PHJ*BHJ
M*BHJ*BHJ*BHJ*BH**BHJ(#@P.2PX,30@*BHJ*@HM+2T@.#$P+#@Q-B`M+2TM
M"B`@"7T*("`)9F5N8U]A;&QO8V5D(#T@1D%,4T4["B`@("`@('T**R`C96YD
M:68@+RH@25-?5$A)4U].14-%4U-!4ED@*B\*("`@("`@96QS92!I9B`H*G!?
M9F5N8W,@/3T@3E5,*0H@("`@("!["B`@"69E;F,@/2!C=7)B=68M/F)?<%]F
M96YC.PDO*B!U<V4@9F]R;6%T(&9R;VT@8G5F9F5R("HO"BHJ*BHJ*BHJ*BHJ
M*BHJ*@HJ*BH@.30R+#DT."`J*BHJ"BTM+2`Y-#0L.34T("TM+2T*("`@("`@
M("H@8V]N=F5R<VEO;B!T;R!55$8M."DN"B`@("`@("`J+PH@("`@("!F:6]?
M9FQA9W,@/2`P.PHK("-I9F1E9B!)4U]42$E37TY%0T534T%260H@("`@("!C
M;VYV97)T960@/2`H*F9E;F,@(3T@3E5,("8F("%S86UE7V5N8V]D:6YG*'!?
M96YC+"!F96YC*2D["BL@(V5L<V4**R`@("`@8V]N=F5R=&5D(#T@*"IF96YC
M("$]($Y53"D["BL@(V5N9&EF("\J($E37U1(25-?3D5#15-305)9("HO"B`@
M("`@(&EF("AC;VYV97)T960@?'P@96YC7W5N:6-O9&4@(3T@,"D*("`@("`@
%>PH@(`IF
`
end
0855853
05/02/19 19:12:20:help で表示されるファイルのエンコードを 'fileencodins' に指定してても
ちゃんと表示されない原因についての説明です。
ファイル読み込み部で 'fileencodings' をなめる前に、
:help からの呼び出しだったら utf-8 か latin1 で処理する、
というコードが入り込んでます。
これが原因で 'fileencodings' が効きません。
この部分を削ると 'fileencodings' を見てくれるようになります。
コメントを読むと 『ヘルプファイルは utf-8 か latin1 じゃなきゃだめ』
と読めますが、別にユーザに任せてくれれば良いような気が。
＃変換による情報の欠落をおそれてるのかなぁ。
バグではないのだろうけど、どうなんでしょ？
0856853
05/02/19 19:13:40vim のソースを読むきっかけとなった問題です。
:set encoding=euc-jp
:set fileencodings+=euc-jp,iso-2022-jp,sjis (元の 'fileencodings' に無い値を追加)
とすると、euc-jp のファイルが開けるけれども、
それ以外の iso-2022-jp、sjis のファイルは文字化けしてしまいます。
これが
:set fileencodings+=iso-2022-jp,euc-jp,sjis
だと sjis のファイルだけが化けて、
:set fileencodings+=iso-2022-jp,sjis,euc-jp
だと全部表示されます。
どうも 'encoding' に設定されている値が
'fileencodings' に含まれているとその後のエンコードが無視されるようです。
ちなみに、文字化け時の 'fileencoding' は全部 euc-jp になってます。
0857853
05/02/19 19:16:26ファイル読み込み時は、'fileencodings' の先頭から
エンコード名抜き出しチェックしていきます(ここでは fenc とします)。
処理の流れを簡単に説明すると次のような感じです。
1. fenc から 'encoding' へ iconv が変換できるかチェック (iconv_open)
- ここでは iconv がそのエンコードの変換に対応しているか調べるだけ
+ファイルがどのエンコードかは、この段階で不明
- iconv が対応してなければ次の fenc にチャレンジ
- 対応していれば iconv ディスクリプタをゲット
2. iconv ディスクリプタを元にエンコードの変換を試みる (iconv)
- 変換失敗(fenc とファイルとのエンコードが異なる場合)で次の fenc にチャレンジ
- 成功すると 'encoding' に変換されたデータをゲット
という処理を 2. が成功するまで 'fileencodings' をなめながら行います。
＃そして成功時の fenc が 'fileencoding' になると。
0858853
05/02/19 19:17:57が、ソースを読むと、fenc と 'encoding' が同じならば、
1. のチェックを省くというように書かれてます。
＃同じエンコードならば iconv のチェックの必要がないと考えた？
ただ、そうしてしまうと、iconv_open が呼ばれないわけで、
iconv ディスクリプタが手に入らなくなります。
そして、2. の処理の前には iconv ディスクリプタが有効かのチェックがあって、
無効だと iconv の変換が必要ないと判断され、2. の処理がスルーされます。
で、fenc とファイルのエンコードが一緒かどうか判断しないまま、
fenc を 'fileencoding' としたうえ iconv での変換もされません。
これでは、エンコードが違った場合は文字化けしてしまいます。
なので、1. の処理前にある『func と 'encoding'が同じなら〜』の判定を省き、
ちゃんと iconv_open を呼ぶようにしました。
0859853
05/02/19 19:20:22普通に動作しているようですが、一点問題があります。
:set encoding=euc-jp
:set fileencodings+=euc-jp,iso-2022-jp,sjis
の状態で、iso-2022-jp のファイルを開くと 'fileencoding' が euc-jp になります。
＃sjis のファイルは sjis になりオッケー。
そこで原因追求のため iconv のテストプログラムを書いてみました。
すると euc-jp -> euc-jp の変換用の iconv ディスクリプタを使って
iso-2022-jp の変換を試した所、エラーが発生せず iso-2022-jp に変換されました。
＃本来ならばエラーになって欲しい。
これのせいで、'encoding' == func == euc-jp かつファイルのエンコードが
iso-2022-jp だと文字化けしてます。
＃euc-jp を想定している所に iso-2022-jp のデータが流れてきてしまう。
iconv のバージョンを上げて調査したい所ですが、
エネルギーが切れてきたので、とりあえず報告だけということで。
0860853
05/02/19 19:22:39長くて誰も読まないﾖｶｰﾝ。
0861KoRoN@Vim%Chalice ◆8XALICEsdk
05/02/19 20:02:281について。そういう仕様ですし「むしろhelpの翻訳はUTF-8で書くべし」と考えた方が
なにかと都合が良いです。特に原文の文字を残したい場合など、CP932やEUC-JPでは表
現不可能な場合があり、実際問題KaoriYaのsvn上にある翻訳の最新版は全てUTF-8にし
ましたから、今後公開する版では全部UTF-8になります。仕様を変更したい、という話
でしたらvim-devかBram氏に直接提案してみてください。
2について。簡単に言ってしまえば、それはfencsの設定の仕方の問題で、わざわざソー
スを修正する必要はありません。enc=euc-jpならば
set fencs=ucs-bom,ucs-2le,ucs-2,iso-2022-jp-3,utf-8,cp932
これで良いでしょう。
Vimは「encへの変換をfencsの値を先頭から順番に試して成功したところで止める」と
いう文字コード判別アルゴリズムを採用しています。そして全て失敗した場合にはenc
がそのまま使われます(無変換)。ですからencに等しい値をfencsに入れる必要はありま
せんし、むしろ下手に入れてしまうとご指摘の問題が生じます。さらにそれだけではな
く、日本語での利用ではfencsに書かれた順番も重要な問題になります。KaoriYaで配布
しているパッチに、日本語向けのfencsを自動設定するスクリプトや、誤認識をある程
度補正するスクリプトが含まれているのは、それらを回避する目的です。
本質的な修正には、いまの場当たり的な文字コード判別アルゴリズムは破棄して、
Gaucheのようなしっかりした判定アルゴリズムを積みたいところですが…Bram氏を納得
させるには難しい面があります orz
0862KoRoN@Vim%Chalice ◆8XALICEsdk
05/02/19 20:17:56> Gaucheのようなしっかりした判定アルゴリズムを積みたいところですが…Bram氏を納得
> させるには難しい面があります orz
一応、認識している問題を具体的にしておきます。
1. 文字コード判別ライブラリとして(世界規模で)スタンダードなものがない。
2. 判別ルーチンは変換ライブラリが持っているのが自然に思われる。
しかし、POSIXで定義されるiconvにはその口が無い。
3. Vimの現在の方法はある程度以上、妥当に働いてしまう。
0863853
05/02/19 20:36:371はやはり仕様なんですか。
政治的なことは面倒なんで放置プレイかしらん。
>Vimは「encへの変換をfencsの値を先頭から順番に試して成功したところで止める」と
私もそう理解してますが、
変換に成功してない(試していない)のに成功と判定するのは変だと思ったのです。
何をもって変換成功とするかのとらえ方の問題ですかね。
>>862
はい、文字コードを判別する仕組みが iconv に無いことは調べてる最中にわかりました。
そしてそれで苦労している人がたくさんいることも。:)
日本語だけならまだしも、全コードとなると大変ですものね。
0864名無しさん＠お腹いっぱい。
05/02/19 21:56:44> 1について。そういう仕様ですし「むしろhelpの翻訳はUTF-8で書くべし」と考えた方が
> なにかと都合が良いです。特に原文の文字を残したい場合など、CP932やEUC-JPでは表
これってencがutf-8以外だと変換(表示)できなくてむしろ困る気がする。
結局は変換できない文字をつぶさなきゃなんないし、
最低限、encに合わせて変換した物を利用できるようにすべきだと思う。
そのほうがチープな環境もサポートするって意味でvim的な感じがする。
ていうか現状そうなってると思うんだけど、違うんかな。
0865名無しさん＠お腹いっぱい。
05/02/19 22:06:26後ろばかり見ているのはいかがなものかと。
0866KoRoN@Vim%Chalice ◆8XALICEsdk
05/02/19 23:00:55> 何をもって変換成功とするかのとらえ方の問題ですかね。
あるコードから同じコードへの変換は、どのような入力であっても明らかに成功する
とわかっている(仮定している)から、ということなのでしょうね。むしろ変換に成功
しないようなiconv実装は知らん、ぐらいの勢いが感じられますよね(笑)
あとはドキュメントの問題ですかね。help 'fencs'には幾つかのダメな設定例があ
がっていますが、encと同じ値を指定するという例はありませんから、追加するよう
に提案するのは1つのアイデアです。が、やはり本質的にはちゃんと自動認識して欲
しいですよね。
>>864
> これってencがutf-8以外だと変換(表示)できなくてむしろ困る気がする。
それにはiconvが無いと使えなくなるとか、iconvの実装の問題というところもあるん
ですが、大元のデータとしてはUTF-8で表現しておくのは決して間違いではありませ
ん。あとは、どのタイミングで何を使ってコンバートするか、だけの問題です。
> そのほうがチープな環境もサポートするって意味でvim的な感じがする。
> ていうか現状そうなってると思うんだけど、違うんかな。
現状からは否定できないところです(苦笑)。でも個人的には最終的に、encはUTF-8固
定にするのが一番良いと考えてます。そして必要に応じて表示する直前でtermencを
使う。どの文字を潰してどう表現するかはiconvの実装に任せれば良いわけです。
GNOME,KDE,WinならばUTF-8からiconv使わずに表示できますから、コードが小さく単
純にできるし、基幹部分も速くなります。
# Vim7ではリファクタリングするとか宣言してたと思うけど、本当にするのかな?
■ このスレッドは過去ログ倉庫に格納されています