Hatena::ブログ(Diary)

Memo

2017-01-02

[][] Python の Flake8 と Mypy のプラグイン作った

tl;dr

Flake8 と Mypy のチェックが動く Vim プラグイン作った。


Flake8 のプラグインは何個あるんだって感じだが、pyflakes-vim はとっくに deprecated だし、Python3 の type-hint な文法は解釈できないし、既存の Flake8 なプラグイン(Syntactic, neomake) は保存をしないとチェックが走らないし、Syntactic に至っては遅いし、khuno.vim は保存しなくてもリアルタイムにチェックしてくれるが、QuickFix 使わず独自のバッファでエラーリスト管理してるし、どれも気に入らないから結局自分で作った。

GitHub - heavenshell/vim-snowflake: An asynchronous Python source code checker for Vim.


特徴

例によって job と channel で動作している。

デフォルトは Flake8 だが、frostedpylama もパーサー書けば動く。

Flake8 は stdin から受け取るオプションがあるので、バッファをそのまま流し込んでるだけ。

そのため保存しなくてもチェックが走る。

InsertLeave や TextChange あたりに autocmd を設定すれば良い。

Python3 な venv で Flake8 を入れたら当然 type-hint なものもエラーではなくて、解釈してくれる。

MyPy

せっかく type-hint が正しく通るようになったから、型チェックもやらしたい。

現状 Mypy で Vim と言ったら @_achiku さんの以下のエントリにあるよう、Syntactic を使うしか無い模様。

syntasticとmypyでvimからPython型アノテーション確認


Mypy にはオプションに stdin はなく、Guido 御大も stdin オプションをつけたく無いと言われてるので、入ることはなさそう。

Feature request: checking files on stdin ? Issue #2119 ? python/mypy ? GitHub

その代わりに `--shadow-file` というドキュメントに書いてない隠しオプションあるから、そっち使ってねとある。

Feature request: checking files on stdin ? Issue #2119 ? python/mypy ? GitHub


`-shadow-file` の説明ソースコード内に書いてある。

mypy/main.py at master ? python/mypy ? GitHub

cp app.py tmp.py
mypy --incremental --silent-imports --show-column-numbers --shadow-file app.py tmp.py 

と動かすと、チェックされない。

mypy: error: Missing target module, package, files, or command.

正しく動かすには以下のようにする。

mypy --incremental --silent-imports --show-column-numbers --shadow-file app.py tmp.py app.py

チェックする対象のファイルが必要な模様。

app.py を指定してるんだからそれで良さそうなのに、コード読むと必要みたい。


tmp.py には Vimバッファの内容を読み取って、 `tempname()` でテンポラリにファイルを作成したやつを指定する。


これで type-hint な Python コードも静的チェックができるようになった。

アンドキュメントなやつだし、使えなくなる可能性高いけど便利。


実際に Flake8 と Mypy を同時に job を使いつつ TextChange イベントとかでフックすると重そうだけど、実際のプロダクト書くときに使ってみてドッグフーディングしてみる。


こういうツールを作ってる人にはエディタからの連携が楽になるので是非 stdin をサポートしてほしい。

2016-12-31

[] 2016 年振り返り

f:id:heavenshell:20161231170151p:image

かなり激しい一年だった。

デスマった。春先に倒れた

見事に 2 月から 4 月までコミットがない。

特に 4 月は体調が最悪だった。

3 月末に案件が終わってホッとしたところで見事に倒れた。

いのちたいせつに。

転職した

働き方を変えようと思ってたところにご縁があって声をかけてもらって、わがまま聞いてもらってフルリモートで働かせてもらってる。

今の所快適に働けている。

GitHub のプライベートリポジトリを使ってるので、草は増えた。

プライベートなコミットはほぼ Vimプラグインになってしまった。

理由があって、仕事で自分が楽したいためにプラグイン探す -> 気に入らない -> 作ってしまえという循環にはまったため。

特に Job, Channel, Timer あたりが出てきて非同期の恩恵に与ってないプラグインが多いので、そこの不満を自分で解消している感じ。


リモートワークしてる

リモートワークは最初はオン・オフの切り替えが難しかったけど、最近は割と出来るようになってきた。

ハイコンテキストな会話をされるとついていけないけど、そんなのは最初から覚悟しているし問題ない。

寂しくないの?と何度か聞かれたが、フルリモートワークしてる先人たちのように一緒に暮らしてる家族がいないので寂しいかなと思ったが、別にそんなこともない。

Slack に行けば会社の人がいるし。これが何か投げても何も返ってこないようなところだと辛そうだけど、幸いにしてそういうこともない。


諸事情があって 1 週間ほど家で働いてなかったけど、ネットさえ繋がっていれば仕事はできる。

そういう風に入る前に環境を整備してきた会社の人たちには感謝しかない。

社内サーバーがないというのは素晴らしい。


リモートワークするにあたって良い椅子(オカムラのバロン)と机(ビクターワークスタジオ)を買ったけど、買ってよかった。

特に椅子はお高いだけあって非常に快適。研究員時代の椅子と同じにしてよかった。

ワークスタジオは奥行きが 50cm にしたけど、60cm でもよかったかも。

もう少し広い部屋に引っ越したいなと思ったりもしないでもない。


フロントエンド

転職してフロントエンドの方を触る機会が多くなった。一から自分で調べるよりフロンエンドに詳しい人がいるのでかなり助かっている。

TypeScript は文法的に FlowType より好みだけど、2.0 までは外部ライブラリ使うのに型定義ファイル絶対必須なのは開発の速度が辛い。

2.1 になって緩くなったようだけどまだ追いついてない。

型定義も仕事で必要なので 3 つほど Pull Request した。

1 つは FlowType を使うことになったので、放ったままになってしまってる。なんとかせんと。

Django はじめた

一方でバックエンドは Django を使ってるので、Django はじめた。

はじめてまともに触ったけど、諸々揃っていて楽。

こちらも精鋭が揃ってるので、すごく楽させてもらってる。


Django ならこうやって書くというのをレビューで指摘もらえるのは本当にありがたい。

SQLAlchemy 大好きなので、まだ ORM は慣れてないけど、そのうち慣れると思う。

まとめ

健康に気をつけたい。

2016-12-22

[] FlowType のプラグイン作った

この記事は Vim アドベントカレンダー 2016 の23日目の記事です。

id:yuttie さんの comfortable-motion.vim よさそうなので入れてみたが自分の MacVim な環境では "E118: 関数引数が多過ぎます: <SNR>128_tick" が出たので追いかけようと思います。

…と思ったけど、修正版が上がってたのでしばらく使ってみよう。

慣性スクロール素敵。


TL;DR


はじまり

Facebook の FlowType ようの Vim プラグインは有る。

GitHub - flowtype/vim-flow: A vim plugin for Flow

諸々挙動が気に入らなくて、最初 PR しようかと思ったが、ローカルの npm のモジュールを使う Pull Request が放置されたり、PR の敷居が高そうだし、直すなら全部書き換えくらいな雰囲気なコードなので自分専用で作った。

GitHub - heavenshell/vim-flood: A simple Vim plugin for facebook flow


どうせなら、job と channel 使って非同期で色々やりたかった。

型チェックのエラー表示は QuickFix に非同期で出す、補完も非同期でやる方法を知りたかった。

# ちなみに Flow は割と速いので同期と非同期の差はほとんど無い


今現在 Flow が持つ機能全て実装してある。

TypeScript には GitHub - Quramy/tsuquyomi: A Vim plugin for TypeScript という素晴らしい IDE があるが、これには及ばない。

エディタ機能については Language Service がある TypeScript が勝ってる。

非同期の補完

同期の補完を作るのは omnifunc を使ってやればいい。簡単。

非同期の場合は、どうやったらいいのか最初分からなかったが、miyakogi さんの asyncjedi に答えがあった。

<c-x><c-o> を独自の補完関数マッピングしてやり、補完候補のリストを作り、complete() に渡せば良い。


complete() の微妙な挙動

一通り機能を実装し終わった後に実際に使っていると、補完候補が 1 件の場合の動作が混乱した。

complete() は補完候補を作るが、completeopt で menu かつ noinsert や noselect を指定している場合の挙動がわかりづらかった。


noselect や noinsert は補完候補が沢山ある場合は、候補のみを表示して、実際には補完せずユーザーに選ばせる。

menu は補完候補が 1 件の場合はそれが挿入される。

また普通の omnifunc の場合補完時はエコーエリアに何が起きているかを表示してくれるが、complete() はしない。


つまり補完候補が 1 件の場合、何も表示されず補完候補が何もないように錯覚する。

# 指摘されて気づいたが completeopt=menuone,noselect とかのように menuone の場合は起きない


なんか分かり辛いなーと思い、この挙動を自分で変えられないかと思った。

Vim のコードを読む。

とりあえず vim のコードを clone して src の下で grep する。

キーワード的に noinsert とか noselect あたりを使うと、edit.c に当たる。

edit.c を読んでいくと、set_completion という関数に当たる。


complete() 時noselect や noinsert が何をやっているかというと、補完時に completeopt にそれらがあれば、KEY_DOWN と KEY_UP のイベントを中で呼び、補完候補の選択位置を変えてる。

vim/edit.c at master ? vim/vim ? GitHub


そのため completeopt=menu,noselect,noinsert の場合は、補完候補の位置が隠れている状態になる。


ということは補完候補が 1 つなら completeopt=menu と同じ挙動にすれば良いと思う。

本来なら complete() 時もメッセージ出してやればいいのだろうけど、いじる箇所が多くて大変そうなので、簡単な方法から試してみる。


変更を入れる場所がわかったので、あとは補完候補の数を調べれば良い。

compl_length というそれっぽい変数があったので、これかと思い、条件文を加えて、ビルドして Vim を動かしてみたが、うまく動かなかった。


やむをえないので gdb を使う。

ついでに Mac より Linuxデバッグした方がやりやすいので、VMUbuntu を立ち上げ、Vimデバッグオプション付きでビルドする。

出来上がったバイナリgdb 経由で起動し、set_completion にブレークポイントを張る。


簡単に再現するように以下のような Vim scriptでっち上げる。

set completeopt=menu,noselect
inoremap <F5> <C-R>=ListMonths()<CR>

func! ListMonths()
  call complete(col('.'), ['January'])
  return ''
endfunc

inoremap <F6> <C-R>=ListMonths2()<CR>

func! ListMonths2()
  call complete(col('.'), ['January', 'Feb'])
  return ''
endfunc

F5 や F6 を押せば自動的に gdbブレークポイントを張ったところで止まる。

で、compl_length の変数の中身を見たが違った。

どこかで補完候補を持ってるはずと、コードを眺めていたら、引数で list_T *list という引数がある。

この中を gdb で見ると、lv_len というものを持っており、これに補完候補数が格納されている。


というわけでこれを使えば良い。

noselect_patch.diff ? GitHub

できた。テストとかはまぁ後でいいやと思い、vim-jp にぶん投げて反応を見る。

補完候補が 1 つの際の noselect,noinsert の挙動 ? Issue #984 ? vim-jp/issues ? GitHub


で、menuone でええやんと教えてもらうが、menu の時の挙動がわかりづらいことを説明して、vim_dev に仕様変更としてどうよ?と投げてもらったが、既存補完系のプラグインの動き壊すと言われた。


まぁそうだよなーもっともだし、completeopt が menu,noselect,noinsert の時のみこの変更が動くようにすればいいのかなーと思ったが、completeopt=menuone,noselect,noinsert なら困らんしとモチベーションが若干落ちたので、放置したままになってしまった。

意欲が湧けばまた取り掛かる。


結論らしきもの

Vim のコードをいじるのは今でもハードルが高いが、コードを変更して、make すればいいだけなので、ここら辺は昨今のフロントエンドの開発や Golang の開発と変わらないなーということで、みんなもっと、パッチ書けばいいと思う。

2016-10-31

[] 型定義ファイルの管理方法

TypeScript を書いていて、型定義ファイルがライブラリリポジトリや DefinitelyTyped/DefinitelyTyped にある場合は、npm 経由でインストールしている。


型定義ファイルに漏れがあると、修正して Pull Request を送っている。また存在しない場合は、DefinitelyTyped/DefinitelyTyped に PR している。


ここで、作成してから取り込まれて、npm からインストールできるまでの微妙なタイムラグの間どうやって管理すればいいのか悩んでいる。

現状、DefinitelyTyped/DefinitelyTyped の types2.0 ブランチに PR していて、それが取り込まれていない。

[types-2.0] Add d3-hexbin by heavenshell ? Pull Request #12089 ? DefinitelyTyped/DefinitelyTyped ? GitHub


この取り込まれていないものを、取り込まれるまで使いたい。

とりあえず、現状は `types` というようなディレクトリを作り、その中に、モジュール名でディレクトリを作り、その中に型定義ファイルを入れている。


`types/d3-hexbin/index.d.ts` という風な形で、tsconfig.json の中で、 paths でモジュール名を解決するようにしている。


    "baseUrl": ".",
    "paths": {
      "d3-hexbin": ["types/d3-hexbin/index.d.ts"]
    }

これで、自分のローカルで npm でインストールしたのと同じように、モジュールとして使える。


ただし、これをプライベートのリポジトリに push しているので、その管理方法が手間。管理したくない。

typings はオワコンな雰囲気が出てきているので、使いたくない。

良い管理方法を知らないので、現状はローカルにキャッシュするたびに、何を管理していて、どこに手が入っているかを Issue として管理している。


何か良い方法はないものだろうか。

2016-09-27

[] eslint と tslint を Vim から

textlint.vim を流用。

GitHub - heavenshell/vim-eslint-config: Wrapper for ESLint [deprecated]

GitHub - heavenshell/vim-tslint-config: Wrapper for TSLint


作った理由は textlint.vim と全く同じ。

syntastic-local-eslint.vim とかは system() でパスを調べてるけど、node_modules の位置を見て、eslint, tslint を探す。

似たようなことをしてる人がいたけど、こちらも system() を使ってた。

vim で編集中のファイルを eslint する - Qiita

自分のは Watchdogs.vim とも連携してるので、WatchdogsRun とかすれば良い。

自分用。便利。

2016-08-31

[] 最近作った Vim plugin

textlint を今のプロジェクトでは使ってて、textlint を 開いているバッファから行いたい。


先人がすでにいるし、プラグインもある。


textlint の設定ファイルを npm で管理していて、そこから読み込むというのが二つともできない。

また textlint がグローバルに入っていて、node_modules から読み込むことができない。

なので、その両方をできる自分用のプラグインを作った。

GitHub - heavenshell/vim-textlint: Wrapper for textlint

let g:textlint_configs = [
  \ '@azu/textlint-config-readme',
  \ '@example/textlint-config-example',
  \ ]

こんな感じで設定ファイルを書き、`:Textlint` コマンドを実行するで、設定を行い、`:make` コマンドで実行する。

ただ、この `:make` コマンドを実行すると、バックグラウンドで実行してくれない(textlint は node.js でできているので Vim から使うには少し遅い)。

なので、watchdogs.vim とも連携できるようにした。

:Textlint -c @example/textlint-config-example
:WatchdogsRun

エラーがあった場合は、Quickfix が開いてくれるので便利。

2016-07-15

[] Vim-Pokemon 〜あなたが Vim で開いているファイルに潜んでいるポケモン〜

see Pokemon-Emacs 〜あなたが Emacs で開いているファイルに潜んでいるポケモン〜 - Thanks Driven Life

TL;DR

最近は Pokemon Go が流行っているようで、正式サービス開始を待ち望まれているようです。

『Pokemon GO』は、位置情報を活用することにより、現実世界そのものを舞台として、ポケモンを捕まえたり、交換したり、バトルしたりするといった体験をすることのできるゲームです。 このゲームはモニターの中だけで完結せず、プレイヤーは実際に家の外に出てポケモンを探したり、他のプレイヤーと出会ったりしながら楽しむことができます。

面白そうですね。海外でも既にユーザが爆発的に増えており、スマホ片手に街をうろうろする様子などを画像や動画でも目にします。

さて、日本は夏まっさかりであり、暑い日が続いています。そんな中

「私もポケモン探しにいきたいけどまだサービス開始してないし、 そもそも外に出たくない… 」

という Vimmer も多いと思います。

でもよく考えてみてください。ポケモンは何も外だけに居るわけじゃないんです。 昔はゲームボーイにいました。じゃあ Vim にも居るかもしれないですよね。

Vim-Pokemon とは

https://github.com/heavenshell/vim-pokemon

Vim のライブラリーの一つです。効果としては「今開いているファイル名の絶対パス(もしくはバッファー名)で一意に決まるポケモン名を表示する」だけです。

とりあえずいろいろがんばって .vimrc に設定してもらったあと

$ vim /path/to/俺のリポジトリ/github/vim/vim-pokemon/README.md

を実行すると、(おそらく)ファイル名の横あたりに、下図っぽい感じでポケモン名が表示されます。

この場合は ジュゴン が選ばれました。

つまり /path/to/俺のリポジトリ/github/vim/vim-pokemon/README.md にはジュゴンが潜んでいる。豆知識です。

ちなみに 無名バッファー にはフシギダネが居ます。多分。

実装についてちょっとだけ

特に難しいことはしてませんが

  • ファイル名、もしくはバッファ名を seed として乱数をゲット
    • なのでどの環境でもファイル名が同じ = 同じポケモンが出てくる。はず。
  • (もちろんポケモン一覧 s:monsters が変化したら変わりますが…)
    • ポケモン一覧から↑の乱数を index としてポケモンをゲット

これだけです。

少し前に Pokemon-Go におけるポケモン出現率*1 みたいな画像を見たので、出現率に併せて「出やすいポケモン」「出にくいポケモン」みたいな実装をしてたんですが、 あの画像自体デマだったみたいなコメントもあったので、まあいいかってことでとりあえず愚直にリストから取るようにしました。

あとはポケモン一覧はとりあえず初代の 151 匹*2をチョイスしました。他のシリーズ追加すれば勝手に出てくるとおもいます

まとめ

「/path/to/foo にピカチュウが潜んでいたぞ!!」 「ミュウが見つからねえ!!」

みたいな楽しみ方で、エディタ生活に華を添えてください。ポケモン大好き!!


蛇足

あとネタとしてパクらせてもらった、偉大な Emacs ハッカーの @gongoz さん大好き!