Vimのexecute()と組み合わせて便利なコマンド

この記事はVim Advent Calendar 2018の13日目の記事です。

先月に開催されたVimConf 2018で、Migrating plugins to standard featuresというタイトルで発表してコマンドの結果をバッファに表示する方法を紹介しました。
その中で解説しきれなかったテクニックとして、以下のようなコマンドを定義しておくとL <コマンド>*1のようにして簡単に任意のコマンドの結果をバッファに表示することが出来るようになります。

command! -bar ToScratch
      \ setlocal buftype=nofile bufhidden=hide noswapfile

command! -nargs=1 -complete=command L
      \ <mods> new | ToScratch |
      \ call setline(1, split(execute(<q-args>), '\n'))

当日はプラグイン一覧やMRUを表示する用途として、

• :scriptnames
• v:oldfiles(:oldfilesでも良い)

を紹介しましたが、簡単に使えるなら他にも便利なコマンドがあるんじゃないかと思って調べてみました。
なお、対象は:exusageから

• 引数不要
• ファイルタイプやカーソル位置、バッファの状態などに依存しない
• 結果が複数行になる

コマンドのみとしています。(収拾ががつかなくなりそうなので...)

定義系

各種定義を一覧表示するのは何かと便利そうです。
年末にvimrcを掃除する際などにも大活躍するんじゃないでしょうか?

• :augroup ... 自動コマンドのグループ
• :autocmd ... 自動コマンド
• :abbreviate ... 短縮入力
  • :noreabbrevや、先頭にc, iを付けても良い
• :command ... コマンド
• :function ... 関数
• :highlight ... ハイライト
  • :runtime syntax/hitest.vimだと実際にハイライトされる
• :let ... 変数
• :map ... マップ
  • :noremapや、先頭にc, i, l, n, o, s, t, v, xを付けても良い
• :menu ... メニュー
  • :noremenuや、先頭にa, c, i, n, o, s, tl, v, xを付けても良い

開いているもの

gfで開く用途には向きませんが、どちらも大量に開いている時はバッファに表示されると便利そうです。

• :buffers ... バッファ
  • または:files, :ls
• :tabs ... タブ

各種操作結果

こちらも大量に表示されるような状況では便利そうです。

• :registers ... レジスタ
  • または:display
• :marks ... マーク
• :messages ... メッセージ
• :history ... コマンド履歴

Vimの情報

Vim関連の様々な情報はバッファに表示して見たいというケースはあまりないかもしれません。
個人的には代替の手段の方が使い勝手が良いと思っています。

• :compiler ... コンパイラ用設定
• :digraphs ... ダイグラフ
  • :h digraph-tableの方が見やすいかもしれない
• :set ... 既定値と異なるオプション
  • :setglobalや:setlocalもある
  • :optionsでも良いかもしれない
• :version ... バージョン番号やその他の情報

デバッグ向け

Vim script開発者向け。

• :breaklist ... ブレークポイント

QuickFix

切り替える際に表示するだけならわざわざバッファに表示する必要はないかもしれません。

• :chistory ... grepやmakeなど、quickfixリストの履歴
  • locationリストの場合は:lhistory
• :clist ... quickfixリストの内容
  • locationリストの場合は:llist

移動系

こちらも一時的に表示するだけならバッファに表示する必要はなさそうです。
※実際に移動できるマッピングなどがあれば...*2

• :jumps ... ジャンプリスト
• :tags ... タグスタック
• :tselect ... タグ

その他

ということで最後はこちら。

• :smile ... 「ついに見つけたんだね、セイバー!」

                            oooo$$$$$$$$$$$$oooo
                        oo$$$$$$$$$$$$$$$$$$$$$$$$o
                     oo$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o         o$   $$ o$
     o $ oo        o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o       $$ $$ $$o$
  oo $ $ "$      o$$$$$$$$$    $$$$$$$$$$$$$    $$$$$$$$$o       $$$o$$o$
  "$$$$$$o$     o$$$$$$$$$      $$$$$$$$$$$      $$$$$$$$$$o    $$$$$$$$
    $$$$$$$    $$$$$$$$$$$      $$$$$$$$$$$      $$$$$$$$$$$$$$$$$$$$$$$
    $$$$$$$$$$$$$$$$$$$$$$$    $$$$$$$$$$$$$    $$$$$$$$$$$$$$  """$$$
     "$$$""""$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$     "$$$
      $$$   o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$     "$$$o
     o$$"   $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$       $$$o
     $$$    $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$" "$$$$$$ooooo$$$$o
    o$$$oooo$$$$$  $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$   o$$$$$$$$$$$$$$$$$
    $$$$$$$$"$$$$   $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$     $$$$""""""""
   """"       $$$$    "$$$$$$$$$$$$$$$$$$$$$$$$$$$$"      o$$$
              "$$$o     """$$$$$$$$$$$$$$$$$$"$$"         $$$
                $$$o          "$$""$$$$$$""""           o$$$
                 $$$$o                                o$$$"
                  "$$$$o      o$$$$$$o"$$$$o        o$$$$
                    "$$$$$oo     ""$$$$o$$$$$o   o$$$$""
                       ""$$$$$oooo  "$$$o$$$$$$$$$"""
                          ""$$$$$$$oo $$$$$$$$$$
                                  """"$$$$$$$$$$$
                                      $$$$$$$$$$$$
                                       $$$$$$$$$$"
                                        "$$$""""

*1:Listの略

*2:i.e. Unite

golang.tokyo 静的解析Dayでgolang.org/x/tools/go/analysisを使ってみた

golang.org/x/tools/go/analysis 面白そうだなー。 けど触る時間がなかなか取れないなー。 と思っていたらちょうどタイムリーなツイートがあり、

12/8とかにGoで静的解析を一緒にモクモクやるかいをどこかでやりたいけど、会場がないので、一緒にモクモクしてくれる人とどこか会場を探してます。

— tenntennʕ ◔ϖ◔ʔ ==Go＠Goが生きてる (@tenntenn) November 27, 2018

数時間後にこちらの開催が決まりました。

golangtokyo.connpass.com

ということでモクモクとgscでhonnef.co/go/tools/lintからgolang.org/x/tools/go/analysisへの置き換えをやってきました。

ちなみにgscはgolang.tokyo #14のLT*1で紹介した自作のlinterです。

変更点をざっくりまとめると、

• honnef.co/go/tools/lintではCheckerというinterfaceに実装をするが、golang.org/x/tools/go/analysisではAnalyzerというstructになる
• honnef.co/go/tools/lintではJobを受け取ってast.Inspectで処理をしていくが、golang.org/x/tools/go/analysisではPassを受け取ってInspector.Preorderで処理をしていく
  • AnalyzerのRequiresフィールドに必要な前処理を指定する
  • 次の処理に結果を渡すような作りにすることも可能
• コマンド本体はlintutil. ProcessFlagSetからmultichecker.Mainになる
  • ただしmainでflagを扱えなくなってしまう！
    • ツール全体でExitCodeを0にするといった制御が不可に...
    • なのでPassのReportフィールド(関数)を書き換えることで 無理矢理 実現した
• テストはhonnef.co/go/tools/lint/testutilがgolang.org/x/tools/go/analysis/analysistestになる
  • 使い方はだいたい同じ

といったところです。

統一的なインターフェースになって再利用しやすくなるのもメリットですが、処理速度も向上していて、 手元で3秒くらいかかっていたのが一瞬で終わるようになりました。

今日はまだgolang.org/x/tools/go/analysisを使いこなすところまではいけませんでしたが、とても有意義な時間を過ごせました。

便利なAnalyzerが増えるとみんな幸せになれるのでもっともっと使う人が増えていくと良いですね！

awesome analyzerを作るという気持ちを示した #golangtokyo

— tenntennʕ ◔ϖ◔ʔ ==Go＠Goが生きてる (@tenntenn) December 8, 2018

*1:https://daisuzu.github.io/golang-tokyo-14/

VimConf 2018に行ってきた

VimConf 2018に行ってきました。

今年は@mattn_jpさんだけじゃなく、Vim作者のBramさんも発表するという超豪華Keynoteでした。
また、今年は去年以上に国際色高まるカンファレンスだったんじゃないかなと思います。
運営のみなさま、とても大変だったと思いますがすごく楽しい1日を過ごすことができました。
本当にありがとうございます。

以下セッションの一言感想です。

What is the next feature? by Yasuhiro Matsumoto

vim-jpについてのエモい話。
自分もVimにパッチを送る時、vim-jpにはとてもお世話になりました。
それにしても(ある程度形になった)パッチを用意してプレゼンに臨むのは流石です。

Vim: From hjkl to a platform for plugins by Bram Moolenaar

Vimの新機能について作者本人から話が聴けるというすごく貴重な発表でした。
プラグイン管理やVimの表現力がさらに充実していきそうで今後がとても楽しみです。
もちろんVim scriptのパフォーマンス向上も!

Migrating plugins to standard features by daisuzu

自分の発表。
Shougo wareを標準機能で置き換える話をしてきました。

Modes by Tatsuhiro Ujihisa

:Termdebugを使ったモードの実装の解説。
前にMeguro.vimで:Termdebugを使っているところを見せてもらいましたが、とても便利そうでした。

A day in the life of (ordinary) Vimmer by OKURA Masafumi

Ordinary Vimmerは毎朝アップデートしますよね。
Learn once, use anywhere.
自分の発表で言いたかったことはこれです。

Modern editor-independent development environment for PHP by USAMI Kenta

普段はEmacsを使っていらっしゃる。
自分でHackできるツールが良いというのは完全に同意です。

Effective Modern Vim scripting by Alisue

Create your own plugin!
すごくわかります。
vital-Whiskyの中にあるRxがすごく気になりました。

Oni - The GUI-fication of Neovim by Akin

Electron(React + TypeScript)製のneovimクライアントの紹介。
バッファを分割してブラウザを開けるのはとても便利そうでした。

Vim ported to WebAssembly by rhysd

今日1番濃い発表だったんじゃないか...?
Vimの内部処理の解説がとても詳しくてすごく勉強になりました。
それにしても8日でやってしまうのが本当にすごい。

grpc-gatewayでProtocol Buffers over HTTP

grpc-gatewayを使うとgRPCサーバをRESTfulなインターフェースで叩けるようになります。
APIクライアントはswaggerから生成しても良いのですが、Goだとprotocで生成したstructをPOSTする方が依存も少なく、楽なこともあるでしょう。
ということで軽く試してみました。

Protocol Buffersのシリアライズ/デシリアライズ

まず、サーバがProtocol Buffersをやりとりできるようにしてあげないといけません。
そのための機能は全てgrpc-gatewayのruntimeパッケージにあるので、以下のようにしてServeMuxを初期化すればOKです。

mux := runtime.NewServeMux(
    runtime.WithMarshalerOption("application/octet-stream", new(runtime.ProtoMarshaller)),
)

APIクライアント

これでクライアントからapplication/octet-streamでProtocol Buffersを投げることができるようになりました。

func do(url string, in *pb.ExampleRequest) (*pb.ExampleResponse, error) {
    body := new(bytes.Buffer)
    if err := new(runtime.ProtoMarshaller).NewEncoder(body).Encode(in); err != nil {
        return nil, err
    }

    res, err := http.Post(url, "application/octet-stream", body)
    if err != nil {
        return nil, err
    }
    defer res.Body.Close()

    if res.StatusCode >= 400 {
        b, err := ioutil.ReadAll(res.Body)
        if err != nil {
            return nil, errors.New(res.Status)
        }
        return nil, fmt.Errorf("%s: %s", res.Status, b)
    }

    out := new(pb.ExampleResponse)
    if err := new(runtime.ProtoMarshaller).NewDecoder(res.Body).Decode(out); err != nil {
        return nil, err
    }
    return out, err
}

エラーの型を共通化する

このままでも普通に使う分には問題ありませんが、サーバがエラーレスポンスを返した際もBodyをstructにデコードできるとより嬉しいです。
現状だと、サーバ側のエラーレスポンスはデフォルトで以下のunexportedな型になっています。

type errorBody struct {
    Error   string     `protobuf:"bytes,1,name=error" json:"error"`
    // This is to make the error more compatible with users that expect errors to be Status objects:
    // https://github.com/grpc/grpc/blob/master/src/proto/grpc/status/status.proto
    // It should be the exact same message as the Error field.
    Message string     `protobuf:"bytes,1,name=message" json:"message"`
    Code    int32      `protobuf:"varint,2,name=code" json:"code"`
    Details []*any.Any `protobuf:"bytes,3,rep,name=details" json:"details,omitempty"`
}

// Make this also conform to proto.Message for builtin JSONPb Marshaler
func (e *errorBody) Reset()         { *e = errorBody{} }
func (e *errorBody) String() string { return proto.CompactTextString(e) }
func (*errorBody) ProtoMessage()    {}

そのため、クライアント側でデコードするためにはこちらをコピーして使うか、サーバ側で型を変更する必要があります。

エラーの型を変える場合はWithProtoErrorHandlerを使います。

mux := runtime.NewServeMux(
    runtime.WithMarshalerOption("application/octet-stream", new(runtime.ProtoMarshaller)),
    runtime.WithProtoErrorHandler(func(ctx context.Context, mux *runtime.ServeMux, marshaler runtime.Marshaler, w http.ResponseWriter, r *http.Request, err error) {
        w.Header().Set("Content-Type", marshaler.ContentType())

        s, ok := status.FromError(err)
        if !ok {
            s = status.New(codes.Unknown, err.Error())
        }

        buf, merr := marshaler.Marshal(s.Proto())
        if merr != nil {
            w.WriteHeader(http.StatusInternalServerError)
            io.WriteString(w, `{"error": "failed to marshal error message"}`)
            return
        }

        w.WriteHeader(runtime.HTTPStatusFromCode(s.Code()))
        w.Write(buf)
    }),
)

内容はDefaultHTTPErrorとほとんど同じですが、エラーの型をgoogle.golang.org/genproto/googleapis/rpc/status(*spb.Status)にしています。

こうすることで、クライアント側はgoogle.golang.org/genproto/googleapis/rpc/statusをspb*1としてimportし、proto.Unmarshalで*spb.Statusに戻せるようになります。

if res.StatusCode >= 400 {
    b, err := ioutil.ReadAll(res.Body)
    if err != nil {
        return nil, errors.New(res.Status)
    }

    v := new(spb.Status)
    if err := proto.Unmarshal(b, v); err != nil {
        return nil, fmt.Errorf("%s: %s", res.Status, b)
    }
    return nil, status.ErrorProto(v)
}

返ってきたエラーはstatus.FromErrorで*status.Statusにすると、CodeやMessage、Detailsが取り出せるので後続の処理で自由に使えます。

if s, ok := status.FromError(err); ok {
    log.Printf("code: %d, message: %s, details: %v", s.Code(), s.Message(), s.Proto().Details)
}

なお、Detailsは型情報が落ちてしまっているため、内容を正しく出力するにはptypes.UnmarshalAnyで元に戻してあげる必要があります。

例えばDetailsがerrdetails.BadRequestの場合だと以下のようなコードです。

if s, ok := status.FromError(err); ok {
    var details []string
    for _, d := range s.Proto().Details {
        var m errdetails.BadRequest
        if err := ptypes.UnmarshalAny(d, &m); err == nil {
            details = append(details, m.String())
        }
    }
    log.Printf("code: %d, message: %s, details: %v", s.Code(), s.Message(), details)
}

s.Details()だと[field_violations:<field:"data" description:"invalud" > ]、
s.Proto().Detailsだと[type_url:"type.googleapis.com/google.rpc.BadRequest" value:"\n\017\n\004data\022\007invalud" ]になってしまうのが、
ちゃんと[field_violations:<field:"data" description:"invalud" > ]になります。

*1:statusだと"google.golang.org/grpc/status"とかぶるため

Goの標準パッケージだけでRESTfulなHandlerを作る

Goのnet/httpパッケージだけではパスパラメータを扱うことができないため、/users/:id のようなエンドポイントを作ろうとしたら自分で処理を書かなければいけない。
適当なフレームワークや3rd-partyのパッケージを使えば簡単ではあるんだけど、時々標準パッケージだけで書きたくなってその度にどうやって書くんだっけ?となるのでblogに書いておく。

ポイントはHow to not use an http-router in goで紹介されているShiftPath。

func ShiftPath(p string) (head, tail string) {
    p = path.Clean("/" + p)
    i := strings.Index(p[1:], "/") + 1
    if i <= 0 {
        return p[1:], "/"
    }
    return p[1:i], p[i:]
}

これを使うことでパスの最上位とそれ以降がそれぞれhead、tailとして取得できるので、以下を繰り返しながらハンドリングしていく。

func (h *handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    var head string

    // それ以降のパスをr.URL.Pathに設定し、次のHandlerに渡す
    head, r.URL.Path = ShiftPath(r.URL.Path)

    // headを使って次のHandlerを決める
    switch head {
    case "users":
        h.users.ServeHTTP(w, r)
    default:
        http.NotFound(w, r)
    }
}

例えば次のエンドポイントを作るとしたらこんな感じ?

• POST /api/todos
• GET /api/todos/:id
• POST /api/users
• GET /api/users/:id

func ShiftPath(p string) (head, tail string) {
    p = path.Clean("/" + p)
    i := strings.Index(p[1:], "/") + 1
    if i <= 0 {
        return p[1:], "/"
    }
    return p[1:i], p[i:]
}

func NewHandler() http.Handler {
    return &rootHandler{
        api: &apiHandler{
            todos: &todosHandler{},
            users: &usersHandler{},
        },
    }
}

type rootHandler struct {
    api *apiHandler
}

func (h *rootHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    var head string
    head, r.URL.Path = ShiftPath(r.URL.Path)

    switch head {
    case "api":
        h.api.ServeHTTP(w, r)
    default:
        http.NotFound(w, r)
    }
}

type apiHandler struct {
    todos *todosHandler
    users *usersHandler
}

func (h *apiHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    var head string
    head, r.URL.Path = ShiftPath(r.URL.Path)

    switch head {
    case "todos":
        h.todos.ServeHTTP(w, r)
    case "users":
        h.users.ServeHTTP(w, r)
    default:
        http.NotFound(w, r)
    }
}

type todosHandler struct{}

func (h *todosHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    var head string
    head, r.URL.Path = ShiftPath(r.URL.Path)

    switch r.Method {
    case http.MethodPost:
        // Create Todo
    case http.MethodGet:
        // Get Todo
    default:
        http.Error(w, http.StatusText(http.StatusMethodNotAllowed), http.StatusMethodNotAllowed)
    }
}

type usersHandler struct{}

func (h *usersHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    var head string
    head, r.URL.Path = ShiftPath(r.URL.Path)

    switch r.Method {
    case http.MethodPost:
        // Create User
    case http.MethodGet:
        // Get User
    default:
        http.Error(w, http.StatusText(http.StatusMethodNotAllowed), http.StatusMethodNotAllowed)
    }
}

うん、まあ面倒。
ちなみにtodosHandlerやusersHandlerのServeHTTP以降の処理は、

1. h.handler(head).ServeHTTP(w, r)の形式で呼べるようにしても良いし、
2. h.create(w, r)やh.get(w, r, head)のようにしてしまっても良い。

※ただしheadをcontextに詰めて渡すのはダメ！

1の場合はh.handlerがhttp.HandlerFuncなど、ServeHTTPを実装した型を返すことになる。
もちろんstructを返しても構わないけど、How to correctly use context.Context in Go 1.7 – Jack Lindamood – Mediumにあるような割と複雑なコードになってしまうんじゃないかな。

力尽きたのでとりあえずこの辺で...

Google Codelabs の執筆者用ツールの使い方

今週の GCP 7/2 – google-cloud-jp – Mediumでclaat(Codelabs as a Thing)が紹介されていました。

github.com

これを使うとGoogle DocsやMarkdownからGoogle Codelabsのコンテンツを生成することができます。

Markdownでとりあえず試してみる

1. ツールをインストール

go get -u github.com/googlecodelabs/tools/claat
# またはリリースページからダウンロードする

2. 適当なファイルを作成

• index.md

# App Engine 入門 (Go)

## 概要

### 学習内容

* Google App Engine での単純な Go サーバーの作成方法。
* サーバーを停止せずにコードを更新する方法。

### 必要な環境

* Go
* Vim、Emacs、Nano などの標準 Linux テキスト エディタの熟知

## セットアップと要件

3. htmlを生成

claat export index.md

4. サーバを起動

claat serve

でOKです。

Google Docsでちゃんと作る

正式なフォーマットはGoogle Docsのようなので以下を参考にフォーマットや例を入手して書いていきます。

• Can I use this to create my own codelabs and serve my own codelabs online?
• Ok, how do I use it?

生成したコンテンツはpython3 -m http.serverやGitHub Pagesなどで配信することもできますが、本家に載せることも可能です。

• App Engine 入門 (Go)

手順は Can I publish my codelab on the official Google Codelabs site? にあるので興味がある人は是非やってみてください。

そして日本語版は数が少ないので英語版からの翻訳があると初学者はとても助かります。

codelabs.developers.google.com

リポジトリごとにGOPATHを切る環境でのvim-go

↓のようなリポジトリごとにその直下をGOPATHにする環境でGoを書く時、

.
├── github.com/daisuzu/bar
│     ├── bin
│     ├── pkg
│     └── src
│         └── bar
│              └── main.go
└── github.com/daisuzu/foo
       ├── bin
       ├── pkg
       └── src
           └── foo
                └── main.go

両方のリポジトリのファイルを同時に開いて行ったり来たりするのを少し楽にするためにvim-goの設定を切り替える関数を作ることにした。

function! SwitchRepo()
  let toplevel = trim(system('git rev-parse --show-toplevel'))
  if toplevel =~# '^fatal'
    return
  endif

  " GOPATHをリポジトリ直下に変更する
  execute 'GoPath ' . toplevel

  " リポジトリ名をgoimportsの'-local'フラグに渡す
  let g:go_fmt_options = { 'goimports': '-local ' . fnamemodify(toplevel, ':t') }
endfunction

*1

これで他のリポジトリのファイルを開いたらcdした後にcall SwitchRepo()すれば:GoDefでちゃんと飛べるし、
:GoImportsした時もサブパッケージを標準パッケージとは異なるグループにしてくれる。

• Before

import (
    "bar/handler"
    "bar/model"
    "fmt"
)

• After

import (
    "fmt"

    "bar/handler"
    "bar/model"
)

autocmdを組み合わせればもっと便利になるかもしれないけど、今のところは必要ない。

*1:普段はg:go_fmt_optionsを使っていないので都度上書き