ぼちぼち散歩

VimConf 2017に参加してきた

VimConf 2017に参加してきました。各発表の内容や当日の様子などは多くの方が既に書いてらっしゃると思いますので、自分が感じたところだけ残しておきたいと思います。

所感

今回は、Vim以外エディタ枠が空いているかも?という風の噂を聞いて、Visual Studio Code + Vim plugin紹介ネタで登壇発表に応募していたのですが、残念ながら落選しておりました。しかし、箱を開けてみると、haya14busaさんの"Vim, Me and Community"にてVim以外のエディタへの言及があったり、mattn_jpさん、k_takataさん、kaoriyaさんによる"Talk Show"でもmattn_jpさんより新しい機能の発見の場としてVisual Studio Codeはおもしろい、という趣旨のお話もあったりと、言いたかったことはむしろより深い視点でカバー頂いて逆に興味深く聞くことができました。

また、Vim以外エディタ枠という観点では、t9mdさんの"vim-mode-plus: The most ambitious vim emulator in the world"では、昨年に引き続き素晴らしい取り組みとその紹介、デモが発表されており、まだ自分はこのレベルではないなとも思いました。

そのかわりと言っては何ですが、懇親会のLTにて元々話そうと思っていたことのダイジェスト版を話してきました。実際には、手持ちのMacBook Proと会場のプロジェクタを繋ぐことができず、資料なしの口頭のみの発表となってしまったのですが、それなりに笑いも取れて(?)、少しは会の盛り上がりに貢献できていると感じて貰えればなと思っています。ほんとは、こちらの資料VSCode上でReveal.jsを表示するプラグインで表示して、Visual Studio Code上でプレゼンしつつ、簡単なデモもできればなぁという感じでしたが、このあたりはまた別の機会に披露できればなと思います。

また、fatihさんの"The Past and Future of Vim-go"でGoのAST解析機能を使ったTextObjectの話があったり、Talk ShowではLanguage Server Protocolへの言及があったり、p_ck_さんの"The new syntax highlighter for Vim"ではRubyの構文解析機能を使ったハイライトの仕組みが提案されていたりと、プログラミング言語処理系の機能を活用したVim拡張の方向性が見えてきたのが、一番面白いなぁと思った部分です。個人的な観測範囲では、GoがAST解析機能を提供しているなど単なる言語処理系を超えたツール類の提供に熱心で、そこにVisual Studio CodeがLanguage Server Protocolを持ってエディタと処理系のつなぎの部分を提案してきており、このあたりの流れをVimに統合できれば、また一段とVimでのプログラミングが楽しくなるのではないかと楽しみになってきています。

最後に、これまでのVimConfも大変素晴らしかったのですが、今年はさらに各発表のレベルも高く、来年への期待が膨らむばかりです。発表された皆様、運営の皆様、本当にお疲れ様でした&ありがとうございました!!

スポンサーサイト

2017/11/07 02:16 | Vim | トラックバック(0) | コメント(0)

ページの先頭へ

VimConf 2016に参加してきた

5年もブログ書いてなかった。VimConf 2016に参加してきました。

各発表の雑な感想

内容や詳細は他の人のレポートなど見てもらうとして、個人的な感想を書き留めておきます。

Introduction to Vim 8.0

vim-jpの活動は本当に素晴らしく、以前に自分がTwitterで「これはバグかな?」という類の内容をつぶやいたところ、「既にパッチができているのでIssue登録してね」というリプライがあり、速攻で修正が本家に取り込まれました。

Vim 7.4の2300以上あるパッチのうちの一つがこれなわけで、つまり、バグっぽい挙動を呟くことでVim 8.0に超々微力ながら貢献できました。なので、皆さんも気軽にバグ報告していきましょう。以下のようなありがたいお言葉もありました。

あと、Vimは25周年なんだけど、何人かの人が「あ、Vimより年下だ!」というTweetをしていて、ジェネレーションギャップを感じました笑。

Vim as the MAIN text editor

VSCode + Vim ExtensionからVim本家に来た、という珍しい?パターンの紹介。世の中に新しいIDEやエディタが登場すると、どこからともなくVimmerが現れてVim風操作にする拡張が作成されるわけですが、それがVim本家への導線としても機能している点が新鮮でした。

Denite.nvim ~The next generation of unite~

最近のShougoさん作のプラグインがだいたいPython3ということで、自分が昔作っていたlingr.vimをちょっと思い出しました。

ただ、個人的には就職してからは開発環境やフレームワークを整えて他の多くの人に使ってもらうことが多く、そうなると必然的にVimではない普通のIDEで環境作る→勧めるためには自分も使い込み慣れる→同じことをもう一回Vimでやるのがだるい、ということで、Vimでガシガシ開発することが少なくなっています。なので、Vimはちょっとしたテキスト編集がメインの用途となり、むしろシンプルに保つ方が良いので、Shougoさんが作るような大型プラグインは使わなくなりつつあります。

Go、C、Pythonのためのdeoplete.nvimのソースの紹介と、Neovim専用にpure Goでvim-goをスクラッチした話

deopleteはPythonで補完ソースを増やせ、かつ、補完も非常に早いとのことで、機会があれば試してみたいです(上記のとおり、最近機会が減少傾向ですが…)。

エディタの壁を越えるGoの開発ツールの文化と作成法

Goは依存性なしの実行ファイルをクロスプラットフォームで作成できる、ということで、Vimのjob/channel機能と非常に相性が良さそうだと思いました。これまでは、外部プログラムに依存するVimプラグインは敬遠され、pure Vim scriptであることが有難がられる風潮が一部ではありました(ような気がしています)。Goなら主要プラットフォーム向けにビルドした実行ファイルをGitHubのReleaseにでも置いておけば良さそうなので、遅い箇所はGoで、UIはVim scriptで、その間をjob/channelで繋ぐプラグインが増えてきても良さそうです。

vim-mode-plus for Atom editor

AtomのVimプラグインを通じて、よりVimへの理解が深まったとのこと。紹介されていたような概念はVimをずっと使って理解が深まってくるとある程度たどり着ける内容だとは思いましたが、それがきっちり整理され、さらに実装に活かされているところに深みを感じました。さらに、Practical Vim(実践Vim)も併せて読むと良いと思います。

また、懇親会でt9mdさんとお話させて頂いたのですが、VimのOperatorは一貫性があるような動きをしているように見せかけて、実はtargetがline-wiseかどうかで動きをad-hocに変えている、など泥臭い実装があるらしく、実際に作った人だから分かる素晴らしい知見だと思いました。

あと、周囲へのリスペクトを忘れない姿勢がかっこよかったです。

Vimの日本語ドキュメント

最も手っ取り早くVimの貢献する方法はこれのような気がしているので、本当は時間を見つけて参加したい…。

また、懇親会では、KoRoNさんのVim論を少し聞けておもしろかったです。(おそらく歴史的経緯で)Vimの内部構造がイケていないことに起因する話をいくつかされていたのですが、それでもVimが発展していっている点は色々と考えさせられます。ついつい、一から作った方が早い論に流されがちですが、既存のものを良く理解し発展させる方も常に考えたいと思いました。

Vim script parser written in Go

最近Vim界隈では、画期的なプラグインができた!というより、この手の周辺ツールを固めていく話が多い気がしています。Vim 8.0でのVim script強化と併せて、ある意味今はVim界隈全体として、基礎固めの時期なのかなと感じました。今後、これらをもとにしたすごいプラグインが出てくるといいですね!(おまえがやれという話ですが…)

僕の友達を紹介するよ

今回は、Vimプラグインにフォーカスした発表が少なかったので、おすすめをまとめて教えてくれる発表は価値があると思いました。

Best practices for building Vim plugins

thincaさんがこれまで感じた辛さをまとめたような発表でした笑 このあたりのベストプラクティスこそ、Vim本体のhelpに入っても良さそうなものですが、そのあたりどうなんでしょう?

全体を通して

Vim関係の勉強会は出られるものはできるだけ出るようにしているけど、ここ何年も毎回進捗がなく、自分が発表できるネタがないのがちょっとつらい。Vimどうこうより、家族(妻、子ども)と過ごす時間、仕事の時間、それ以外の時間、をうまくやりくりしてVim含めたプライベートな活動をどう進めて行くかが個人的な大きな課題。がんばろう。


2016/11/07 00:52 | Vim | トラックバック(0) | コメント(0)

ページの先頭へ

PythonでVim scriptの関数を定義する

Vim Advent Calendar 18日目!

こんにちは!Vim Advent Calendar 18日目担当のtsukkeeです。以前にも、vim-users.jpにて、Hack #132: Pythonインタフェースを使う(1)Hack #136: Pythonインタフェースを使う(2)を書かせていただきましたが、今回はさらに面白い?Pythonインタフェースの使い方を紹介したいと思います。

Pythonインタフェース内でVim scriptの関数を定義する

いきなりですが、vim_bridgeというものが既にあります。これに気づかず再発明してしまったのですが、自分が作ったものの方が自由に関数名を決めれるのでまぁいいことにします^^; サンプルコードは以下のとおりです。

PythonのデコレータでPythonの関数をVim scriptの関数に変換するところはvim_bridgeと同じですが、今回はデコレータの引数で関数名を指定できるようにしてみました。これによってs:fuga()のようなスクリプトローカスな関数や、例にはありませんが、hoge#fuga#piyo()のようなaudoload関数も定義可能です。

まとめ

PythonインタフェースはVimによってあったりなかったりするために、あまり広くは使われていません。また、はじめはPythonインタフェースを用いて実装していたものを、ピュアVim scriptにする人もいます。ですが、私はあえてPythonインタフェースを使うことも推奨したいです。逆にVim scriptゼロでVimプラグインを実装するというのも面白いのではないでしょうか?というわけで、18日目終わります!

2011/12/18 00:00 | Vim | トラックバック(0) | コメント(3)

ページの先頭へ

関西Vim勉強会 #7? #8?に参加してきました

lingr.vimとその中身の簡単な紹介を発表してきた。かなりざっとして説明だったのでどれぐらいの方に分かって頂いたかわからないけど、興味を持って頂ければと。最近は、VimのPythonインタフェース用ライブラリみたいなものも微妙に作り出しているので、将来的にはvitalに仲間入りさせてもらっても良いのかも。それぐらい洗練させれたらいいな。

他の方々の発表としては、ujihisaさんによるいくつかのプラグインの紹介とvitalの紹介、Sixeightさんによるrails.vimの紹介、kozo-niさんによるVundleの紹介があった。特に、Vundleは自分も最近つかいはじめて、超適当なhgおよびsvn対応版も勝手につくっているので、参考になった。作者がいい人っぽいというのは、自分も感じていて、GitHubにはマメにコメントしてくれるし、lingrのvim-users.jp部屋にも遊びにきてくれるしで、すごい親しみやすい人だとおもう。hgとsvnサポートも本家が近いうちにやってくれそうな感じなので期待している。

というわけで、主催してくださったujihisaさんをはじめ、参加者の皆様お疲れ様でした!

2011/05/07 19:10 | Vim | トラックバック(0) | コメント(0)

ページの先頭へ

iTerm2が(当初に比べて)むちゃくちゃ速くなったのでurxvtとかいらなくなった

これまで理想の(?)ターミナル環境を求めてMacでurxvtをいろいろゴニョゴニョしてきたけど,iTerm2がr176でかなり速くなり,r191でさらに速くなって,十分実用的になった.iTerm2なら256色表示できて,普通にコピペできて,Ambiguous Widthな文字をdoubleで表示するオプションもあって, 半透明表示もできて,なんというかもうこれでいいです.

たぶん,次のalphaバージョンでこの高速化が入るけど,待ち切れない人は,Xcode入れて,svn checkoutして,make Deploymentすれば簡単にビルドできます.

2010/9/30 追記: r196で64bit化したせいかわからないけど,もうちょい速くなってた.これがr176あたりで自分が試したやつやけど,r196では同じベンチマークスクリプトが0.7?0.8秒ぐらいで走るようになってる.単純計算で当初の6倍速か.Appleなら6x fasterとか宣伝できるレベルw

2010/10/1 さらに追記: ちょっと気になったのでTerminal.appやurxvtでのベンチもついでに.やってみた.それぞれMacBook Pro 15"(MacOS X 10.6.4, 2.4 GHz Core i5, 8 GB Memory)上で150x55,フォントはMenloの13ptに設定し,/bin/bash上で以下のスクリプトをtime ./scroll_bench 100000として3回走らせた結果の平均である.さすがにTerminal.appよりかは少し遅いけどurxvtよりも速くなっている.

ターミナルreal [sec]user [sec]sys [sec]
iTerm2 r1754.4360.2090.205
iTerm2 r1761.8520.2110.202
iTerm2 r1960.8030.2100.211
Terminal.app0.6290.1920.165
urxvt 9.07 on XQuartz 2.5.32.4270.1770.142

2010/09/29 17:02 | Mac | トラックバック(0) | コメント(0)

ページの先頭へ

トップページへ >> 次のページへ