なぜそれが必要ですか
チーム開発では、特定のコーディング標準に従うことが重要です。 これは、変数、関数などの命名に関するものではありません。 上記は主に経験とテキストで考えを定式化する能力の問題です。 多くの場合、コーディング標準は次のことを定義することから始まります。
同じファイル内の
異なる人が上記のスタイルパラメータを守らないと、次の問題が発生します。
多くの場合、このような問題は、プロジェクトに入った新しい人がエディターを正しく構成しなかったために発生します。これは、同じファイルの異なるバージョンを比較する必要が生じる瞬間まで気付かれません。
ファイルを開くときにこのような問題をすぐに見るために、小さなプラグインを作成しました。
なぜプラグインなのか
これにはいくつかの理由がありました。
- ほぼ2年間、私は定期的にコードを編集するためにVimを使用してきました。
noexpandtabオプションでインデントにスペースが使用されている場合、 listcharsなどの標準設定を使用しても強調表示されませんftplugin設定への依存関係の設定
機能的
expandtabオプションに従って空白を強調表示します。このオプションが有効な場合、タブは赤で強調表示されます。それ以外の場合、行の先頭のスペースは黄色で強調表示されます- 行末の空白を強調表示する
textwidthオプションで指定された長さを超える行の一部を強調表示する
内部プラグイン
プラグインは、
matchadd()関数に基づいています。 この関数は、指定されたパターンと一致するオープンバッファを検索し、指定されたバックライトスキームに従ってハイライトします。
たとえば、バッファ内のすべてのスペースを黄色で強調表示します。
:highligh Spaces ctermbg=Yellow guibg=Yellow :call matchadd('Spaces', '\s\+')
一般的なバックライト機能は次のとおりです。
function FileStyleHighlightPattern(highlight) call matchadd(a:highlight['highlight'], a:highlight['pattern']) endfunction
バックライトスキームの名前と比較用のパターンを含む辞書が入力で受け入れられます。
プラグインがパターンのチェックを自動的に開始するには、プラグインの初期化時に自動コマンドを追加する必要がありました。
augroup filestyle_auto_commands autocmd! autocmd BufReadPost,BufNewFile * call FileStyleActivate() autocmd FileType * call FileStyleCheckFiletype() autocmd WinEnter * call FileStyleCheck() augroup end
FileTypeイベントハンドラの目的を個別に言及する価値があります。 プラグインの内容は任意であり、現在の設定と一貫性がなく、ヘルプウィンドウから編集できないため、プラグインが
helpファイルで機能しないように追加する必要がありました。
ウィンドウを分割する（
:split ）ときに、開いているウィンドウにもハイライトが表示されるように、
WinEnterハンドラー
WinEnter必要です。
これが最終結果です。
リンクをダウンロードできます：
vim.org |
GithubUPD： undefined variable filestyle_activeエラーが
undefined variable filestyle_activeさ
undefined variable filestyle_active 。 GitHubおよびVim.orgにアップロードされた変更