ssh 越しにクリップボード共有したり URL 開いたりする lemonade の便利設定

私は普段は Windows マシンから自宅サーバLinuxssh で接続して作業しており、端末内で作業が完結している間はいいのだけど、Web ブラウザはローカル側なので、URL を開いたりクリップボードのやりとりなどが面倒。

そこで便利なのが lemonade!

GitHub - lemonade-command/lemonade: Lemonade is a remote utility tool. (copy, paste and open browser) over TCP.

ssh 越しから URL を飛ばしてローカルでブラウザを開いたり、リモート側からローカルのクリップボードの読み書きができる。便利。 lemonade を使う上であれこれやったのでメモ。

port forwarding

lemonade 作者の pocke さんはローカルマシン内で動いている仮想環境とのやりとりを想定していたようで、お互いのマシンが直接やりとりすることを想定していたようだけど、私の場合は外部マシンなのでそうは行かない。

これは SSH Remote Forwarding を使えば問題なく利用できる。

putty (Windows) の場合:

接続→SSH→トンネル にて、 源ポート: 2489 送り先: localhost:2489 リモート として、「追加」ボタンを押す。

OpenSSH (Mac/Linux) の場合:

以下の設定ファイルを作成する(ホスト名は環境に合わせる)。

# ~/.ssh/config
Host your.hostname
  RemoteForward 2489 localhost:2489

このようにするとリモートに ssh でログインした際に、リモート側は 2489 番ポートで LISTEN を始める。ここに通信すると、ローカルマシンの localhost:2489 にフォワードしてくれる。

なのでリモート側では、lemonade はリモート側の localhost に接続すれば OK。以下のように設定しておく。

# ~/.config/lemonade.toml
host = 127.0.0.1

注意点として、同じリモートマシンに複数の場所から ssh しちゃうと当然ながらうまく動かない。何度 URL を開こうとしても開かれず、実は別のクライアントマシン上でガンガン開かれていた、ということが起きる。

Windows で lemonade をバックグラウンドで動かす

ローカル側のマシンでは、lemonade はサーバとして常駐する。普通にコマンドプロンプトから実行すると、コマンドプロンプトが常駐してしまう。不便。

というわけでこの件について mattn さん(@mattn_jp)に相談したところ、以下のようにして lemonade.exe を生成することで、プログラムが端末から切り離されて裏で動作するようになるらしい…!

# 2023-09-25 更新。旧コマンド: go get -u -ldflags="-H windowsgui" github.com/pocke/lemonade
go install -ldflags="-H windowsgui" github.com/lemonade-command/lemonade@latest

端末から切り離されるので標準入出力などは使えなくなっちゃう(=ログが消える)けど、まあそこまで困らない。mattn さんありがとうございます!

というわけでこれをマシン起動時に起動するようにショートカットを作成。

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup 以下にショートカットを作成しておけばログイン時に実行される。

最初は nssm でサービス化を試したのだけど、なぜかうまく動かず…。この方法でなんとか動いたので良かった。

tmux のバッファと lemonade を連携する

tmux で範囲選択をしてコピーしたり、tmux のバッファから貼り付けを行う際に、lemonade 経由でローカルのクリップボードが使えると便利。私は tmux を vi mode で使っているので、以下のような感じ。lemonade コマンドがある場合だけ実行。

if-shell '[[ -x ~/.go/bin/lemonade ]]' \
  'bind-key ] run-shell "~/.go/bin/lemonade paste | tmux load-buffer -" \; paste-buffer ; \
   bind-key -t vi-copy y copy-pipe "~/.go/bin/lemonade copy"'

私の環境が若干アレで、.tmux.conf が読み込まれるタイミングで ~/.go/bin が PATH に入っていなかったので微妙になってる。これは事前に PATH に入ってる環境ならマシにできると思うので、今後やっていきたい。

emacs mode の人は別途調べてみてください。

Vimクリップボード操作と lemonade を連携する

Vim では "+y"+pクリップボードからコピー、ペーストができる。当然ここでも lemonade が使いたい。

というわけで fakeclip.vim…と言いたいところなのだけど、fakeclip.vim は特に lemonade をサポートしていない。仕方ないので fork してサポート足してみた。

追記: PR はすでにマージされているので本家を使えばOK

使う場合は以下のような感じ(dein.vim の場合):

call dein#add('kana/vim-fakeclip')

これで、環境にクリップボードサポートがない場合は lemonade が使われるようになる。

一応 PR も出したのだけど、そもそも微妙な変更なせいかスルーされ中。実際、やるならこういうやっつけ実装ではなくて内部構造を整理すべきな感じはする…。

以上

lemonade の便利設定の紹介でした。ssh で暮らしている人は便利なので使おう。

Yokohama.vim #8 に行ってきた

Yokohama.vim #8 に行ってきたよ!

Yokohama.vim の軌跡について

@gu4 さんの開始挨拶。

印象に残っているのが、gu4 さんは Vim で有能な新人をゲットするお仕事などをしているらしい。すごい。

アイスブレイク

自己組織化ゲーム(Vimバージョン)というのをやった。

指示を出してもらって動くより各々が自分で考えて動いた方が効率が良くなるみたいなのを理解するのが趣旨っぽいのだけど、そこはこの際どうでもよくて(?)、進む方向の指示の出し方が hjkl であるということが重要。

おかげで指示自体が慣れるまではなかなかうまく伝わらないということがあちこちで発生し、混乱している感じがなかなか楽しかった。

DSL でナンデモプログラミング!? ~TeXVim script を比較してみた~

資料: https://speakerdeck.com/wtsnjp/dsl-programming

@Watson_DNA さん(現在は @wtsnjp さんの模様)の発表。TeXVim script もめっちゃ遅い。

そもそも TeX で計算しようとするのすごい…。そしてその TeX に負けてしまう Vim script さん…。

ちなみに LingrVim 部屋はスライド内では常時議論と書いてるけど、基本雑談しかしてないし質問はいつでも welcome です!

Vim script で C のコンパイラを作ろうとしてる話

@Linda_pp さんのデモ。

なにやらちゃんと理解できてないのだけど、C のプログラムを Vim script に変換して実行するデモが流れ始め、なにやらそのような変換をする何かがあってそれを利用して Vim script に変換したらしいのだけど、それを使って C のコンパイラVim script に変換すれば pure Vim script で C のコンパイラが作れるなどと供述しており、完全にやばかった。

Vim 8.0 一周の旅

Vim 8.0 について知りたいとの会場の声があったので、急遽開催することに。

:help version-8.0 という Vim 8.0 についてまとまっているありがたい help ページがあるので、これをスクリーンに映してみんなで見つつ、かいつまんで解説していくコーナーをやった。構成は完全に行き当たりばったり。

やはりというか結構ボリュームがあり、長くなってしまったけど、割と需要があったっぽいのでやってよかった。

その他

Vim 8.0 の新機能によって TweetVim が便利になりそうな予感があるので期待。

懇親会

寿司やらカレーやらなどを食べつつおしゃべりタイム。だいぶ満足度が高かった。

懇親会で、@Watson_DNA さんに、Vim script で AtCoder に参戦するやつが動かないと報告を受け、どうやら AtCoder の実行環境が変わってしまったらしく、本当に動かなくなってしまっていた。

懇親会の最中に、なんとか新しい環境で動かせないかあれこれ試したけど、うまく行かなかったので、諦めた。よくよく確認したら入っている Vim(正確には vi コマンド)は Small Version だったので、Vim script 動くわけがない…。さようなら AtCoder…。

まとめ

次回も行くぞ!

Osaka.vim #7 に行ってきた

今更何を言い出すんだ、という感じではあるけども、次回 Osaka.vim #8 が来週に控え、さすがに何か残しておくか、という気持ちになったので書きます。

というわけで Osaka.vim #7 に行ってきました。3ヶ月前の勉強会の感想記事だよ!

当日朝

今回は @ryunix さんと二人旅。 新幹線でいざ大阪へ。

大阪で @koturn さん、@mozi_kke さんと合流し、4 人でランチを求めて大阪をさまよう。 一切事前に調べていなかったので、適当に大阪っぽいもの食べるか、という話になって適当なお好み焼き屋に入った。

で、その後会場へ。

↑これ適当に撮った割にはいい感じに撮れたっぽかったけど、建物は2棟あって、会場は反対の建物であった…。

本編

Osaka.vimもくもく会なので、一応作業はしていたけども、なかなか来れない大阪、ただ作業だけして帰るのはもったいなすぎますね。

というわけでスキを見ては別のテーブルに絡みに行ったりしました。

何話したかあまり覚えてないけど(早く書かないから…)、Unity つらい話とかをした気がする。Vim 一切関係ないw

作業の方は quickrun.vim が PR のマージばかりでバージョンがまったく切られていなかったので雑に 0.7.0 のバージョンを切ったりしてた。

懇親会

終了後に何人かで懇親会へ。思っていたより参加率は高くなかった記憶。

各々事情があるだろうし、懇親会に参加できない人がいるのは仕方のないことなのだけど、せっかくオフラインで会うのだから交流していかないともったいない。

これは今回の話というより今後勉強会などに参加する予定がある人みんなに向けて。

私はなんだかんだ言いつつ聞き手に回ることが多いのだけど、色んな人の色んな話を聞くだけでも楽しい。

翌日

翌日は @haya14busa さんと合流して、3人で USJ を満喫した。

Osaka.vim 関係ないので詳細は省くけど、デスノートのリアル脱出ゲームとフライングダイナソーが最高だった。

まとめ

次からはちゃんとすぐに感想記事を書くようにしたい。

第6回 集まっtail で LT してきた

Osaka.vim のレポート記事を書きそびれていい加減なんか書かんとなと言う気持ちの今日この頃です。今更感あるけどやっぱ後でレポート記事書こうかな…。

さて、最近は teratail と言うプログラマ向けの QA サイトをよく利用するんですが、そのオフィシャルのユーザーオフ会である第6回 集まっtailと言うイベントにスペシャルLT枠として招待されたので行ってきました。

どんなイベントかというと、ユーザー同士や中の人などが軽食を食べながらおしゃべりする、まあ本当に普通の交流イベントと言う感じ。中の人もいるので中の話なんかも色々聞けるのがよく、teratail と言うサービスを身近に感じれます。

で、私なんかがなぜか招待されたので、最初はどうしようか迷ったんですが、まあいい機会だと受けることにして、LT してきました。資料はこちら。

まー見るとわかるんですが、VimConf 2016 の宣伝と、発表者募集の宣伝ですね。こじつけ感がすごい。

まあでも、色々な方面の人がいるのが Vim のコミュニティの特徴だなと言うのは以前から感じていて、teratail もそこは共通しているなーと言うのは今回改めて思ったことでした。

発表資料について、私は普段発表するのはだいたい Vim 系のイベントなので、おこがましいのは承知の上で恥ずかしいのもあり自己紹介は端折っちゃうことが多いのだけど、今回はそうじゃないし一応ちゃんとやるかと思って、それならアイコン入れたいし画像使えるプレゼンツール使おうかと思ったんだけど準備にグダグダしていたら時間がなくなってしまっていつも通りの Markdown + showtime.vim になってしまったのはとても反省している。アイコンは自己紹介の場面でブラウザに切り替えるなどして雑に補完しました。

記事もグダグダしてきたのでまとめると、

  • VimConf 2016 発表者募集しているので応募してね!
  • テーマは「Vim もしくはテキスト編集に関わることならなんでも」だよ!Vim 以外の話でも大丈夫だよ!
  • 発表者になると参加費が無料になったり安くなったりするよ!

以上です。よろしくお願いします。

Vim の help を見せてくれる hubot スクリプトを作った

先週は Vim で help が引ける npm パッケージを作ったのだけど、そもそもなぜ作りたかったかというと、bot で使いたかったから。 と言うわけで vimhelp パッケージを使って、hubot-vimhelp を作りました。

https://www.npmjs.com/package/hubot-vimhelp
https://github.com/thinca/hubot-vimhelp

README は面倒になってあまりちゃんと書いてない。

導入方法

hubot スクリプトなので、hubot の使い方や hubot スクリプトの導入自体は省略(README に簡単には書いてあるけど)。 このスクリプト自体の導入については、スクリプトのソースの先頭にコメントで簡単な設定用の変数について書いてあるのだけど、ひとまず使いたいのであれば、

  • bot が動いている環境に vim コマンドが必要
  • プラグインマネージャ機能が使いたい場合は、
    • bot が動いている環境に git コマンドが必要。Git 2.3 以降じゃないと存在しないプラグインをうっかり指定した際に面倒なことになる可能性が高い
    • プラグインを入れておくディレクトリを用意して、そのパスを HUBOT_VIMHELP_PLUGINS_DIR 環境変数で指定する
  • 日本語ヘルプを優先して出してほしい場合は HUBOT_VIMHELP_HELPLANG 環境変数ja,en などと設定しておくとよい

以上で動く。

使い方

help の引き方

bot が動いたら、:help word もしくは :h word などで help が見れる。カンタン。手抜きをしているので、:he とかだと動きません。注意。

markdown が使える前提で、``` で囲まれた状態で発言されるので、そうじゃない環境だとおかしくなるかも。要望があればオプションなりで制御できるようにします(使いたい人いるんかな)。

プラグインマネージャ

プラグインマネージャは、/vimhelp plugin {cmd} で使える。 プラグインをインストールすると、そのプラグインの help も引けるようになる。 プラグインの指定({plugin-name})は、GitHubvim-scripts ユーザーのリポジトリ名か、<user>/<repos> 形式か、もしくは Git リポジトリのフルパスを指定できる。

  • /vimhelp plugin add {plugin-name}
  • /vimhelp plugin remove {plugin-name}
  • /vimhelp plugin update {plugin-name}
  • /vimhelp plugin list
    • インストール済みのプラグイン一覧の表示
    • (なんか条件によってはうまく動いてないっぽい…)

以上

まだバグが多い気がしてますが(特にプラグインマネージャ付近)、使ってみたい物好きな方がいればどうぞお使いください。

Vim で help が引ける npm パッケージを作った

色々あって node.js から Vim の help を引く必要が出てきたので、npm パッケージにしてみた。人生初 npm パッケージです。

https://www.npmjs.com/package/vimhelp
https://github.com/thinca/node-vimhelp

特に必然性はなかったのだけど、せっかくなので勉強も兼ねて ES2015 で書いてみた。node.js にも依存しているので、node.js 6 以降が必須です。 このパッケージは外部プロセスとして Vim を起動して、help を引きます。なので環境に Vim が必要です。また、プラグインの help も引きたいというそれだけのために Git を使った簡易プラグインマネージャも付いてます。こちらを使う場合は Git が必要。 使い方とかは README を参照してください。

苦労した点

初めての npm

今回初めてだったので、npm の作法やら ES2015 の機能やら、ついでにテストやらカバレッジ計測やら色々調べながらやった結果、必要以上に時間がかかってしまった…。

非同期地獄

node.js の非同期 API は、呼び出しスタックの奥底に 1 つでも非同期が混じると根本から非同期の API にする必要が出てくるのがだいぶしんどく感じた。Promise のおかげでネスト深いは回避できているものの、やはりまだしんどい印象が拭えない。ES2016 で入るとの噂の await があるとここがかなりマシになりそうな予感がするので、はよ。

外部プロセスのテスト

外部プロセスを起動するようなプログラムのテストはどこまでモックにするべきかがかなり悩ましい。コマンド実行部分をモックにすると、想定したコマンドが実行されているかまではテストできるが、想定したコマンドが期待した結果を生むかまではテストできない。そこまですべきなのかどうなのか…。 今はモック化するのが難しかったという理由もあって、テストでも実際にコマンドが実行されている。なのでプラグインマネージャのテストが走る度に git clone が実行されるという感じに…。実行も遅くなるので正直しんどい。

機能実現のアプローチについて

今回 Vim の help を引くという機能を実現するにあたって、Vim を実際に実行するという手段を選んだわけだけど、helptags や help ファイルを直接読んでパースするという手段も考えられた。 実際のところ、直接読んだ方が速度や効率は良いと思う。ただ、tags ファイルをパースしたり、Vim がやっている :help の引数の独自解釈などを自分でやるのが面倒だったため、今回は直接起動する方法を取った。こちらの方法だと、今後 Vim が :help の動作を拡張などした場合にも対応できる。そういう機会はそうそうないとは思うけども。少なくとも私が必要としている用途においてはこれでも十分な速度で動いている。

さいごに

初 npm パッケージ、作ってみたのはいいけど自分以外には需要なさそう。まだ欲しい機能がいくつかあるので、のんびり更新していく予定。

Software Desing 2016年5月号の Vim 特集記事に寄稿しました

技術評論社から発売される Software Design 2016年5月号 の第1特集「Vim[実践]投入」に寄稿しました。

gihyo.jp

全5章の構成で、5人の Vimmer が1人1章を担当する豪華な内容になっています。

書いたこと

私は第2章「Vim だからできる、一歩先行く編集術」を担当しました。

今回の特集は、4月から新社会人になった方々をメインターゲットに、入門者向けの内容になっています。 その中でも第2章では、Vim ならではの機能について紹介しました。

この記事を見て、多くあるエディタの中から Vim を選ぶ意義について感じてもらえれば幸いです。

書けなかったこと

今回、これから Vim を使い始める人達を対象に記事を書くということで、help の引き方についての解説を入れたかったのですが、紙面の都合上叶いませんでした。

Vim を使っていくにあたって、help を引くことはとても重要です。Vim は設計上の目標(:help design-goals)の一つによくドキュメント化されていることを挙げており、大抵のことは help に書いてあります。また、プラグインについても、まともなプラグインであればドキュメントが書かれていて、Vim の中からいつでも参照できるようになっています。

調べ方を知っておくというのは Vim に限らず重要なことです。記事内での解説は叶いませんでしたが、もし Vim を使うことに決めた場合は、まずはヘルプのヘルプ(:help helphelp)などを見て引き方を知っておくとよいでしょう。

それでは、よい Vim ライフを!