VimConf 2023 Tiny に行ってきた

昨日(11/18)はVimConfに行ってきました。
前回が2019年だったので実に4年ぶりの開催でした。

vimconf.org

2017年から2019年は3回ともスピーカーでしたが、今回は久しぶりの一聴衆でした。
なので当日は全く緊張する必要がなく、とても穏やかな気持ちで参加することができました。

また、休憩時間や懇親会などで久しぶりに会えた人と話をすることができ、とても懐かしい気持ちになりました。
そして古巣の皆さんのVim愛は変わらないどころか、さらに強まっていて感慨深かったです。

ただ後になってみると、新しい所属でのVim活なんかをLTしても良かったかなと思ったりもしました。
この感覚はVimConf 2016に参加した時に似ていて、あの時も「自分も登壇したい!」という気持ちになったことを覚えています。

最後に、発表者とスタッフの方に改めて大きな感謝を伝えたいです。
特にスタッフの方は限られたリソースの中でとても大変だったと思いますが、今までのVimConfと変わらない体験を得ることができました。
来年も楽しみにしています。

macvimをビルドする(2023/08)

だいぶ前にも書いていた。

daisuzu.hatenablog.com

ここ最近は毎朝UpdateMacVimを実行している。*1

UpdateMacVim() {
    cd $HOME/go/src/github.com/macvim-dev/macvim
    git fetch origin master
    if [ -z "`git diff FETCH_HEAD --shortstat`" ]; then
        cd -
        return 0
    fi
    git merge FETCH_HEAD
    make distclean && ConfigureMacVim && make
    rm -rf $HOME/.local/MacVim.app
    cp -R src/MacVim/build/Release/MacVim.app $HOME/.local/
    cd -
}
ConfigureMacVim() {
    ./configure \
        --enable-fail-if-missing \
        --with-features=huge \
        --enable-terminal \
        --enable-multibyte \
        --enable-python3interp \
        --enable-luainterp \
        --with-lua-prefix="$(brew --prefix lua)" \
        --enable-cscope \
        --with-tlib=ncurses \
        --with-compiledby="daisuzu <daisuzu@gmail.com>" \
        CFLAGS="-I$(brew --prefix)/include" \
        LDFLAGS="-L$(brew --prefix)/lib" \
        --prefix=$HOME/.local "$*"
}

あとは$HOME/.local/MacVim.app/Contents/binにパスを通しておけばOK。

*1:ghq getしたのでGOPATHにmacvimのリポジトリがある

Vimの極意

この記事はVim Advent Calendar 2022の1日目の記事です。

今年でVimをメインエディタにして15年になります。
最近どうすれば思考する速度でテキストを編集できるようになる*1のか考えたりすることがあったので、この機会に軽くまとめてみます。

簡単な操作であれば「○○をしたい」と思った瞬間にそうなっていることもありますが、実際はそうならないことがの方が多いです。
それが何故なのかというと、複雑な編集をする際には自分のやりたいことをVimの操作に変換する必要があり、そこに時間がかかっているからだと考えました。

そこで思いついたのが、やろうとしていること自体をVimのコマンド群として捉えられるようになればさらに高速にテキストを編集できるのではないか、ということです。

具体例をあげてみると、以下のようなGoのコードでカーソルがfuncのfにある時に、戻り値の型をClientInterfaceから*Clientに変更したいと思ったら、

func NewClient() ClientInterface {
    return newDefaultClient()
}

戻り値の位置にカーソルを移動して、カーソル下の単語を*Clientに書き換えよう、と考えてVimを操作するのではなく、
最初から$bcw*Clientと考えてVimを操作します。

つまり、「あらゆる編集操作をVimのコマンドで表現できるようになる」ことがVimの極意ということになります。

実際に文章に書いて読んでみるとかなり難しそうな気がしてきましたが、
これを会得する方法としては以下の7つが考えられます。

  1. 極意のことを意識しながらVimを使い続ける
  2. 定期的にVimのヘルプを読み返してコマンドとしての語彙を増やす
  3. 指に負担を感じたら少し立ち止まってより良い方法がないか調べる
  4. VimGolfをやる
  5. 覚えにくい処理をユーザー定義コマンドやマッピングにする
    • vimrcを育てる
  6. 4で汎用性が高いものをプラグインにする
    • 既に似たようなプラグインがあればそれを使っても良い
  7. 5で有用なものをVimの本体に組み込む
    • Vim本体の実装に対する知識が必要

ある程度身に付いてくれば先のサンプルコードで戻り値の型がわからなくてもすぐに
/newD<CR><C-]>Wyiw<C-T>j%bcw<C-R>0<ESC>が出てくるようになることでしょう。

ぜひ試してみてください。

*1:実践Vim 第21章の続き

Vimのterminalでパイプを使う

この記事はVim Advent Calendar 2021の9日目の記事です。

Vimにterminal機能が追加されてずいぶん経ちましたが、普段はtmux上でVimを使っていたので実際のところ使用頻度はそんなに高くありませんでした。
たまに使った時は出力がVimの中に閉じているため、検索したり編集したりはtmuxのペイン分割と比べてやりやすいなと思うことがあったくらいです。

ただ、最近になって似たようなコマンドを何度も実行することが増えてきて、その度にシェルの履歴から探してきてはコマンドライン引数を変更して実行するのが煩わしくなってきました。
例えば以下のようなコマンドです。

go test \
    # 1. 詳細な出力が欲しい(-v)
    # 2. カバレッジが取りたい(-covermode, -coverprofile, -coverpkg)
    # 3. 実行するテストを指定したい(-run)
    # 4. goldenファイルを更新したい(-golden)
    # 5. テストの分析がしたい時は出力を自作コマンドに流し込む

1〜4までは:executeを使って組み立てたcmdを実行するようにすれば良いので簡単です。

:execute 'terminal ' . cmd

ところが5で出力を流すのに、パイプ(|)をどのように使えば良いのかわかりませんでした。
いくつか試してみたところ、bash(やzsh)の-cオプションに""で実行したいコマンドを渡してあげれば良いことがわかりました。

" grepが効かない(`|`以降もvimコマンドの引数として扱われる)
:terminal vim -h | grep vimrc

" エラー
:terminal bash -c 'vim -h | grep vimrc'

" OK
:terminal bash -c "vim -h | grep vimrc"

これを自作コマンドにしておくと簡単に実行できます。

当初は柔軟に実行できる形にしようと思っていましたが、組み合わせはある程度固定化されていたので3、4パターンほどコマンドとして定義しておき、必要に応じて修正するような使い方をしています。
シェルスクリプトMakefileにしておくのも手かと思いますが、管理の手間などを考えると自分にとってはvimrcに書いておくのが一番楽でした。

curlとjqを組み合わせても良さそうなので、必要になったら同じようにしてやってみようと思っています。

vim-lspのCallHierarchyをツリーっぽく表示する

リファクタリングしたりコードを調べたりする時、呼び出し元を探すのにLspReferencesLspCallHierarchyIncomingを使っていた。
ただ、どちらも1階層分しか表示してくれず、呼び出し元が遠いと影響範囲が把握しにくかったのでquickfixに結果をマージして表示するコマンドを作ってみた。

command! AppendCallTree call s:append_tree(':LspCallHierarchyIncoming')
command! AppendRefTree call s:append_tree(':LspReferences')

augroup AppendTree
    autocmd!
augroup END

function! s:append_tree(cmd) abort
    autocmd AppendTree BufWinEnter quickfix let s:lsp_done = 1

    copen                            " quickfixに移動し、
    let l:pos = line('.')            " 現在の行番号と、
    let l:parent_tree = getqflist()  " 内容を取得し、
    call setqflist([])               " いったん空する
    let l:level = count(l:parent_tree[l:pos-1].text, '⬅️  ')
    wincmd p

    " 元のバッファで指定したコマンドを実行し、
    let s:lsp_done = 0
    execute a:cmd

    " 完了するかある程度時間が経過するまで待つ
    let l:cnt = 0
    while !s:lsp_done && l:cnt < 100
        sleep 10m
        let l:cnt += 1
    endwhile

    let l:child = getqflist()
    if len(l:child) != 0
        " 新たに取得した分は先頭に⬅️を付けて元の位置の下に挿入する
        call extend(l:parent_tree, map(l:child, 'extend(v:val, {"text": repeat("⬅️  ", l:level+1) . v:val.text})'), l:pos)
    endif

    " 結果(取得できなかった場合は元の内容)をquickfixに表示し、
    " 次の場所にジャンプする
    call setqflist(l:parent_tree)
    execute 'cc ' . string(l:pos + 1)

    autocmd! AppendTree
endfunction

AppendCallTree実行後は@:などで繰り返せるので調査が楽になった。

f:id:daisuzu:20210312165925g:plain
例: goplsのCallHierarchy

  • LSPを直接呼ぶのは面倒なのでコマンドを実行する形式にした
    • 特にCallHierarchy...
  • 専用バッファよりquickfixの方が何かと扱いやすいのでやらなかった
    • 何も考えずにジャンプできるし
    • フィルタも簡単だし

go/analysisのSuggestedFixでコードを修正する

Goの既存コードを修正するツールを作る時、

  • 既存コードをどう書き換えて
  • 出力して
  • テストするか

を考えなければいけないのが少し面倒だと思っていました。
が、golang.org/x/tools/go/analysisSuggestedFixを使えばすごく簡単にできてしまいます。

golang.org/x/tools/go/analysisstaticcheckgolangci-lintなどの静的解析ツールでよく使われているパッケージです。

例えば以下のような、関数の引数にcontext.Contextがあるかどうかチェックするツールがあったとして、

func run(pass *analysis.Pass) (interface{}, error) {
    inspect := pass.ResultOf[inspect.Analyzer].(*inspector.Inspector)

    nodeFilter := []ast.Node{
        (*ast.FuncDecl)(nil),
    }

    inspect.Preorder(nodeFilter, func(n ast.Node) {
        decl := n.(*ast.FuncDecl)
        if decl.Type.Params.NumFields() > 0 {
            // NOTE: 第1引数のみを文字列でチェックしているので厳密ではない
            if types.ExprString(decl.Type.Params.List[0].Type) == "context.Context" {
                return
            }
        }

        pass.Reportf(decl.Pos(), "missing ctx in parameter")
    })

    return nil, nil
}

これを、もしチェックに引っ掛かったら引数にcontext.Contextを追加できるように変更してみます。

まずはpass.Reportfpass.Reportに変更し、直接Diagnosticを渡せる形にします。

pass.Report(analysis.Diagnostic{
    Pos:     decl.Pos(),
    Message: "missing context in parameter",
})

そしてSuggestedFixesとしてコードを変更する場所(PosからEnd)と書き換え後のコード(NewText)を渡します。

pass.Report(analysis.Diagnostic{
    Pos:     decl.Pos(),
    Message: "missing context in parameter",
    SuggestedFixes: []analysis.SuggestedFix{{
        Message: "add ctx to parameter",
        TextEdits: []analysis.TextEdit{{
            Pos:     decl.Pos(),
            End:     decl.Type.Params.Closing + 1,
            NewText: b,
        }},
    }},
})

書き換え後のコードは標準パッケージのformat.Nodeを使って作ります。

func newText(pass *analysis.Pass, decl *ast.FuncDecl) ([]byte, error) {
    // Godoc、戻り値、関数の中身は使わずにコードを整形する
    f := &ast.FuncDecl{
        Recv: decl.Recv,
        Name: decl.Name,
        Type: &ast.FuncType{
            Params: &ast.FieldList{
                List: append([]*ast.Field{{
                    Names: []*ast.Ident{{Name: "ctx"}},
                    Type: &ast.SelectorExpr{
                        X:   &ast.Ident{Name: "context"},
                        Sel: &ast.Ident{Name: "Context"},
                    },
                }}, decl.Type.Params.List...),
            },
        },
    }

    var buf bytes.Buffer
    if err := format.Node(&buf, pass.Fset, f); err != nil {
        return nil, err
    }
    return buf.Bytes(), nil
}

この書き換えを実際に適用するにはコマンドラインツールとして実行する時に-fixフラグを付けるようにすればOKです。
なお、-fixフラグはunitcheckerだと渡せないため、main.gosinglecheckermulticheckerを使う必要があります。

もしくは、goplsAnalyzerとして組み込むことでエディタと連携して使うことも可能です。
多少作り込みが甘くても、リファクタリングする時だけ以下に追加し、go installして使ってみても良いかもしれません。 https://github.com/golang/tools/blob/gopls/v0.6.4/internal/lsp/source/options.go#L1108-L1150

vim + vim-lspは該当箇所で:LspCodeActionを実行すると呼び出せます。

f:id:daisuzu:20210128120803g:plain
vim-lspのLspCodeAction

テストについてはanalysistest.Runanalysistest.RunWithSuggestedFixesに変更すればgoldenファイルと比較してくれるようになります。

編集を加速するVimのquickfix機能

この記事はVim Advent Calendar 2020の3日目の記事です。
昨日は@mira010さんのvim pluginsをインストールしてみましょうでした。

みなさんquickfixを使っていますか?
Vimのquickfix機能はgrepやmakeなどの結果を保持する専用のバッファと、それを扱うための各種コマンドからなります。
IDEには当たり前のようにあるような機能ですが、Vimの場合は他の機能と組み合わせることで編集操作を格段に効率化できます。

:grep:makeも、

  1. 外部コマンドを指定した引数で実行し、
  2. ファイル名や行番号、メッセージなどの出力を解析し、
  3. ジャンプのために使えるリストを作ってくれる

のは共通です。
このリストはquickfixリストと呼ばれるもので、:copenで専用のウィンドウが開きます。
そして<Enter>キーやダブルクリックで該当行にジャンプします。

ただデフォルトのgrepコマンドはまだしも、makeコマンドは滅多に使わないという人もいるかもしれません。
その際はgrepprgmakeprgオプションで実行する外部コマンドを任意のコマンドに変更できます。
(出力される結果が解析できない形式の場合はerrorformatなども変更する必要があります。)

grepコマンドはgit grep

" スペースはエスケープが必要
set grepprg=git\ grep\ -n\ --no-color

makeコマンドはlinterやタスクランナーなどにするとグッと使いやすくなります。

" 使用例
" :make ./...
" :make --disable-all -E staticcheck
set makeprg=golangci-lint\ run

これらの設定はvimrcに書いておいたり、簡単に切り替えられるコマンドやマッピングを用意しておいても良いでしょう。

しかし、quickfixリストは同時に複数の結果を表示することができません。
そのため、複数のquickfixリストを扱うには:colder:cnewer:chistoryを使って履歴を行き来する必要があります。
もしくはlocationリストを使います。

locationリストとはウィンドウローカルなquickfixリストのことで、コマンドのプレフィックス

だけで、quickfixリストと同じように使えます。

そのため、別のウィンドウやタブページで個別にlocationリストを開くことで複数の結果を表示できます。

さて、ここまで紹介した機能だと便利なジャンプリストでしかありません。
quickfixリストを使ってさらに効率的な編集をするには、:cnextとマクロを組み合わせて使います。

例えばgrepで絞り込んだ行の特定の文字列を置換したければ、以下の操作を(qqなどで)マクロに記録し、

:s/Before/After/
:w
:cnext

大きな数を指定して(100@q1000@qで)実行すると、quickfixリストの最後まで自動的に繰り返してくれます。
リストが指定した数より少なければそこでマクロが止まってくれるので重複実行は気にしなくて大丈夫です。

この時、さらにquickfixリストを絞り込みたくなることがあるかもしれません。 :grepの場合は正規表現を工夫しても良いですが、:packadd cfilterで使えるようになる:Cfilterでquickfixリストを絞り込んでしまうのがとても楽です。

それでも絞り込むのが難しい場合、いったん別のバッファにコピーして編集し、:cbuffer:cgetbufferでquickfixリストを読み込み直しても構いません。
(quickfixリストを:setlocal modifiableして書き換えるのはちょっと乱暴なので非推奨です。)

また、quickfixリスト自体をファイルとして保存しておき、:cfile:cgetfileで読み込み直すことも可能です。
そうするとジャンプ可能なTODOリストとしても使えるので、リストが巨大だったら少しずつ進めたり、他のVimmerと作業を分担する、なんてこともできるかもしれません。

ということで、ぜひquickfix機能を活用してみてください。

本当はより実践的な例として、最近やったことを具体的なコマンド付きで紹介できれば良かったんですが、ある事情でそのヒストリーをロストして再現環境もなく...
覚えている範囲でフワッと紹介して終わります。

目的はterraformerで生成したmonitoring_alert_policy.tfファイルのdocumentationに、フィルター付きでCloud LoggingのWeb画面に飛べるリンクを追加することでした。
そのフィルターの内容はlogging_metric.tfファイルに定義されているものを使います。

  • monitoring_alert_policy.tf(のサンプル)
resource "google_monitoring_alert_policy" "alert_policy_error" {
  display_name = "My Alert Policy(Error)"
  combiner     = "OR"
  conditions {
    display_name = "test condition"
    condition_threshold {
      filter     = "resource.type=gae_app AND metric.type=logging.googleapis.com/user/my-error-metric"
      duration   = "60s"
      comparison = "COMPARISON_GT"
      aggregations {
        alignment_period   = "60s"
        per_series_aligner = "ALIGN_RATE"
      }
      threshold_value = 0.1
      trigger {
        count = 1
      }
    }
  }

  documentation = {
    mime_type = "text/markdown"
    # TODO: ここに↓の形式でリンクを入れたい
    # - [NAME](https://console.cloud.google.com/logs/query?project=PROJECT_ID&query=FILTER)
    content = ""
  }
}
  • logging_metric.tf(のサンプル)
resource "google_logging_metric" "logging_metric_error" {
  name   = "my-error-metric"
  filter = "resource.type=gae_app AND severity>=ERROR"
  metric_descriptor {
    metric_kind = "DELTA"
    value_type  = "INT64"
  }
}

手順:

  1. :grepする
  2. :copenして、不要な行があれば除外する
  3. マクロを記録開始して、
    1. getline()substitute()で検索するmetricの名前を抽出する
    2. logging_metric.tfのバッファに移動する
    3. search()getline()substitute()を使ってfilterを取得する
    4. 元バッファに戻る
    5. documentationのcontentがある行に移動する
    6. リンクを生成して追加する
      • conditionsが複数ある場合はそれぞれのリンクを追加する
      • フィルターはbase64化してクエリパラメータにする必要がある
    7. :wで保存する
    8. :cnextする
  4. マクロの記録を終了する
  5. 1000回ほど繰り返す

実は初めの数回は関数などを使用せず、ノーマルモードコマンドで普通に編集をしていました。
ただ同じような操作を繰り返していることは薄々感じていたのと、残りの件数を見て即マクロに切り替えたという経緯があります。
そのまま続けていたら数時間はかかっていたと思いますが、ほぼ一瞬で終わらせることができました。

明日は@kaneshinさんです。