GitHub Flavored Markdown をもっと Vim でハイライトする vim-gfm-syntax つくった
Vim にはデフォルトで Markdown のドキュメントをハイライトするためのファイルが同梱されています.基本的にはこれで満足なのですが,僕が書くのはほぼ GitHub Flavored Markdown(GFM: GitHub で使える拡張された Markdown 記法)なので,一部ハイライトされない構文があります.
そこで,既存のハイライトに GFM 向けのハイライトを追加する vim-gfm-syntax という Vim プラグインをつくりました.インストールは一般的な他のプラグインと同じです.ハイライトを追加するだけなので,設定済みの markdown
ファイルタイプの設定を壊すことは無いはずです.
入れる前 | 入れた後 |
---|---|
このプラグインを入れると,デフォルトで markdown
ファイルタイプのファイルを読んだ時に次のハイライトが追加されます.
- テーブル記法
- 絵文字記法 (e.g.
:dog:
) - タスクリスト記法 (e.g.
- [x]
) - 打ち消し線記法 (e.g.
~~取り消された文~~
) - issue 番号記法 (e.g.
#123
) - メンション記法 (e.g.
@rhysd
) - インラインコード記法(コードブロック記法を含まない) (e.g.
code
)
1〜6 は GFM 特有の記法で,デフォルトでは全くハイライトされないものです.7 を入れた理由は後の方で説明します.
デフォルトですべてのハイライトが常に有効になるようになっていますが,挙動をある程度制御できるようにいくつかのカスタマイズ方法を提供しています.
ほしい構文だけハイライトする
vim-gfm-syntax では上記のうちほしいものだけをハイライトできます. g:gfm_syntax_highlight_
で始まる変数でそれぞれの構文をハイライトするかどうかを決められます.(詳細は README をご覧ください)
特定の場合だけハイライトしてほしい
commonmark などの普通の(?) Markdown 記法を使う時は上記ハイライトをしてほしくない場合もあると思います.なので,特定のファイルタイプだけハイライトを追加するようにカスタマイズできるようになっています.例えば下記は markdown.gfm
というサブファイルタイプをつくって,特定のファイルでのみ追加のファイルタイプを有効にするようにしています.markdown.gfm
は markdown
のサブファイルタイプなので markdown
の設定も読み込まれます.
" デフォルトでハイライトしない let g:gfm_syntax_enable = 0 " filetype が 'markdown.gfm' のときだけハイライトを追加する let g:gfm_syntax_enable_filetypes = ['markdown.gfm'] " 'README.md' というファイルを編集する時は filetype を markdown.gfm にして GFM ハイライトを有効にする autocmd BufRead,BufNew,BufNewFile README.md setlocal ft=markdown.gfm
ハイライトの色を変えたい
ハイライトの色合いは使っているカラースキームで決まるため,このプラグインが設定しているデフォルトの色合いがベストとは限りません.そのため,ColorScheme
autocmd イベントでハイライト色を上書きできるようになっています.
例えば下記は githubFlavoredMarkdownCode
(インラインコード記法のハイライト定義)を CursorLine
と同じになるように上書きしています.
autocmd ColorScheme * highlight link githubFlavoredMarkdownCode CursorLine
CursorLine
は一例で,:hi
コマンドでハイライト一覧を見て選ぶことができます.また,githubFlavoredMarkdown
で始まる各種コードハイライト名は コード を直接参照してください.
コードブロックのシンタックスハイライト
標準の Markdown ハイライトが対応済みです.
let g:markdown_fenced_languages = ['cpp', 'ruby', 'json']
のようにすると C++,Ruby,JSON のコードブロックがそれぞれの言語の構文でハイライトされます.ただし,数を増やしすぎると Markdown ハイライトの読み込みが重くなってしまうので注意です.
インラインコードのハイライト
Vim の標準の構文ハイライトでは,コード記法は ` のみがハイライトされ,その中身が表示されません.そのため,インラインコードを多用するライブラリのドキュメントではインラインコードの範囲が分かりにくくなります.実は標準のハイライトではデフォルトのハイライトが設定されていないだけで下記のように markdownCode
ハイライトを定義してやると色をつけてくれます.
autocmd ColorScheme * highlight link markdownCode Constant
にも関わらず冒頭の 7. を追加したのは,markdownCode
だと ``` で始まるコードブロックも一緒にハイライトされてしまうためです.ここは好みですが,文中のインラインコードだけハイライトしてほしい場合はこれではできないため,今回は githubFlavoredMarkdownCode
を新たに追加しました.
Well-tested
themis.vim を使って各種ハイライトやカスタマイズ機能をテストしています.また,Travis CI も利用しています.
ErgoDox EZ を使い始めて1ヶ月ぐらい経った
タイムラインで購入している人がちらほらいて,評判も良好みたいなので ErgoDox EZ というキーボードを試しに買ってみることにしました.購入したのは無刻印+アームレスト付きの赤軸です.
(画像は公式サイトから)
とりあえず購入して1ヶ月経ち,そこそこ慣れてきて違和感なく打てるようになってきたので,この辺りで備忘録がてらまとめてみることにしました.
購入
他の人のブログを読んでいると手続きして2週間以上かかったりしていたので,お盆明けぐらいに届けば良いかなーという気持ちで7月22日に購入手続きをしました.しかし実際は台湾からの発送で1週間で届きました.8月頭に1週間サンフランシスコ出張があったので受け取れなかったら返送されてしまうとヒヤヒヤしましたが何とか直前に受け取れました.
セットアップ
出張前にとりあえずセットアップだけしました.と言っても箱から出して高さを調節して設置してみて,ファームウェアのビルドができることを確認しただけです.
この記事がとても参考になりました.コマンドラインから make
一発でビルドしてファームをキーボードのマイコンに焼きこむところまで出来るのでかなり楽です.
ErgoDox のキーボードファームウェアはオープンソースで開発されているので,リポジトリ を手元に clone してきて必要なクロスビルド用のライブラリを Homebrew で入れるだけで OK です.
他の人のブログ記事を読んでいると qmk_firmware
リポジトリを fork して自分の設定を足している人が多いですが,僕は設定ファイルは極力 dotfiles に置きたいので,clone してきたリポジトリ内に ergodox/keymaps/rhysd
をつくってその中に dotfiles からシンボリックリンクを張りました.この辺は何でも良さそうですが.
なお,デフォルトだと PC がスリープ状態になったときに LED が光って邪魔だったのですが,Makefile 読んでみるとビルド時に指定することでオフにできました.
$ make teensy KEYMAP=rhysd SLEEP_LED_ENABLE=no
キー配置を考える
キーマップいじくるのは好きなのでお盆休みあたりに少し色々試してみました.キーマップは C 言語のプリプロセッサマクロで簡単に定義できます.最終的なキー配置はこんな感じ.(設定ファイル)
- 左側
,---------------------------------------------------. | ESC | 1 | 2 | 3 | 4 | 5 | 6 | |--------+------+------+------+-------+-------------| | Tab | Q | W | E | R | T | { | |--------+------+------+------+-------+------| | | LCtrl | A | S | D | F | G |------| |--------+------+------+------+-------+------| } | | LShift | Z | X | C | V | B | | `--------+------+------+------+-------+-------------' |C-Left| | | LAlt |LG/Eisu| `-----------------------------------' ,--------------. |LGuiEnt| | ,------|-------|------| | | | Home | |Ctrl/ |TapL1/ |------| |Space |Tab | End | `---------------------'
- 右側
,----------------------------------------------------. | | 7 | 8 | 9 | 0 | - | = | |------+------+-------+------+------+------+---------| | _ | Y | U | I | O | P | \ | | |------+-------+------+------+------+---------| |------| H | J | K | L | ; | '" | | = |------+-------+------+------+------+---------| | | N | M | , | . | / | ` | `-------------+-------+------+------+------+---------' |RG/Kana| RAlt | [ | ] |C-Right| `------------------------------------' ,---------------. |AltTab|LGuiSpc | |------+--------+--------. | PgUp | | | |------|BackSpc |RShift/ | | PgDn | |Enter | `------------------------'
基本的には英字配列からあまり外れないように
慣れるのが大変そうなので,基本的な配置はなるべく US からあまり外れないようにしました.例えば左端の Ctrl や Shift などのキーは残す,以前のキーボードで左手で押していた 6 キーは引き続き左手で押せるように移動する(デフォルトでは右手で押すようになってた)など.
ただし,ErgoDox のキーボードの列数は HHK のそれよりも少ないため,どうしても足りなくなります(特に右端の記号列).これはどうしようもないので,あぶれた [ と ] は最下段へ… これはちょっと押しにくいのでもう少し考えたいところです.今までのキーボードは小指の守備範囲が広くて,記号を多用するプログラミングでは結構つらかったので,それが解消されるならお釣りがくるかなという感じです.
単押し,複数押し
ErgoDox ではモディファイアキー(他のキーと一緒に押す Ctrl などのキー)の挙動をかなり細かく指定することができます.例えばキー単体を押した時は半角スペースを入力し,他のキーと一緒に押した時は Ctrl として働くといったことができます.また,Ctrl を押した次のキー入力が Ctrl と一緒に押した扱いになるワンショットなどの挙動も指定できます.
親指にたくさんキーを割り当てられるので,ここはしっかり活用したくて特に左右に2つずつある大きい親指キーには単押しと複数押しにそれぞれ割り当てています.
,---------------. ,---------------. |LGuiEnt|LGuiSpc| |AltTab|LGuiSpc | ,------|-------|-------| |------+--------+--------. | | | Home | | PgUp | | | |Ctrl/ |TapL1/ |-------| |------|BackSpc |RShift/ | |Space |Tab | End | | PgDn | |Enter | `----------------------' `------------------------'
- 左手親指
- 単押しはスペースキー,他のキーと同時押しで Ctrl キー
- 単押しはタブキー,他のキーと同時押しでレイヤー2(後述)のキー配置
- 右手親指
- 単押しは Enter キー,他のキーと同時押しで Shift キー
- バックスペースキー
これだとキー長押しのキーリピートができなくなるのではと思われるかもしれませんが,同じキー2連打以降の長押しはキーリピートとして扱われる仕様のため問題ありませんでした.
ちなみに親指向けにはさらにキーが配置できるようになっていますが,一番外側の縦3つのキーはホームポジションから指が届かないのでほぼ使ってません.この辺は外国人サイズなのかも.さらに Vim 的には Esc キーが親指のほうが良いかなとも思ったのですが,普段 jj
で挿入モードから抜けるようにしているのと,Vim 以外ではほとんど使わないので Esc キーは普段の位置に収まりました.
英数キー,かなキー
僕は IME の状態を覚えておかないといけない 半角/全角 的なトグルキーが嫌で Mac の JP 配列のような英数キーやかなキーを使っています.HHK ではその挙動にするために Karabinar のお世話になっていたのですが,今回はファームウェアのキーマップ書き換えで出来そうなのでやってみました.
最初調べて出てきた情報によるとパッチを当てないとだめとのことでしたが,該当箇所を確認したところ既に修正された跡がありました.issue を漁ってみると下記を見つけました🙏.
Can't use KC_LANG1 & KC_LANG2 key
どうやら既に LANG1
がかなキー, LANG2
が英数キーとして使えるようなのでそのまま使ってみるとちゃんと動きました.Karabinar で設定していたのと同じように,単押しで IM 切り替え,他のキーと同時押しで Cmd キーになるようにしました.
Alfred や iTerm2 に1キーでアクセス
僕は普段ターミナルで作業するので,Cmd+Enter で iTerm2 を全画面トグルで使えるようにしています.また,Alfred もよく使うので,Cmd+Space にホットキーを設定しています.
ErgoDox ではこれらのホットキーを1ボタンに割り当てています.左親指キーの LGuiEnt
というのがターミナルのトグルで,右親指キーの LGuiSpc
というのが Alfred のホットキーです.頻繁に使うアプリのホットキーが1キーになることで思ったより楽になりました.
また,左右のワークスペースへの切り替えも最下段の一番端のキーのみで行えるようにしました(C-Left
と C-Right
がそれです).元々 Karabinar に頼って Ctrl + 左Cmd/右Cmd で切り替えというかなり変わったキー配置をしていたのですが,それが1キーで出来るようになりました.
キー配置レイヤー
ErgoDox ではキー配置にレイヤーを持たせることができ,Vim のモードのように複数のキー配置を切り替えることができます.レイヤーは3つ設定できます(デフォルトのレイヤーが L0 なので残りの L1 と L2).各レイヤーには Vim のようにキー入力で遷移したり,キーを押している間だけレイヤーを変えたり,キーを押した次の入力だけレイヤーを切り替える(ワンショット)といった好きな方法でアクセスできます.
僕はレイヤー3つは使いこなせる感じがしなかったので L1 だけ使い,F1〜F12 や方向キー&Home・Endキー,列が足りなくて再現できなかった右端の記号列のキー配置を設定したりしてますが,F1〜F12 と方向キーぐらいしかちゃんと使えていません.もっとレイヤーを使いこなしたい…
ErgoDox のキー配置(物理)について
ErgoDox は今まで僕が使ってきたキーボードとは違い,縦にまっすぐにキーが配置されています.そのため,以前のキーボードに慣れている指では最初誤入力が多発しました(特に C と V とか).これについてはキーボードに対する腕の向きが大事でした.一般的なキーボードは,キーボードに対して腕がハの字になるように設計されていると思います.それに対して ErgoDox では腕がキーボードに対して垂直になるように意識的に直してやる必要がありました.腕の向きを直すと大分誤爆が減りました.
また,ErgoDox に慣れると今までのキーボードが打てなくなるのではという懸念がありました.しかし今までは HappyHacking (US配列) を使っていて,職場では静音の Realforce (JP配列) を使っているので,新しい配列が加わったという感覚で,今までのキーボードが打てなくなるといったことは無さそうです.
打鍵感と音と振動
これらについては残念ながら以前の HHK のほうが遥かに良かったです.
打鍵感は HHK のほうがキーの押し込みがスムーズで押し心地が良いです.さすがに静電容量無接点方式にはメカニカルでは敵わないのかなという印象でした.
また,僕はキーの押下圧が強くて,HHK の時は特に気にならなかったのですが,ErgoDox では入力の振動が机に伝わってしまってモニターが少し揺れたりすることがあります.この辺りは良い机を買ったりすれば少しマシになるのかもしれませんが…
あと,音もちょっと気になりました.静音でない HHK Pro2 よりも大きいです.自宅では特に気になりませんが,職場でこの音は僕的にはちょっと…という感じです.
肩凝り
僕は昔から結構肩凝りがひどいのですが,それはかなりマシになりました.肩が開いて姿勢も良くなるので,そのおかげだと思います.日中ずっとキー入力していても肩がつらくなってきて中断といったことはほぼなくなりました.
まとめ
今の時点でもう ErgoDox のみでコードを書いたりツイートを書いたりしていて,特に困っていないです.前述のとおり肩凝りが解消されたのと,かなり小指の負担が減ったように思います.あと,キー配置やキーの挙動の自由度がかなり高いので,新しいキー設定を思いついたら即試せて今後も楽しめそうです.
僕自身はキーボードを組み立てる技術が無いので壊れた場合のサポートとかが少し不安ですが,その時は HHK にフォールバックして考えます.新しいおもちゃが手に入ったというのと,肩凝り解消などの実益で,僕にとってはなかなか良い買い物でした.
15K 行のアプリを TypeScript 1.8 から 2.0 に移行してみた
先日 TypeScript の新しいメジャーバージョン 2.0 のコンパイラの beta 版がリリースされました.
コンパイラのチェックの強化や非 null 型,tagged union など,いくつかの機能が追加・強化され,自分の趣味プロジェクトでも恩恵に与れそうだったので試しに移行してみました.
移行してみたのは下記の Electron でつくり中の Twitter Client アプリ(React+Redux)で,全体で大体 15000 行ぐらいです.
下記の手順で修正してみました.
- コンパイラをアップデートしてビルドしてみる
--noImplicitThis
,--noUnusedLocals
,--noUnusedParameters
を有効にしてみる--strictNullChecks
を有効にして nullability をチェックするようにするinclude
で glob を使う- Tagged union types で Redux の Action types をリファクタリングする
- 引数リストに trailling comma を入れていく
- インターフェースやクラスメンバを
readonly
指定する
各段階でビルド&単体テスト確認をするのが大事だと思うので,なるべく細かく段階を分けました.コミットも大体各作業ごとになっているので,随時 diff のリンクを貼ります.
「説明しなくて良いからコードを見せろ」という猛者向けに,下記が今回行った作業の全 diff です.+-1000行弱ぐらいですね.
コンパイラをアップデートしてビルドしてみる
TypeScript 2.0 beta は下記のコマンドで入るので,サッと入れてとりあえず npm run build
してみます.
$ npm install --save-dev typescript@beta
TypeScript 2.0 では処理フローを見て型を付けるようになったので,この時点でビルドが失敗することがあります. 例えば下記みたいな場合です.
type T = 'aaa' | 'bbb'; const v: T = 'aaa'; switch (v) { case 'aaa': /* ここでは v の型は 'aaa' */ console.log('OK'); break; case 'bbb': /* ここでは v の型は 'bbb' */ console.log('OK'); break; default: /* ここでは v の型は never */ console.log('NOT OK', v); break; }
このように,制御フローを見て適宜型を切り替えてくれるようになりました.
上記のように v
の型として取りうる可能性のある型がなくなると never
という型になり,v
を参照しようとするとエラーになります.
never type も 2.0 で導入された機能です.
基本的に煩雑さが減る方向のはずなので,修正は容易なはずです.
--noImplicitThis
,--noUnusedLocals
, --noUnusedParameters
を有効にしてみる
2.0 ではいくつかのチェック機能がコンパイラに追加されました.互換性が理由(?)でデフォルトはオフのようですが,特に理由が無ければ有効にしておいたほうが良さそうです.
tsconfig.json で "noImplicitThis": true, "noUnusedLocals": true, "noUnusedParameters": true
のように指定できます.
機能名の通り各チェックを行って,検知した時はコンパイルエラーに落としてくれます.特に noUnusedLocals
は tslint で検知してくれなかった未使用の import
を検出してくれて助かりました.
ここまではたとえ 2.0 にすぐに上げられないプロジェクトでも一時的にコンパイラのバージョンを上げてチェックさせることで恩恵に与れそうです.
--strictNullChecks
を有効にして nullability をチェックするようにする
2.0 では null
の型がそのまま null
となり,T | null
のように書くことで nullable な型を表現できます.また,undefined
についても同様に T | undefined
のように書けます.
さらに tsconfig.json に "strictNullChecks": true
を追加することで,デフォルトで全ての型を non nullable type として扱うようにできます.
基本的には
null
を代入しているのに nullable でない変数の型に| null
を追加するnull
が来る可能性があるのにチェックしていない箇所は素直にチェックする処理を入れる- 型は nullable だけど実質
null
な値が来ないところには null assertion 演算子(後置!
)を使う
という処理を入れていけば修正は OK です.3. は例えば下記のような感じです.
// 対象の要素が無い時 getElementById は null を返すので戻り値型は本来 // Element | null だが,静的に HTML に id が振られているので実質失敗しない // expr! で expr が null にならないとコンパイラに伝える const elem = document.getElementById('root')!;
また,null assertion 演算子は undefined
にも使えます.
変更箇所もなかなか多かったのですが,他にも細々とうまくいかないところがあり,この変更は思ったより大変でした.
例えば,strictNullChecks
によってオプショナル引数の型が以前と変わります.
function foo(optional?: number) { // 1.8 まで -> number // 2.0 から -> number | undefined optional; }
これだけ見ると問題ないように見えますが,型定義ファイルには,実質オプショナルでないのにオプショナル引数になっている定義が割といっぱいあります. 特にコールバックの引数の指定がまずいものが多く,1.8 までは型的には変わらなかったので問題にならなかったのですが 2.0 では問題になります.
今回例えば困ったのは react.d.ts
の StatelessComponent
です.
interface StatelessComponent<Props> { (props?: Props, context?: any): ReactElement<any>; // ... その他雑多なプロパティ }
上記の props?
が問題です.
const MyComponent: React.StatelessComponent<Props> = props => ...;
今までは上記のようにコンポーネントの型を指定し,引数を推論させていてこれでうまくいっていました.ですが,引数は props?
となぜかオプショナルに定義されているため,
2.0 からは props
の型は Props | undefined
に推論され,props
が undefined
でないかどうかのチェックを入れる必要が出てきてしまいます.
(僕の知識が足りないだけで実は props?
や context?
が実際に undefined
になるようなケースがひょっとしたらあるのかもしれないですが…もしそうなら教えていただけるとうれしいです)
仕方がないので下記のようにしてワークアラウンドを入れています.
const MyComponent = (props: Props) => ...;
これだと引数の型はプログラマが指定したものになるので undefined
チェックを回避できます.現状ではこれで問題になっていませんが,上記型定義の「その他雑多なプロパティ」がほしくなった場合は困ることになります.
また,react-redux.d.ts
の connect()
も困りました.connect()
は mapDispatchToProps
(第2引数)だけを指定したいときは第1引数を null
にできるのですが,第1引数の型定義に | null
が入っていないため
null
を渡せません.仕方ないので手元で react-redux.d.ts
に手を入れ,リポジトリに含めて typeings でインストールしたものの代わりにそちらを見るようにして凌いでいます.
型定義ファイルの更新状況などを見ながら,strictNullChecks
を付けるのは少し待ったほうが良いかもしれません.DefinitelyTyped では今のところ TypeScript 2.0 向けの型定義ファイルの開発を types-2.0 ブランチで進めているようです.
include
で glob を使う
TypeScript のプロジェクトファイル tsconfig.json で指定するソースコード一覧には今まで glob が使えなかったためファイルを1つずつ追加していました.
2.0 からは晴れて *
や **
が使えるようになったのでそれを使うようにします.
**/*.ts
や **/*.tsx
,typings/*.d.ts
のように指定すれば良くなりました.
Tagged union types で Redux の Action types をリファクタリングする
2.0 では tagged union types という機能が入り,union types のどの型の値が入っているのかを,各型に共通のプロパティで判断してくれます. プロパティには string literal type を指定すれば良いようです.公式の What's New に載っている例が分かりやすいです.
flux や redux では type
プロパティを見てアクションの種類を判断するため,アクションの型を tagged union type にすることでうまく型がつくようになります.
/* * action_type.ts */ // 'type' プロパティがタグになる type Action = { type: 'AddSomething', item: Something, } | { type: 'Sort', kind: Kind, } | { type: 'DeleteLast', }; export default Action; /* * actions.ts */ import Action from './action_type'; export function addSomething(item: SomeThing): Action { return { type: 'AddSomething', item, }; } export function sort(kind: Kind): Action { return { type: 'Sort', kind, }; } export function deleteLast(): Action { return { type: 'DeleteLast', }; } /* * reducer.ts */ import Action from './action_type'; function reduce(state: State = DefaultState, action: Action) { switch (action.type) { case 'AddSomething': // ここでは action の型は {type: 'AddSomething', item: Something} になる const next = ...; return next; case 'Sort': // ここでは action の型は {type: 'Sort', kind: Kind} になる const next = ...; return next; case 'DeleteLast': // ここでは action の型は {type: 'DeleteLast'} になる const next = ...; return next; default: return state; } }
大体こんな感じです.これで各アクションの処理内で間違ったプロパティにアクセスしていた時などは全てコンパイルエラーになります. 文字列リテラルが複数箇所にあるのが気になるかもしれませんが,全て string literal 型としてコンパイラがチェックするのでタイポしていてもコンパイルエラーになり安心です. 良い感じです.
ちなみに以前は type
プロパティが取る値を全部 Kind
というオブジェクトに入れて Kind.AddSomething
のように参照していたので,:%s/Kind\.\(\w\+\)/'\1'/g
のように置換して少しマクロを使ってやるだけで
かなり簡単に置き換えられました.Vim 便利.
引数リストに trailling comma を入れていく
個人的にかなり嬉しい機能なのですが,2.0 からは関数の引数に trailing comma が許されるようになりました(公式の例). (配列やオブジェクトの要素は前から trailing comma を許してます).
tslint がチェックしてくれるようになるのを待っても良いのですが,せっかくなので手で置き換えました.\h\w*\s*\(\n
あたりで適当に grep で引っ掛けて修正します.
Vim なら一度行末にコンマを追加する修正を入れれば,他の箇所は .
で繰り返すだけで OK ですね.Vim 便利.
インターフェースやクラスメンバを readonly
指定する
変更するつもりのないインターフェースのプロパティやクラスメンバに 2.0 から導入された readonly
指定をつけてまわります.基本的に大抵のプロパティは変更されないと思うので,デフォルトで readonly
付けるぐらいの勢いで良さそうです.:%s/^\s*\zs\ze\w\+?\=:/readonly /g
とかやると雑にプロパティに readonly
を付けられるので,付けてみてコンパイラに怒られたらそのフィールドを外す感じで機械的に作業できます.Vim 便利.
まとめ
最近ブログ書いてなかった(ネタはあったのに)ので,久々に人柱になった内容をまとめてみました.まだ beta ではありますが,今のところ変なバグは踏んでません.--strictNullChecks
以外はとりあえずやっておいて損は無さそうです.せっかくなので,いずれ 2.0 が正式リリースされた時に役立つと良いなぁと思っています.