keyinput-delayer.vim で Vim での編集力を鍛える

• この記事はなに？
• 人はついつい「知っている方法・慣れた方法」で物事を進めてしまう。
• 使い方
• 類似プラグイン

この記事は Vim advent calendar 2024(Adventar) の4日目の記事です。

この記事はなに？

mikoto2000/keyinput-delayer.vim: 別名「Vimmer 養成ギプス」。 を作ったので、その宣伝です。

人はついつい「知っている方法・慣れた方法」で物事を進めてしまう。

それは Vim における編集でも同じことで、ついつい h, j, k, l での移動をしてしまいがちです。

それはなぜかというと、「キー入力のコストがとても低いから」であると私は考えました。

キー入力のコストがもっと高ければ、丁寧丁寧丁寧に操作を吟味してキー入力をすることでしょう。

例えば、帯域の狭い回線の SSH で、エコーバックがなかなか帰ってこない時、いつもより丁寧に操作をしたことはありませんか？

そんな環境を Vim 上で再現するのが mikoto2000/keyinput-delayer.vim, 別名「Vimmer 養成ギプス」です。

使い方

let g:keyinput_delayer_delay_time = "1000m" のようにディレイ時間を設定し、 keyinput_delayer#ToggleKeyInputDelay() を呼び出すことで、ディレイのあり・なしを切り替えます。

例えばディレイを 1 秒にしたとき、 10 行下に移動するために必要な時間は以下のようになります。

• j x 10 : 10 秒
• 10j : 3 秒

これを見て分かる通り、キーインプットのコストが非常に高くなるため、 「タイプ数を減らして編集を実現する」という意識が高くなります。

皆さんも keyinput-delayer.vim を導入して Vim のキーストロークゴルフ思考を身に着けていきましょう！

類似プラグイン

同じ目的のプラグインが存在することを vim-jp で教えていただきました。

こちらは、連続の 1 マス移動でカーソルが全く動かなくなるので、 よりストイックに鍛えたい方に向いているのではないでしょうか？

• takac/vim-hardtime: Plugin to help you stop repeating the basic movement keys
• m4xshen/hardtime.nvim: Establish good command workflow and quit bad habit

以上、 keyinput-delayer.vim の宣伝でした。

Nix で Vim をスタティックリンクビルドする。ついでにクロスコンパイルもする

• この記事はなに？
• 前提
• Nix のリポジトリアップデート
• スタティックリンクビルド
• aarch64 のクロスコンパイル＆スタティックリンクビルド
• ビルドされた Vim の場所
• パッケージング
• 参考資料

この記事はなに？

mikoto2000/devcontainer.vim の ARM 対応で、 ARM 版のスタティックリンクな Vim が必要になった。

vim-jp にて「Nix ならコマンド一発でできるよ」と教えてもらったのでやってみた。

前提

• Docker: Docker version 27.3.1, build ce12230
• 使用イメージ: nixos/nix

Nix のリポジトリアップデート

nix-channel --update

スタティックリンクビルド

nix-build '<nixpkgs>' --cores 20 -A pkgsStatic.vim

• --cores: make でいうところの -j オプション

aarch64 のクロスコンパイル＆スタティックリンクビルド

nix-build '<nixpkgs>' --cores 20 -A pkgsCross.aarch64-multiplatform.pkgsStatic.vim

ビルドされた Vim の場所

find で探しましょう。

bash-5.2# find /nix -name vim
/nix/store/jx5d1dp77cwkarvalh1l8zvfp2ziqzlw-vim-static-aarch64-unknown-linux-musl-9.1.0787/share/vim
/nix/store/jx5d1dp77cwkarvalh1l8zvfp2ziqzlw-vim-static-aarch64-unknown-linux-musl-9.1.0787/bin/vim
/nix/store/7wkl9dji0dq6v7nmdjp1d72wd5pydqpb-vim-static-x86_64-unknown-linux-musl-9.1.0787/share/vim
/nix/store/7wkl9dji0dq6v7nmdjp1d72wd5pydqpb-vim-static-x86_64-unknown-linux-musl-9.1.0787/bin/vim
/nix/store/gnzqq5zg8r55apxa5avlb5yp0ix8qdwk-nixpkgs/nixpkgs/pkgs/applications/editors/vim
/nix/store/gnzqq5zg8r55apxa5avlb5yp0ix8qdwk-nixpkgs/nixpkgs/pkgs/test/vim
/nix/store/yzqnkb2mfzphmhv3248pw0pqh6f1mn6y-7sprarsdfz9qcd7859phvr9nvhi14mri-source/pkgs/applications/editors/vim
/nix/store/yzqnkb2mfzphmhv3248pw0pqh6f1mn6y-7sprarsdfz9qcd7859phvr9nvhi14mri-source/pkgs/test/vim

bin 下のが目的のバイナリですね。

share の方にはランタイムが入っています。

パッケージング

Vim は、ランタイムと一緒に配布しないと上手く動かないので、パッケージングを行う。 さらに、ランタイムの場所はビルド時に決め打ちされるため、 VIM 環境変数を上書きして Vim を起動するシェルスクリプトを用意し、それ経由で実行してもらうようにする。 (今回の場合は AppRun というシェルスクリプトを用意)

# aarch64 のパッケージング
cp -a /nix/store/jx5d1dp77cwkarvalh1l8zvfp2ziqzlw-vim-static-aarch64-unknown-linux-musl-9.1.0787 vim-9.1.0787-aarch64
cd vim-9.1.0787-aarch64
cat << "EOF" > ./AppRun
#!/bin/sh
CURRENT_DIR="$(dirname "$(realpath "$0")")"
export VIM="${CURRENT_DIR}/share/vim/"
exec "${CURRENT_DIR}/bin/vim" "$@"
EOF
chmod a+x ./AppRun
cd ..
tar zcfv ./vim-9.1.0787-aarch64.tar.gz vim-9.1.0787-aarch64

# aarch64 のパッケージング
cp -a /nix/store/7wkl9dji0dq6v7nmdjp1d72wd5pydqpb-vim-static-x86_64-unknown-linux-musl-9.1.0787 vim-9.1.0787-x86_64
cd vim-9.1.0787-x86_64
cat << "EOF" > ./AppRun
#!/bin/sh
CURRENT_DIR="$(dirname "$(realpath "$0")")"
export VIM="${CURRENT_DIR}/share/vim/"
exec "${CURRENT_DIR}/bin/vim" "$@"
EOF
chmod a+x ./AppRun
cd ..
tar zcfv ./vim-9.1.0787-x86_64.tar.gz ./vim-9.1.0787-x86_64

これで、「ダウンロードした tar.gz を展開して、その中の AppRun を実行すれば vim が起動する」という感じになります。

devcontainer.vim で必要なので、このスタティックリンクな Vim を mikoto2000/vim-static: Distributing a static link binary for vim/vim. で配布予定です。

以上。

参考資料

• Learn Nix | Nix & NixOS | Nix & NixOS
• Using Nix within Docker - Nix Reference Manual
• nixpkgsのupgrade - mrsekut-p
• functor.tokyo – Cross-compiling and Static-linking with Nix

macOS で nexe を使って devcontainers/cli をシングルバイナリにする

• 前提
• Node.js のインストール
• devcontainers/cli のクローン
• ビルド
• おまけ
• 参考資料
• 変更履歴

前提

• OS: macOS Sequoia 15.1.1 (24B91)
• Homebrew インストール済み

前の macOS セットアップ記事の続きから。

Node.js のインストール

brew install nvm
mkdir ~/.nvm
export NVM_DIR="$HOME/.nvm"
[ -s "/opt/homebrew/opt/nvm/nvm.sh" ] && \. "/opt/homebrew/opt/nvm/nvm.sh"  # This loads nvm
[ -s "/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm" ] && \. "/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm"  # This loads nvm bash_completion
nvm install v21.7.3

devcontainers/cli のクローン

git clone --depth 1 -b v0.72.0 https://github.com/devcontainers/cli

ビルド

cd cli
yarn
yarn compile-prod
npx nexe --python=/usr/bin/python3 --loglevel="verbose" -i ./devcontainer.js --make="-j8" -r="scripts/updateUID.Dockerfile" -t -b -o ../dist/devcontainer-darwin-arm64-v0.72.0

node 自体に手を入れるらしく、初回に node 自体のビルドが走ります。

マシンスペックによりますが、初回ビルドは 1 時間以上かかることもあるので気長に待ちましょう。

ビルド後の node は保存されるので、 2 回目以降は一瞬です。

ファイルを埋め込んでアクセスしたいなどが無ければ Node 自体の Single Binary Application の仕組みを使う方ががおすすめです(これはこれで新しい node じゃないと無理ですが…)

以上。

おまけ

上記手順でシングルバイナリにしたモノを、以下リポジトリで配布しています。

mikoto2000/devcontainers-cli: Distributing a single executable binary for devcontainer/cli.

参考資料

• nexe/nexe: 🎉 create a single executable out of your node.js apps
• node-gyp/README.md at main · nodejs/node-gyp
• node/BUILDING.md at main · nodejs/node
• M1 mac mini を買ったのでセットアップしていく - mikoto2000 の日記

変更履歴

日付	内容
2024/11/30-1	新規作成
2024/11/30-2	nexe の注意点について追記