tmux 3.1b の window 分割線を ascii character にする

2020/05/04(Mon) に tmux 3.1b がリリースされました。
という事で、いつも通り EastAsianAmbiguous を ascii に変更するバージョンを作成します。
過去の作業履歴は 3.0a や 2.9a や 2.8 に、そもそもの問題についてはこのこのポストにまとめています。

環境

• OS: macOS Mojave 10.14.6
• tmux: 3.1b-border-ascii 526f000f29abadeef9f804bb9aea5291b913a312
• Homebrew:  2.2.15-2-gb06a7af
  • Homebrew/homebrew-core (git revision 0058c; last commit 2020-05-04)
• Font: Ricty 3.2.2

インストール方法

• $ brew install --HEAD atton/customs/tmux

でインストールできます。

本家との diff : utf8proc を使わない

homebrew-core にある本家 tmux は再度 utf8proc を採用しました。

しかし、 utf8proc は現時点の最新バージョンである 2.5.0 でも EastAsianAmbiguous 対応はされていません。

前回(2.3, 2.2.0)のように utf8proc を変更する選択肢もありました。

ですが、 tmux のソースを読むと utf8proc が無い場合 wcwidth を使うようなので、変更しない選択肢もありそうです。

試しに utf8proc を抜いてビルドした tmux を軽く触っても、特段違和感は無し。

とりあえず YAGNI の精神で、今回は utf8proc を使わない事にしました。

前回との diff : atton/tmux の default branch を master から border-ascii に変更

これは tmux へパッチを当てる運用方法の変更です。

ローカルで設定している remote repository は以下の2つ。

• origin: atton/tmux
• upstream: tmux/tmux

upstream を fetch して origin に反映させつつ、リリースがあれば対応するパッチを当てる、という運用でした。

ここで面倒だったのが、両方の master の使い分け。

例えば upstream/master の変更を origin/master に適用する時は

• $ git fetch upstream
• $ git checkout origin/master
• $ git rebase upstream/master

と、prefix を指定する必要があります。それに加えて、紛らわしいのも改善したい。

そこで、atton/tmux の master は削除して default branch を border-ascii に変更。

そしてローカルの tmux は master の remote tracking branch を upstrem/master に指定。具体的には以下のような感じ

• $ git checkout master
• $ git branch -u upstream/master

これにより master は tmux/tmux に追従し、他のブランチは atton/tmux に反映される、という状態にできました。

前回との diff : GitHub Actions の追加

GitHub Actions を2ヶ所で利用しています。

1ヶ所目は atton/tmux で、centos 環境で make 可能かチェックしています。

2ヶ所目は atton/homebrew-customs で、macOS 環境で make 可能かチェックしています。

GitHub Actions では mac と docker が使えるので、様々な環境下でテストできる点が良いですね。

Homebrew で awscli を upgrade して、依存の keg-only python@3.8 を link する

Homebrew が提供する awscli が 2.0 になる前辺り、必要な python が python@3.8 になりました。
awscli を upgrade する際、 python を消して python@3.8 を使うようにしたログです。

環境(ブログ作成時)

• OS: macOS Mojave 10.14.6
• Homebrew: 2.2.13-74-gecea0e5
• homebrew-core (git revision eb6d; last commit 2020-04-19)
• python: Python3.7.7
• python@3.8: Python 3.8.2
• awscli: aws-cli/2.0.8 Python/3.8.2 Darwin/18.7.0 botocore/2.0.0dev12

keg-only formula と Homebrew の install 事情

Homebrew は元々、 /usr/local/bin へ直接 formula を install しません。

/usr/local/Cellar などの PATH に install して、そこから symlink を貼ります。

その中で key-only formula は「install しても /usr/local/bin に link しない」 formula です。

今回は python@3.8 が keg-only に指定されています。理由として executable の衝突回避が挙げられます。

• 前提として、現時点で Homebrew が提供している python は 3.7 系列
• python が存在する環境に python@3.8 も installすると /usr/local/bin/python3 が重複する
• /usr/local/bin/python3 を 3.7 系列に譲るために、 3.8 は keg-only として link しない

という感じかと思われます。

keg-only formula を link する前の確認

 link の前に、念の為 python が使われていないか、以下のコマンドでチェックします。

• $ brew uses --installed python

何も出力されない場合は install 済みの formulas 全てにおいて python を使っていません。
出力がある場合、その formula は python を使っています。 3.8 の link は止めた方が良いでしょう。

python@3.8 を /usr/local/bin に link する

上記のチェック時、私の環境では出力が無かった為 python@3.8 を link する事にしました。
なお、 keg-only formula を link する場合は --force が必要です。

• $ brew upgrade awscli
• 依存関係で python@3.8 が install される
• $ brew link --force python@3.8
• $ which python3 aws
  • /usr/local/bin/python3
  • /usr/local/bin/aws
• $ python3 -V
• Python 3.8.2
• $ aws --version
• aws-cli/2.0.8 Python/3.8.2 Darwin/18.7.0 botocore/2.0.0dev12

これで python3 と awscli が upgrade できました。良し良し。
ちなみに homebrew-bundle では、 link: true を付けると link してくれます。

pry 0.13.0 で後方互換性を保ちつつ history file の path を設定する

pry が 0.13.0 になった際、実行履歴ファイルの指定方法が変更になった事への対応。加えて後方互換もつけたログ。

pry の警告(ruby 2.7.0 + pry 0.12.2)

ruby 2.7.0 で pry 0.12.2 を起動すると、以下のような警告が出ていました。
私は怠惰なエンジニアなので、問題が発生するまでは様子見をする事にしました。

pry 0.13.0 Released

そして、2020/03/21 に pry の version 0.13.0 がリリースされました。
素晴らしい事に起動時に例の警告が出ません。 pry の開発陣に感謝ですね。
しかし、これでハッピーエンド、という訳にはいきませんでした。

Pry.config の変更

私は pry の history file の path を指定していました。具体的な設定は以下。

0.12.2 はこの設定方法で問題ありませんでした。
しかし、 0.13.0 では設定方法が変わったようで、以下のように NoMethodError が発生します。
という事で設定方法を調べてみます。

設定方法探し

さて、指針も無く彷徨っても仕方が無いので、まずはそれらしい場所にあたりをつけます。

設定時、 Pry.config と書くので、 Config class か module あたりが無いか探します。

• $ git grep Config

すると lib/pry/config.rb に Config class がありました。

流し読みしつつ、 history で検索します。そうすると history に関連するコードの集まりを見付けました。

さらに言えば history_file なる attribute がありますね。とてもとても怪しい。

Pry.config.history_file の値を pry で確認すると、今書き込まれている history の path でした。

変数が特定できたので、まずは path を代入してみます。 弾かれないか心配でしたが特に問題無し。

pryrc で Pry.config.history_file を設定すると、指定した path に history が書き込まれました。これで解決。

なお、history_file 辺りを blame して commit を確認すると

`Pry.config.history.file` becomes `Pry.config.history_file`

とありました。なので調べた結論で正しそうです。

0.13.0 以前の history との互換性

さて、 pry 0.13.0 で history file の path を指定できました。

しかし bundler で gem を管理していると、バージョンが異なる pry が複数、なんてケースもあると思います。

幸い history file の中身は plain text なので、バージョン毎の違いは恐らくありません。
各 pry で同じ history の path を指定する事で、今まで通りバージョンに関わらず共通の history を参照できるはずです。
ということでバージョンが低い pry も考慮に入れた pryrc が以下。

• respond_to? でバージョン確認
• path は instance variable で一時的に定義して最後は消す

といった感じにしました。今の所は問題無く動作しています。

neovim + deoplete で kebab-case の補完をする

kebab-case(単語をハイフンで区切る) は snake_case や camelCase に比べ、比較的使われていないと思います。
ですが、 apt-get や docker-compose を打っていると少し利点を感じました。

• 「Shift Key を押さなくて良い」

怠惰な私にとって採用理由として十分。なので zsh で使う function は kebab-case で記述しています。

さて、ここで小さな問題が発生しました。
neovim で利用している補完プラグインの deoplete が、default の設定では kebab-case を補完してくれない。
と、いうことで kebab-case も補完対象にするように設定したログです。

環境

• OS: macOS Mojave 10.14.6
• zsh: 5.7.1 (x86_64-apple-darwin18.2.0)
• neovim: v0.4.3
• deoplete: master(記事執筆時 6e01000280)
• Python: 3.7.6
• pynvim: 0.4.1

補完の設定

まず、補完の対象を設定する変数などが無いか、:help deoplete で探します。

ありました。keyword_patterns で filetype 別に正規表現を指定すれば良さそうです。
というか ruby の補完サンプルもありますね。末尾の ! や ? に対応している。便利そう。

話が逸れました。まず、kebab-case にマッチしそうな正規表現として

• 最初の文字は alphabet と '_'
• それ以降は alpabet と '_' と '-' が0回以上繰り返される

とします。これを具体的な正規表現にすると

• [a-zA-Z_][a-zA-Z_-]*

で良さそうです。これを filetype zsh の補完に設定します。
何故 sh でなく zsh かと言うと、 sh では kebab-case のfunction が定義できない為です。

設定後、きちんと補完されるようになりました。良し良し。

おまけ(他の定義とか)

これで deoplete の補完対象の設定ができるようになりました。
zsh 以外の普段良く使う filetype の補完設定もしておきます。

• ruby: 先程発見した ruby の補完設定で、先頭に '@' を加えたもの
• text: 英数字も含めて補完対象を広めにしたもの
• _: help にあった定義をそのまま利用。なお、この設定は全 filetype に適用されます

これらを鑑みて設定した、私用の具体的な keyword_patterns の設定はこんな感じ。以下抜粋。

python2 に依存した Vim plugin が無いか確認と修正対応をしたお話

2020/01/01(Wed) に python2 のサポートが終了しました。が、今の所私の周辺で問題は発生していません。

Neovim で :checkhealth を実行していると、まだ python2 provider が有効な事にふと気付きました。
「いつか python2 provider も消えるのだろうな」と悠長に考えたのが1つ目の感想。
「python2 に依存した plugin があったらマズいのでは」と思って焦ったのが2つ目の感想。
「問題は発生していない」と思っているけれど、本当にそうなのか念のために確認+対応したログです。

環境

• OS: macOS Mojave 10.14.6
• Neovim: 0.4.3
• Python2: 2.7.16 (system builtin)
• Python3: 3.7.6 (installed by homebrew)

has('python') している plugin が無いか確認

私は Neovim の plugin management に dein を使っています。

そして、plugin の install 先は ~/.config/nvim/dein を指定しているので、その先に cd して grep をかけてみます。

• $ cd ~/.config/nvim/dein/repos/github.com
• $ egrep 'has\(.python.\)' -R .

egrep のオプションの -R は、指定したディレクトリを起点に recursive に探索してくれます。

そして、渡しているディレクトリは '.' なので、 カレントディレクトリ以下の全てのファイルを対象にできます。

egrep で指定した正規表現は 'has\(.python.\)' です。これは

• まず、 vim/neovim で特定の feature が有効か確認する方法として 'has' function があります。
• そして python2 provider が有効かどうかは has('python') の実行結果で分かります。
• 加えて考慮する事として、python を括る文字が ' と " のどちらかの問題があります。
• これは面倒なので . にしました。 ['"] 2つなどでもOKです。
• 最後に、'()' は egrep パターンマッチに使う記号なので \ でエスケープします。

さて、実行結果は以下のようになりました。

前後のソースを読んではいないので、 現段階では対応が必要かもしれない plugin 一覧とします。

一時的に python2 provider を無効にする

Neovim で :help provider とすると、各 provider の説明が確認できます。
その中には provider を無効化する方法も存在しており、 python2 の場合は

• let g:loaded_python_provider = 0

と ~/.config/nvim/init.vim に書くと無効化できます。

なお、この状態で :checkhealth を実行すると

• - INFO: Disabled (g:loaded_python_provider=0).

と表示されます。

さて、これで仮に python2 provider が消えた時状態を再現できました。

先程 egrep で見付けたプラグインの動作確認を行なった結果、

• gregsexton/VimCalc
• atton/gundo.vim

が動作しませんでした。

VimCalc 対応: VimCalc -> VimCalc3

安直に「VimCalc python3」で検索をかけてみます。

そうすると、fedorenchik/VimCalc3 が見付かりました。なお、 fork 元は本家の gregsexton/VimCalc です。

お試しでインストールすると、ほぼ同じ動作。ということで VimCalc3 に乗り換えます。

gundo.vim 対応: let g:gundo_prefer_python3 = 1

さて、二度目も安直に「gundo.vim python3」でググります。

そうすると bitbucket の issue のページがヒットしました。どうやら既に対応済みだったらしく

• let g:gundo_prefer_python3 = 1

と書くことで python3 を利用するようです。動作確認もできたので、 gundo.vim はそのまま使う事にします。

まとめ

これで Neovim がいつ python2 provider を消しても大丈夫になりました。

蛇足ですが、対応した2つのプラグインは利用頻度が低く、 LazyLoad していました。

なので、仮に Neovim が python2 provider を消したとしても、気付くのに時間がかかった可能性は十分にあります。

それを排除できたので、備えあれば何とやら、ですね。