コンパイラが1つあるため、すべてのエンコーディング（テキストファイルとVIMロケール）をcp866に持ってきますか？ 面白くない。 エラーの意味についてコンテキストから推測しますか？ これまでのところそうしました。 疲れた。 私たちはそれを理解し、数晩過ごし、この迷惑な誤解を忘れる必要があります。
クイックフィックスシステムは機能します。makeの出力はエラーファイルに送られ、間違ったコード行の番号とエラーのタイプがそこから選択され、コンパイル後すぐにカーソルが正しい場所に置かれます。 エラーの本質を理解することは簡単ではありません：
そして、次のコマンドは、コードの誤った行にジャンプすることを可能にしますが、コードを読むことには役立ちません：
注：たとえば、オプションmakeef = error.errが（makeコマンドの表示行を短くするために）使用されましたが、通常はデフォルトで空になっており、makeエラーファイルはTEMPで作成されます。
どうやら-なんてナンセンスだ！ エンコードオプションを修正します...しかし、いや-それは世界的な感染症です。 したがって、エンコーディングは、ソースウィンドウを含むすべてのオープンバッファのどこでも変更されます。 ロシアのカーンのコメント。 VIMメッセージ自体も。
試すことができます：set encoding = cp866を手動で設定します。これを$ VIM / vimfile / ftplugin / qf.vimに固定して、コマンドで動作するようにします。 あなたも試すことができます：setlocal-助けにはなりません。
単一のバッファでエンコードを変更することは不可能です。エラーファイル自体をトランスコードしようとします。 これを行うには、ヘルプを見て、makeを呼び出すと、次のシーケンスが実行されることがわかります。
- 'autowrite'オプションが有効な場合、変更されたすべてのバッファーが書き込まれます。
- エラーファイル名は、「makeef」オプションの値に従って計算されます。 'makeef'オプションの値に「##」が含まれていない場合、同じ名前の既存のファイルが削除されます。
- プログラムは、オプションの[arguments]のセットを持つ 'makeprg'オプションの値で指定された名前（デフォルト： "make"）で始まり、その出力はエラーファイルにリダイレクトされます（Unixでは、出力も画面に表示されます）。
- 「errorformat」オプションの値を使用してエラーファイルが読み取られています。
- 修飾子[！]が設定されていない場合、システムはリストの最初のエラーに移動します。
- エラーファイルが削除されます。
- これで、次のようなコマンドでエラーリストをナビゲートできます：cnextおよび：cprevious。
次のコマンドでqfバッファーを開くと、エラーファイルは存在しません。 あなたはあいまいな方法でそれを返してみることができます-$ VIM / vimfile / ftplugin / qf.vim write
setlocal encoding=cp866 setlocal fileencoding=cp1251 w! ./error.err setlocal encoding=cp1251
つまり、コマンドでqfバッファーを開くと、エンコードの変更に対応し、ファイルのエンコードを挿入し、新しいエラーファイルを書き込み、エンコードを返します。 ちなみに、ここではlocalを省略することができます-まだ役に立ちません。 これで、新しいエラーファイルcf ./error.errを手動でインストールできます。
glyく、不快で、多くの余分な手の動き。 コンパイル後、最初に対処する必要があります。次にccl、次にcf ./error.err、再度対処します。 これをすべてqf.vimに挿入しようとすると、VIMが単独で絞め殺すという必死の再帰が発生します。 そして：対処は奇妙に振る舞います：余分なスティックが行の先頭に追加され、理由を理解するのをためらいます。
それでは、エラーファイルの読み取りの近くではなく、コンパイラの出力に近い瞬間をキャッチしてみましょう。 もう一度ヘルプを見てみましょう。
「：make」コマンドは、「makeprg」オプションの値で指定されたプログラムを実行します。 これは、 'shell'オプションの値で指定されたシェルからコマンドを呼び出すことで発生します。 つまり、コマンドを入力するときとほぼ同じことが起こります
":!{_makeprg} [] {_shellpipe} {_}".
ここで、{makeprg_value}は 'makeprg'オプションの文字列値です。 makeだけでなく、必要なプログラムを使用できます。
感嘆符「：！{コマンド}」では、指定された{コマンド}をシェルで実行する必要があります。 つまり、実行中にファイルで発生するイベント：makeは失敗します。 崩壊した自動車チームを使用したいと考えています。 しかし、早くあきらめます。 よく見てみましょう
'shellpipe' 'sp'文字列（デフォルト： ">"、 "| tee"、 "|＆tee"または 「2>＆1 | tee」） グローバルオプション このオプションは、シェルを強制する行を指定するために使用されます 「：make」コマンドの出力をエラーファイルに書き込みます。
VIMのデフォルトはshellpipe =>％s 2> $ 1であることが判明しました。 外部コマンドラインユーティリティを使用して、何らかの形でこのシェルパイプの途中に配置する機会があるようです。
libiconvページのGnuWin32プロジェクトにあるiconvを使用します。 ファイルまたはコンソールストリームからデータを受信できます。 私はそれをC：\ bin \に置きます。ここで、make、ctags、7z、いくつかの補助バッチファイル、およびいくつかのdllが既にあります。 依存関係を忘れないでください（依存関係、つまりlibintl3.dllはユーティリティページにあります）。
VIMとは別にコマンドラインで再生して、入力とオプションをフィードする方法を見つけました。 それから私は同じことを試みましたが、すでにVIMコマンドラインで。 2番目または3番目の試みのどこかで何かが起こりました：
:set shellpipe=\|c:\\bin\\iconv\\iconv.exe\ -c\ -f\ CP866\ -t\ CP1251>%s\ 2>&1
ユーティリティへのフルパスのパイプ文字、スペース、およびバックスラッシュは、バックスラッシュでエスケープされます。 完全なパスについては-もちろん、このように倒錯することはできませんが、PATHにiconvへのパスを書くことができますが、個人的にはこの方法は好きではありません：稼働中のコンピューター上の4つのIDE / CADが互いに完全に互換性がなく、そしてすべてがPATHで書かれています。 完全なパスの方が信頼性が高くなります。
一般に、それは働いた。 指定した行（先頭にコロンなし）をファイル$ VIM / vimfile / ftplugin / a6403.vimに書き込みました。 現在、「シェルパイプ」は、この特定のcなファイルタイプを開くときにのみトランスコーディングに変更されます。 結果は次のとおりです。
ソース内のロシア語のコメントは読みやすく、エラーメッセージもエラーによってジャンプします。 ソリューションは理想的ではありません：
- 変換ツールが組み込まれたサードパーティのユーティリティを使用する必要がありました。 言い訳：この場合、特に怖いわけではありません-サードパーティのコンパイラ、サードパーティのctag、およびサードパーティのmakeを使用すること。 さて、私のCにはもっとファイルがあります：\ bin \ ...
- shellpipeオプションはグローバルであり、すべてのバッファーに適用されます。 言い訳：この特定のアセンブラーのファイルを開かないと、誰も感じません。 他の翻訳者と一緒に他の同時に開いているバッファを開いて同時に作業する場合、英語を話すコンパイラは紫色（チェック）になり、ロシア語を話すコンパイラ（cp866）は有益です。
2番目の欠点を解消するために、makeprgオプションをローカル（setlocal）でオーバーライドできます。「$ *」のシーケンスで特別な「スタブ」を追加し、コマンドライン引数に置き換えて、iconvを呼び出します。 その後、シェルパイプを自由のままにしておくことができます。 そして、垂直バーは、3つのバックスラッシュですでにシールドされている必要があります。1つはコマンド用、2つ目はコマンドの解析時に必要な3つ目をエスケープするためです。
setlocal makeprg=c:\bin\make.exe\ $*\ \\\|c:\\bin\\iconv\\iconv.exe\ -c\ -f\ CP866\ -t\ CP1251
さまざまな種類のインターネットでこれ以上成功する方法は見つかりませんでした。 実際、私は何の方法も見つけませんでした。 たぶん私はとても不運だったのでしょうか？ しかし、少なくともチームをチームに導入するというアイデアが役立った場合、私は喜んでいます。