Vim scriptを少し触った際の備忘録_20190828

  Vim script使ってプラグイン、とまでいかないまでも自分の使いたい処理を作ろうとした際の忘備録
結果的に途中で破綻したのと代替え手段ができたので成果物はないのだけど、それまでに得た知見のメモ
 

次は破綻させたくないので先に確認したいこと

欲しい情報の取得する情報が求めるフォーマットで取得できるか
ちゃんと標準出力されているか確認する。
自分が誤ったのは標準出力でない結果を標準出力の結果と誤認してしまったことで起きた。
まずモノ作る前にそれぞれのパズルのピースが繋げられるものかイメージしないといけない。

結果を考える
値を返すならどのようなインターフェースで返すか（バッファで表示させるとか）
ここらへんまだよく把握していない。標準出力以外にもQuickfixなどを使えば幅が広がりそう。
vimのインターフェース（どのように結果を受け取れるか）の知見をためたい。

quickfixコマンドはより一般的に、ファイル中の位置のリストを作成し、ジャンプする ために使うことができる。 https://vim-jp.org/vimdoc-ja/quickfix.html

値の加工
受け取った値などの加工などは都度調べたらよさそう。
順番的にはインプット、加工、アウトプットなのだけど、
実現可能かを考えるにはインプット、アウトプットを先にイメージしたらよさそう。本種あれば加工は大体どうにかなりそうなので

調べていた際に参考にさせて頂いた記事（一部抜粋）

Vim Script でカンマ区切りの文字列を余計なスペースを除去しつつリストに変換する https://qiita.com/syu_cream/items/848f5ffe3f9a62cad612 :echo split(substitute("hoge, fuga", " ", "", "g"), ",")

webで調べてもいいけど、ヘルプが充実しているのでhelpコマンドで調べたほうが充実した情報を取れる気がする

:h
:h echo

その他参考

vimエディタのヘルプドキュメントのgrep検索 https://nanasi.jp/articles/howto/help/helpgrep.html

それでも調べきれないときはvim-jpのquestionのチャンネルで質問させて頂いたりなどした
(質問できる場所があるというのは嬉しい)
https://vim-jp.org/docs/chat.html

アウトプットがないような処理
選択した範囲を加工して反映する、みたいなは結果を返さず単に領域内を取得して加工する、みたいな感じになるのだろうか（調べられていない）。  

トライアンドエラーを繰り替えせる環境を作る
最初は乱暴に自分の.vimrcにスクリプト書いて再読み込みさせ挙動みていたけど流石にテスト用のスクリプトは別にきったほうがよさげ

nmap ;s :source ~/myVimscript.vim<CR>

他人のプラグインを読む
興味本位で自分が愛用させて頂いているプラグインを読もうとした際のメモ

最初はまず何をどこから読めばいいのかさえわからず
よく使っているコマンド名を調べて、それがどこのfunctionで定義されているかを調べてみようとしていた

そもそも誤っていたこと
functionとcommandを混同していた
（プラグインを経由して呼び出しているのはcommand（最初プラグインのソース読んでいたときにfunctionをずっと探していたが、 該当のコマンド名がなくて混乱した）
    https://nanasi.jp/articles/code/command/command.html

よく使っているコマンドを調べるならcommand コマンド名 が定義されている場所を調べて、そこでcallされている処理を探すというステップが必要だった

また、githubから取得したプラグインはgitで管理されているのでgit grepで検索できる。
最初からこれ駆使すればもう少しハマる時間短縮できたかも）

その他、色々省略記法があることを把握しておいたほうが良さそう
（推測できるけど、確認しないとただの省略記法なのか否か不安が残る）

https://vim-jp.org/vimdoc-ja/usr_20.html ユーザーマニュアルではコマンドの長い名前と短い名前の両方が使われますが、読み難い短縮形は使われません。例えば、":function" は ":fu" と短縮できますが、これだと大半の人が何の略なのか理解できないので ":fun" が使われます。

他人のプラグイン読み始めた際に、あまりにとっかかりがないのでvim-jpの質問部屋で聞いたときに頂いたアドバイス

• コマンドを定義しているところをみる
• コマンドが呼んでいる関数をみる
• そこから追いかけていく ざっと眺めたい場合 autoload とかのを上からザーッと眺める

Vim script読むときはまずdoc/*.txtをざっとみて、次にテストを読むと便利かもです。 (逆に言うとdocやテストがないプラギンは勉強用には良くない罠プラギンということもわかって便利です) (※実用上便利かは別で勉強目的だとやはりそういう周辺系がちゃんとしてると便利的な意味で)

plugin ディレクトリ → ファイルの種別によらないとてもグローバルな処理 (キーマップとかコマンドの定義、イベントの登録、変数宣言など)を置く場所 ftplugin ディレクトリ → ファイルの種別に特化した処理を置く場所 autoload ディレクトリ → 遅延で読み込まれるソースコードを置く場所 syntax ディレクトリ → シンタックスハイライト定義を置く場所 みたいな置き場所が決まってます。

その他所感

Githubで公開されている他人のコードを読む習慣がないので
これはサイズ的にも手頃だし習慣づけるにはよさそうと思った
がどうしても自分の中での優先順位は下がってしまう。いくらか時間のゆとりがあるときでないと触る頻度が落ちそうと感じた（というか現状落ちている）
大枠から少しずつわかっていくことを意図しながらソース読んでいるが、細かいところで何をしているかなどは現状全然読み解け無い

自分の中でVim scriptは趣味の部類（実務で使うことはないと思うため）に該当するので、他の言語の学習より優先度下がって触らなくなる（忘れる）の形になりやすいと感じた。
ただ前々から気になり続けている言語ではあるため、少しずつでも知見をストックして忘備録としてためていきたいところ。