Big Sky

ひさびさ Vim のエントリを書く気がします。

今から4年ほど前、Vim にスレッドセーフなメッセージキューが欲しいというメールが vim-dev 届きます。

[PATCH] Proof of concept: thread-safe message queue
https://groups.google.com/forum/#!searchin/vim_dev/tarruda%7Csort:relevance/vim_dev/65jjGqS1_VQ/fFiFrrIBwNAJ

その時はまだ、vim-dev の中にも「Vim はエディタだし必要ない」といった空気があったと思います。

[PATCH] Non-blocking job control for vimscript
https://groups.google.com/forum/#!searchin/vim_dev/tarruda%7Csort:relevance/vim_dev/QF7Bzh1YABU/02-YGr7_sCwJ

そしてその数か月後、もう一つのメールが届きます。ノンブロッキングでプロセスを制御する為のパッチです。

このパッチに関して vim-dev は特に反対意見を持っていませんでした。しかし Bram から反応が得られませんでした。昔から vim-dev を知っている人であれば分かると思うのですが、Bram はまずこういった機能追加の要望があった際にはまず皆の反応を確かめます。盛り上がったら取り込むし、盛り上がらなかったらボツという事です。僕も、大昔にソケット通信のパッチを送ってボツにされた事もありますし、mruby を組み込むパッチを送って誰からも相手されなかった事があります。

その反応が気に入らないという人もいました。この2つのメールを送ってきた人、その人もそうでした。そう、この2つのメールを送ってきた人こそが後に Neovim を作る事になった人です。Neovim は Vim のコードをベースに色々な機能を盛り込み、Vim と差別化する事で資金を調達しました。その中でも特徴的だったのが端末機能です。Vim のウィンドウの一つに端末を割り当てられる事で Vim の中だけで色々なシェル操作を完結できるという、とてもキャッチ―な物でした。非同期通信やタイマーといった API は現在の Vim にも備わっています。Bram は元々 fork を参考にしないという頑固な人なので、同じ様な機能を実装するのに時間は掛かってしまったかもしれませんが、channel/job に関しては Neovim 以上の物が実装されています。しかしながらこの端末機能についてはサポートされてきませんでした。ところがつい先日の 7/3 突然 Bram が口を開きました。

Adding terminal emulator support in Vim
https://groups.google.com/forum/#!topic/vim_dev/Q9gUWGCeTXM

長い間、私は Vim の中で端末エミュレータを追加する事がはたして良いアイデアであるのか疑問を持ち続けてきました。 それは危険なことですし、規模も大きくなり、そしてメンテナンスの悪夢にもなり得ます。 しかしそれと同時に、これは非常に、非常に便利になり得ます。

私が今回これを望んだ理由は、ssh 接続で Vim をデバッグする為です。 私はローカルで程よい設定をしていますが、家にいない時はいつも苦しんでいます。 これらの多くの制限は、いつも私が家に帰りデバッグする時間を延期してしまいます。 これを提供するプラグインがありますが、Vim をデバッグするには端末で実行する必要があるのです。

そういって突然 terminal への興味を示しました。僕は以前、Qiita にこんな記事を書いた事がありました。

Vim のソースのいじり方(:terminal を作るまで) - Qiita

この記事は [Vim Advent Calendar 2016](http://qiita.com/advent-calendar/2016/vim)、18日目の記事です。 # はじめに ここ数年で、...

http://qiita.com/mattn/items/ee438479b09055a2f305

そこで作った物を Bram に見せたところ、面白いと興味を持ってくれました。しばらくして Vim のマスターブランチに :terminal の実装が入り始めます。しかし標準入出力を操作する dumb 端末でしかありませんでした。

これはいっちょやってやるかと、winpty を使って Windows で terminal を動かすパッチを送りつけました。

support :terminal on Windows by mattn · Pull Request #1854 · vim/vim · GitHub

diff --git a/src/terminal.c b/src/terminal.c index df40866ba..bc632e7cb 100644 --- a/src/terminal.c ...

https://github.com/vim/vim/pull/1854

7/19 日の事ですから、わずか3日前の事です。Bram もとても興味を持ってくれた様でした。それから Bram と僕でパッチを書き続け、先ほど入ったパッチでようやく一段落した様な気がします。

まさか4年前に、Vim が数年後にこんな事が出来る様になるなんって思っていませんでした。自分でパッチを書いておきながら少し感動してしまいました。右上のウィンドウでこのブログ記事を書き、右下のウィンドウで ssh ログインして UNIX 版の動作検証、左でツイッターのストリームをダラダラと流し続けている光景です。

ちなみに Windows での terminal は Neovim も実現できていません。

元々、コマンドプロンプトで生活しており、Vim を常駐しない派でしたので今後この端末機能を使うかどうかは正直分かりませんが、何か Vim の新しい時代が来た様な気がしており、久しぶりに書いて良かったなと思えるパッチでした。

まだもう少しバグがあるかもしれませんし、安定しないかもしれませんが、引き続き精力的に開発していく予定です。もちろん「vim-jp が Vim の新しい機能を作っていくんだ」という気持ちに変わりはありません。ぜひ新しく追加された端末機能を使ってみて下さい。

結構前から、そろそろ .NET Core を使ったお仕事とかやっていきたいなと思っていて、その際に Linux でちゃんと動くのかを確認しておきたかった。ただインターネットを見てもそれほど良い情報が見当たらず、これは誰も試してないのかもなと思い仕方がないので自分で作って体験してみる事にした。

GitHub - mattn/dotnet-blog

README.md dotnet-blog Markdown friendly blog engine inspired with Jekyll written in Microsoft .NET C...

https://github.com/mattn/dotnet-blog

Markdown で記事が書けて、Jekyll と同様に Liquid でテンプレート制御が行えて、さらに Git と連携するブログエンジンです。

ディレクトリ構成は Jekyll とほぼ同じで、_posts に 2017-07-13-タイトル.md の形式のファイルを置いたら勝手に _layouts の中のテンプレートが適用されてかっちょいいサイトで表示されるという物です。設定ファイルも _config.yml に書きます。

title: "塩梅ドットコム"
base-url: "http://mattn.apphb.com"
clone-url: https://github.com/mattn/dotnet-blog-posts.git


この clone-url に書かれたリポジトリから、_posts や _layouts および _site といったファイルを git pull してローカルに展開します。サンプルのリポジトリも置いておきました。

GitHub - mattn/dotnet-blog-posts

Dismiss Join GitHub today GitHub is home to over 20 million developers working together to host and ...

https://github.com/mattn/dotnet-blog-posts

一度デプロイ出来たら、あとはこちらのリポジトリを更新してサイトの /pull に POST を送ると更新されます。この仕組みはもしかするといずれ変更するかもしれません。

トップ画面や

記事もきちんと表示されます。

とまぁ、こんな感じのブログエンジンを書いてみた訳だけど、実は今回はあえて Vim を使わず全て Visual Studio Code だけで開発を行った。これは仕事で使っていくなら僕だけじゃなく IDE を使いたい人がどの程度苦労するかも把握しておきたかったから。Visual Studio Code の C# 開発環境は以前まではそこそこ酷くて、まともな開発なんて出来ないんじゃないのって思ってたけど今回の開発でそのイメージは一蹴された。あの小気味良い軽快な動作をするエディタの様な IDE 上で、dotnet の restore やブレイクポイントを貼ったデバッグ、入力補完などほぼ問題なく扱えた。

また Windows で開発すると同時に Linux でも動作検証を行った。今回使った DotLiquid や CommonMark などは netcoreapp1.1 (.NET Core 1.1 ターゲット) でも問題無く使えていたし、publish して IIS 上で動作する事も確認出来た。気を付けないといけないのは、パス周りは「必ず」Path.Combine などを使うという事くらいだった。当初は 2～3 日くらいでこの検証を行う予定だったが、ちょっといろいろと忙しく1週間程度掛かってしまった。けれど開発の手順に慣れれば数日でそこそこ品質の良いマルチプラットフォーム向けのウェブアプリケーションを開発する事も出来るという結論に至った。まだテストスイートやインフラ周りで問題が無いかちゃんと検証できてないのでいきなり仕事で使おうとは思ってないけど、そこそこ近い未来で使う時が来るんじゃないかと思った。

Visual Studio Code で ssh 先のファイルを編集するには、Remote VSCode を使います。

Remote VSCode - Visual Studio Marketplace

A package that implements the Textmate's 'rmate' feature for VSCode.

https://marketplace.visualstudio.com/items?itemName=rafaelmaiolla.remote-vscode

なかなか仕組みが面白かったので紹介したいと思います。Remote VSCode は、実際は Sublime TextTextmate の rmate というコマンドの派生版です。どうやって ssh 先のファイルを編集するかというと、勘の良い方であれば以下のコマンドを見れば理屈は分かるはず。 $ ssh -R 52698:127.0.0.1:52698 user@example.org rmate /path/to/the/file.txt


rmate は Remote VSCode と通信してファイルの中身をやり取りします。実際には ssh でログインした際のポートフォワード機能によりリモート側のポート 52698 番で受け待ちすると同時に rmate コマンドを起動、ローカルで Remote VSCode と通信します。

rmate のプロトコルは至って簡単で、最初にファイルセットを送ります。

open
display-name: file.txt
data-on-save: yes
re-activate: yes
token: xxxxxxxxxxxxxxxx
data: 14

This is a file
.


以降は Remote VSCode が保存する度に以下のメッセージを送ってきます。

save
token: xxxxxxxxxxxxxxxx
data: 16
This is the file

面白い事にこの rmate、なぜだか色んな言語で実装されている。

Ruby version: https://github.com/textmate/rmate
Bash version: https://github.com/aurora/rmate
Perl version: https://github.com/davidolrik/rmate-perl
Python version: https://github.com/sclukey/rmate-python
Nim version: https://github.com/aurora/rmate-nim
C version: https://github.com/hanklords/rmate.c
Node.js version: https://github.com/jrnewell/jmate

いや、そんなにいらんやろw と思いつつも golang 版が無かったので作った。おとなげない。

GitHub - mattn/gomate

README.md gomate Edit files from an ssh session in TextMate/VSCode Usage 1 gomate /path/to/the/file....

https://github.com/mattn/gomate

まぁ、ssh してリモートで vim 使えばいいじゃんって思うけど、どうしても Visual Studio Code じゃないと嫌やねんって人はどうぞ。