ErgoDox EZ を使い始めて1ヶ月ぐらい経った

タイムラインで購入している人がちらほらいて,評判も良好みたいなので ErgoDox EZ というキーボードを試しに買ってみることにしました.購入したのは無刻印+アームレスト付きの赤軸です.

ErgoDox EZ

pic (画像は公式サイトから)

とりあえず購入して1ヶ月経ち,そこそこ慣れてきて違和感なく打てるようになってきたので,この辺りで備忘録がてらまとめてみることにしました.

購入

他の人のブログを読んでいると手続きして2週間以上かかったりしていたので,お盆明けぐらいに届けば良いかなーという気持ちで7月22日に購入手続きをしました.しかし実際は台湾からの発送で1週間で届きました.8月頭に1週間サンフランシスコ出張があったので受け取れなかったら返送されてしまうとヒヤヒヤしましたが何とか直前に受け取れました.

セットアップ

出張前にとりあえずセットアップだけしました.と言っても箱から出して高さを調節して設置してみて,ファームウェアのビルドができることを確認しただけです.

ErgoDox EZのキーマップを変更する - Qiita

この記事がとても参考になりました.コマンドラインから make 一発でビルドしてファームをキーボードのマイコンに焼きこむところまで出来るのでかなり楽です.

ErgoDox のキーボードファームウェアオープンソースで開発されているので,リポジトリ を手元に clone してきて必要なクロスビルド用のライブラリを Homebrew で入れるだけで OK です. 他の人のブログ記事を読んでいると qmk_firmware リポジトリを fork して自分の設定を足している人が多いですが,僕は設定ファイルは極力 dotfiles に置きたいので,clone してきたリポジトリ内に ergodox/keymaps/rhysd をつくってその中に dotfiles からシンボリックリンクを張りました.この辺は何でも良さそうですが.

なお,デフォルトだと PC がスリープ状態になったときに LED が光って邪魔だったのですが,Makefile 読んでみるとビルド時に指定することでオフにできました.

$ make teensy KEYMAP=rhysd SLEEP_LED_ENABLE=no

キー配置を考える

キーマップいじくるのは好きなのでお盆休みあたりに少し色々試してみました.キーマップは C 言語のプリプロセッサマクロで簡単に定義できます.最終的なキー配置はこんな感じ.(設定ファイル

  • 左側
,---------------------------------------------------.
| ESC    |   1  |   2  |   3  |   4   |   5  |  6   |
|--------+------+------+------+-------+-------------|
| Tab    |   Q  |   W  |   E  |   R   |   T  |  {   |
|--------+------+------+------+-------+------|      |
| LCtrl  |   A  |   S  |   D  |   F   |   G  |------|
|--------+------+------+------+-------+------|  }   |
| LShift |   Z  |   X  |   C  |   V   |   B  |      |
`--------+------+------+------+-------+-------------'
  |C-Left|      |      | LAlt |LG/Eisu|
  `-----------------------------------'
                                     ,--------------.
                                     |LGuiEnt|      |
                              ,------|-------|------|
                              |      |       | Home |
                              |Ctrl/ |TapL1/ |------|
                              |Space |Tab    | End  |
                              `---------------------'
  • 右側
,----------------------------------------------------.
|      |   7  |   8   |   9  |   0  |   -  |   =     |
|------+------+-------+------+------+------+---------|
|  _   |   Y  |   U   |   I  |   O  |   P  |   \     |
|      |------+-------+------+------+------+---------|
|------|   H  |   J   |   K  |   L  |   ;  |  '"     |
|  =   |------+-------+------+------+------+---------|
|      |   N  |   M   |   ,  |   .  |   /  |  `      |
`-------------+-------+------+------+------+---------'
              |RG/Kana| RAlt |   [  |   ]  |C-Right|
              `------------------------------------'
,---------------.
|AltTab|LGuiSpc |
|------+--------+--------.
| PgUp |        |        |
|------|BackSpc |RShift/ |
| PgDn |        |Enter   |
`------------------------'

基本的には英字配列からあまり外れないように

慣れるのが大変そうなので,基本的な配置はなるべく US からあまり外れないようにしました.例えば左端の Ctrl や Shift などのキーは残す,以前のキーボードで左手で押していた 6 キーは引き続き左手で押せるように移動する(デフォルトでは右手で押すようになってた)など.

ただし,ErgoDox のキーボードの列数は HHK のそれよりも少ないため,どうしても足りなくなります(特に右端の記号列).これはどうしようもないので,あぶれた [ と ] は最下段へ… これはちょっと押しにくいのでもう少し考えたいところです.今までのキーボードは小指の守備範囲が広くて,記号を多用するプログラミングでは結構つらかったので,それが解消されるならお釣りがくるかなという感じです.

単押し,複数押し

ErgoDox ではモディファイアキー(他のキーと一緒に押す Ctrl などのキー)の挙動をかなり細かく指定することができます.例えばキー単体を押した時は半角スペースを入力し,他のキーと一緒に押した時は Ctrl として働くといったことができます.また,Ctrl を押した次のキー入力が Ctrl と一緒に押した扱いになるワンショットなどの挙動も指定できます.

親指にたくさんキーを割り当てられるので,ここはしっかり活用したくて特に左右に2つずつある大きい親指キーには単押しと複数押しにそれぞれ割り当てています.

       ,---------------.      ,---------------.
       |LGuiEnt|LGuiSpc|      |AltTab|LGuiSpc |
,------|-------|-------|      |------+--------+--------.
|      |       | Home  |      | PgUp |        |        |
|Ctrl/ |TapL1/ |-------|      |------|BackSpc |RShift/ |
|Space |Tab    | End   |      | PgDn |        |Enter   |
`----------------------'      `------------------------'
  • 左手親指
    • 単押しはスペースキー,他のキーと同時押しで Ctrl キー
    • 単押しはタブキー,他のキーと同時押しでレイヤー2(後述)のキー配置
  • 右手親指
    • 単押しは Enter キー,他のキーと同時押しで Shift キー
    • バックスペースキー

これだとキー長押しのキーリピートができなくなるのではと思われるかもしれませんが,同じキー2連打以降の長押しはキーリピートとして扱われる仕様のため問題ありませんでした.

ちなみに親指向けにはさらにキーが配置できるようになっていますが,一番外側の縦3つのキーはホームポジションから指が届かないのでほぼ使ってません.この辺は外国人サイズなのかも.さらに Vim 的には Esc キーが親指のほうが良いかなとも思ったのですが,普段 jj で挿入モードから抜けるようにしているのと,Vim 以外ではほとんど使わないので Esc キーは普段の位置に収まりました.

英数キー,かなキー

僕は IME の状態を覚えておかないといけない 半角/全角 的なトグルキーが嫌で Mac の JP 配列のような英数キーやかなキーを使っています.HHK ではその挙動にするために Karabinar のお世話になっていたのですが,今回はファームウェアのキーマップ書き換えで出来そうなのでやってみました.

最初調べて出てきた情報によるとパッチを当てないとだめとのことでしたが,該当箇所を確認したところ既に修正された跡がありました.issue を漁ってみると下記を見つけました🙏.

Can't use KC_LANG1 & KC_LANG2 key

どうやら既に LANG1 がかなキー, LANG2 が英数キーとして使えるようなのでそのまま使ってみるとちゃんと動きました.Karabinar で設定していたのと同じように,単押しで IM 切り替え,他のキーと同時押しで Cmd キーになるようにしました.

Alfred や iTerm2 に1キーでアクセス

僕は普段ターミナルで作業するので,Cmd+Enter で iTerm2 を全画面トグルで使えるようにしています.また,Alfred もよく使うので,Cmd+Space にホットキーを設定しています.

ErgoDox ではこれらのホットキーを1ボタンに割り当てています.左親指キーの LGuiEnt というのがターミナルのトグルで,右親指キーの LGuiSpc というのが Alfred のホットキーです.頻繁に使うアプリのホットキーが1キーになることで思ったより楽になりました.

また,左右のワークスペースへの切り替えも最下段の一番端のキーのみで行えるようにしました(C-LeftC-Right がそれです).元々 Karabinar に頼って Ctrl + 左Cmd/右Cmd で切り替えというかなり変わったキー配置をしていたのですが,それが1キーで出来るようになりました.

キー配置レイヤー

ErgoDox ではキー配置にレイヤーを持たせることができ,Vim のモードのように複数のキー配置を切り替えることができます.レイヤーは3つ設定できます(デフォルトのレイヤーが L0 なので残りの L1 と L2).各レイヤーには Vim のようにキー入力で遷移したり,キーを押している間だけレイヤーを変えたり,キーを押した次の入力だけレイヤーを切り替える(ワンショット)といった好きな方法でアクセスできます.

僕はレイヤー3つは使いこなせる感じがしなかったので L1 だけ使い,F1〜F12 や方向キー&Home・Endキー,列が足りなくて再現できなかった右端の記号列のキー配置を設定したりしてますが,F1〜F12 と方向キーぐらいしかちゃんと使えていません.もっとレイヤーを使いこなしたい…

ErgoDox のキー配置(物理)について

ErgoDox は今まで僕が使ってきたキーボードとは違い,縦にまっすぐにキーが配置されています.そのため,以前のキーボードに慣れている指では最初誤入力が多発しました(特に C と V とか).これについてはキーボードに対する腕の向きが大事でした.一般的なキーボードは,キーボードに対して腕がハの字になるように設計されていると思います.それに対して ErgoDox では腕がキーボードに対して垂直になるように意識的に直してやる必要がありました.腕の向きを直すと大分誤爆が減りました.

また,ErgoDox に慣れると今までのキーボードが打てなくなるのではという懸念がありました.しかし今までは HappyHacking (US配列) を使っていて,職場では静音の Realforce (JP配列) を使っているので,新しい配列が加わったという感覚で,今までのキーボードが打てなくなるといったことは無さそうです.

打鍵感と音と振動

これらについては残念ながら以前の HHK のほうが遥かに良かったです.

打鍵感は HHK のほうがキーの押し込みがスムーズで押し心地が良いです.さすがに静電容量無接点方式にはメカニカルでは敵わないのかなという印象でした.

また,僕はキーの押下圧が強くて,HHK の時は特に気にならなかったのですが,ErgoDox では入力の振動が机に伝わってしまってモニターが少し揺れたりすることがあります.この辺りは良い机を買ったりすれば少しマシになるのかもしれませんが…

あと,音もちょっと気になりました.静音でない HHK Pro2 よりも大きいです.自宅では特に気になりませんが,職場でこの音は僕的にはちょっと…という感じです.

肩凝り

僕は昔から結構肩凝りがひどいのですが,それはかなりマシになりました.肩が開いて姿勢も良くなるので,そのおかげだと思います.日中ずっとキー入力していても肩がつらくなってきて中断といったことはほぼなくなりました.

まとめ

今の時点でもう ErgoDox のみでコードを書いたりツイートを書いたりしていて,特に困っていないです.前述のとおり肩凝りが解消されたのと,かなり小指の負担が減ったように思います.あと,キー配置やキーの挙動の自由度がかなり高いので,新しいキー設定を思いついたら即試せて今後も楽しめそうです.

僕自身はキーボードを組み立てる技術が無いので壊れた場合のサポートとかが少し不安ですが,その時は HHK にフォールバックして考えます.新しいおもちゃが手に入ったというのと,肩凝り解消などの実益で,僕にとってはなかなか良い買い物でした.

15K 行のアプリを TypeScript 1.8 から 2.0 に移行してみた

先日 TypeScript の新しいメジャーバージョン 2.0 のコンパイラの beta 版がリリースされました.

コンパイラのチェックの強化や非 null 型,tagged union など,いくつかの機能が追加・強化され,自分の趣味プロジェクトでも恩恵に与れそうだったので試しに移行してみました.

移行してみたのは下記の Electron でつくり中の Twitter Client アプリ(React+Redux)で,全体で大体 15000 行ぐらいです.

github.com

下記の手順で修正してみました.

  1. コンパイラをアップデートしてビルドしてみる
  2. --noImplicitThis--noUnusedLocals, --noUnusedParameters を有効にしてみる
  3. --strictNullChecks を有効にして nullability をチェックするようにする
  4. include で glob を使う
  5. Tagged union types で Redux の Action types をリファクタリングする
  6. 引数リストに trailling comma を入れていく
  7. インターフェースやクラスメンバを readonly 指定する

各段階でビルド&単体テスト確認をするのが大事だと思うので,なるべく細かく段階を分けました.コミットも大体各作業ごとになっているので,随時 diff のリンクを貼ります.

「説明しなくて良いからコードを見せろ」という猛者向けに,下記が今回行った作業の全 diff です.+-1000行弱ぐらいですね.

diff

コンパイラをアップデートしてビルドしてみる

TypeScript 2.0 beta は下記のコマンドで入るので,サッと入れてとりあえず npm run build してみます.

$ npm install --save-dev typescript@beta

TypeScript 2.0 では処理フローを見て型を付けるようになったので,この時点でビルドが失敗することがあります. 例えば下記みたいな場合です.

type T = 'aaa' | 'bbb';

const v: T = 'aaa';

switch (v) {
    case 'aaa': /* ここでは v の型は 'aaa' */ console.log('OK'); break;
    case 'bbb': /* ここでは v の型は 'bbb' */ console.log('OK'); break;
    default:    /* ここでは v の型は never */ console.log('NOT OK', v); break;
}

このように,制御フローを見て適宜型を切り替えてくれるようになりました. 上記のように v の型として取りうる可能性のある型がなくなると never という型になり,v を参照しようとするとエラーになります. never type も 2.0 で導入された機能です.

基本的に煩雑さが減る方向のはずなので,修正は容易なはずです.

diff

--noImplicitThis--noUnusedLocals, --noUnusedParameters を有効にしてみる

2.0 ではいくつかのチェック機能がコンパイラに追加されました.互換性が理由(?)でデフォルトはオフのようですが,特に理由が無ければ有効にしておいたほうが良さそうです. tsconfig.json"noImplicitThis": true, "noUnusedLocals": true, "noUnusedParameters": true のように指定できます.

機能名の通り各チェックを行って,検知した時はコンパイルエラーに落としてくれます.特に noUnusedLocals は tslint で検知してくれなかった未使用の import を検出してくれて助かりました.

diff

ここまではたとえ 2.0 にすぐに上げられないプロジェクトでも一時的にコンパイラのバージョンを上げてチェックさせることで恩恵に与れそうです.

--strictNullChecks を有効にして nullability をチェックするようにする

2.0 では null の型がそのまま null となり,T | null のように書くことで nullable な型を表現できます.また,undefined についても同様に T | undefined のように書けます. さらに tsconfig.json"strictNullChecks": true を追加することで,デフォルトで全ての型を non nullable type として扱うようにできます.

基本的には

  1. null を代入しているのに nullable でない変数の型に | null を追加する
  2. null が来る可能性があるのにチェックしていない箇所は素直にチェックする処理を入れる
  3. 型は nullable だけど実質 null な値が来ないところには null assertion 演算子(後置 !)を使う

という処理を入れていけば修正は OK です.3. は例えば下記のような感じです.

// 対象の要素が無い時 getElementById は null を返すので戻り値型は本来
// Element | null だが,静的に HTML に id が振られているので実質失敗しない
// expr! で expr が null にならないとコンパイラに伝える
const elem = document.getElementById('root')!;

また,null assertion 演算子undefined にも使えます.

変更箇所もなかなか多かったのですが,他にも細々とうまくいかないところがあり,この変更は思ったより大変でした.

例えば,strictNullChecks によってオプショナル引数の型が以前と変わります.

function foo(optional?: number) {
    // 1.8 まで -> number
    // 2.0 から -> number | undefined
    optional;
}

これだけ見ると問題ないように見えますが,型定義ファイルには,実質オプショナルでないのにオプショナル引数になっている定義が割といっぱいあります. 特にコールバックの引数の指定がまずいものが多く,1.8 までは型的には変わらなかったので問題にならなかったのですが 2.0 では問題になります.

今回例えば困ったのは react.d.tsStatelessComponent です.

interface StatelessComponent<Props> {
    (props?: Props, context?: any): ReactElement<any>;
    // ... その他雑多なプロパティ
}

上記の props? が問題です.

const MyComponent: React.StatelessComponent<Props> = props => ...;

今までは上記のようにコンポーネントの型を指定し,引数を推論させていてこれでうまくいっていました.ですが,引数は props? となぜかオプショナルに定義されているため, 2.0 からは props の型は Props | undefined に推論され,propsundefined でないかどうかのチェックを入れる必要が出てきてしまいます. (僕の知識が足りないだけで実は props?context? が実際に undefined になるようなケースがひょっとしたらあるのかもしれないですが…もしそうなら教えていただけるとうれしいです)

仕方がないので下記のようにしてワークアラウンドを入れています.

const MyComponent = (props: Props) => ...;

これだと引数の型はプログラマが指定したものになるので undefined チェックを回避できます.現状ではこれで問題になっていませんが,上記型定義の「その他雑多なプロパティ」がほしくなった場合は困ることになります.

また,react-redux.d.tsconnect() も困りました.connect()mapDispatchToProps(第2引数)だけを指定したいときは第1引数を null にできるのですが,第1引数の型定義に | null が入っていないため null を渡せません.仕方ないので手元で react-redux.d.ts に手を入れ,リポジトリに含めて typeings でインストールしたものの代わりにそちらを見るようにして凌いでいます.

型定義ファイルの更新状況などを見ながら,strictNullChecks を付けるのは少し待ったほうが良いかもしれません.DefinitelyTyped では今のところ TypeScript 2.0 向けの型定義ファイルの開発を types-2.0 ブランチで進めているようです.

include で glob を使う

TypeScript のプロジェクトファイル tsconfig.json で指定するソースコード一覧には今まで glob が使えなかったためファイルを1つずつ追加していました. 2.0 からは晴れて *** が使えるようになったのでそれを使うようにします.

**/*.ts**/*.tsxtypings/*.d.ts のように指定すれば良くなりました.

diff

Tagged union types で Redux の Action types をリファクタリングする

2.0 では tagged union types という機能が入り,union types のどの型の値が入っているのかを,各型に共通のプロパティで判断してくれます. プロパティには string literal type を指定すれば良いようです.公式の What's New に載っている例が分かりやすいです.

flux や redux では type プロパティを見てアクションの種類を判断するため,アクションの型を tagged union type にすることでうまく型がつくようになります.

/*
 * action_type.ts
 */

// 'type' プロパティがタグになる
type Action = {
    type: 'AddSomething',
    item: Something,
} | {
    type: 'Sort',
    kind: Kind,
} | {
    type: 'DeleteLast',
};
export default Action;


/*
 * actions.ts
 */
import Action from './action_type';

export function addSomething(item: SomeThing): Action {
    return {
        type: 'AddSomething',
        item,
    };
}

export function sort(kind: Kind): Action {
    return {
        type: 'Sort',
        kind,
    };
}

export function deleteLast(): Action {
    return {
        type: 'DeleteLast',
    };
}


/*
 * reducer.ts
 */
import Action from './action_type';

function reduce(state: State = DefaultState, action: Action) {
    switch (action.type) {
        case 'AddSomething':
            // ここでは action の型は {type: 'AddSomething', item: Something} になる
            const next = ...;
            return next;
        case 'Sort':
            // ここでは action の型は {type: 'Sort', kind: Kind} になる
            const next = ...;
            return next;
        case 'DeleteLast':
            // ここでは action の型は {type: 'DeleteLast'} になる
            const next = ...;
            return next;
        default:
            return state;
    }
}

大体こんな感じです.これで各アクションの処理内で間違ったプロパティにアクセスしていた時などは全てコンパイルエラーになります. 文字列リテラルが複数箇所にあるのが気になるかもしれませんが,全て string literal 型としてコンパイラがチェックするのでタイポしていてもコンパイルエラーになり安心です. 良い感じです.

ちなみに以前は type プロパティが取る値を全部 Kind というオブジェクトに入れて Kind.AddSomething のように参照していたので,:%s/Kind\.\(\w\+\)/'\1'/g のように置換して少しマクロを使ってやるだけで かなり簡単に置き換えられました.Vim 便利.

diff

引数リストに trailling comma を入れていく

個人的にかなり嬉しい機能なのですが,2.0 からは関数の引数に trailing comma が許されるようになりました(公式の例). (配列やオブジェクトの要素は前から trailing comma を許してます).

tslint がチェックしてくれるようになるのを待っても良いのですが,せっかくなので手で置き換えました.\h\w*\s*\(\n あたりで適当に grep で引っ掛けて修正します. Vim なら一度行末にコンマを追加する修正を入れれば,他の箇所は . で繰り返すだけで OK ですね.Vim 便利.

diff

インターフェースやクラスメンバを readonly 指定する

変更するつもりのないインターフェースのプロパティやクラスメンバに 2.0 から導入された readonly 指定をつけてまわります.基本的に大抵のプロパティは変更されないと思うので,デフォルトで readonly 付けるぐらいの勢いで良さそうです.:%s/^\s*\zs\ze\w\+?\=:/readonly /g とかやると雑にプロパティに readonly を付けられるので,付けてみてコンパイラに怒られたらそのフィールドを外す感じで機械的に作業できます.Vim 便利.

diff

まとめ

最近ブログ書いてなかった(ネタはあったのに)ので,久々に人柱になった内容をまとめてみました.まだ beta ではありますが,今のところ変なバグは踏んでません.--strictNullChecks 以外はとりあえずやっておいて損は無さそうです.せっかくなので,いずれ 2.0 が正式リリースされた時に役立つと良いなぁと思っています.

『SD別冊 Vim&Emacs』と『SoftwareDesign 5月号』に寄稿しました

SD別冊 Vim&Emacs と SoftwareDesign 5月号の Vim 特集にそれぞれ寄稿させていただきました.

SD別冊 VimEmacsエキスパート活用術

http://gihyo.jp/book/2016/978-4-7741-8007-6

www.amazon.co.jp

Software DesignVim 特集と Emacs 特集を集めて1冊の本にしたものです.VimEmacs について,入門から拡張の紹介,キーボードの話や昔話まであります.1冊読み終える頃にはエディタ成分を過剰多量に摂取できていることでしょう.

僕は 2015年 1月号に寄稿させていただいた「犬でも分かる!?Vim 導入&カスマイズ超基本」という記事を古くなっている箇所を改定して寄稿させていただきました.特にこれから Vim を使い始めたいと考えている方を対象に,インストール方法から Vim の入門の仕方(チュートリアルプラグイン導入,ヘルプの読み方など)を解説しています.

Software Design で「犬でも分かる!? Vim 導入&カスタマイズの超基本」という記事を書きました

全体を通して個人的に印象深かったのは,まつもとゆきひろさんの記事で EmacsGC 実装などを見て言語実装を学んだというところでした. 確かに EmacsLisp マシンとその上に Lisp で実装されたエディタという構成で,Atom にちょっと似ています(と言っても Atom は下地が Chromium なので全然厚さが違いますが).Emacs に次の GC 発動までに割り当てるメモリサイズとかの指定ができることを考えると普通のマーク・アンド・スイープなのかな.

Emacsruby-mode も実装したとのこと.Rubyend で終わる構文は地味に厄介で,ある endclass ブロックのものなのか if ブロックのものなのか…というのはぱっとみただけでは分かりません.雑にハイライトするだけなら大して問題にはならないのですが,class ... endif ... end では別のハイライト色を割り当てたいとかなるとちょっと考える必要があります.というのを vim-crystal を実装した時に考えたのを思い出しました.

Sofware Design 5月号

http://gihyo.jp/magazine/SD/archive/2016/201605

www.amazon.co.jp

VimGitHub の連携についての記事を『第1特集 コード編集の高速化からGitHub連携まで Vim[実戦]投入』に寄稿させていただきました.こちらは新規に書いた記事です.

仕事でも趣味でも GitHub を使った開発が非常に一般的になってきましたが,Vim はエディタ,Githubウェブサービス,Git は(主にコマンドラインベースの)VCS という都合上,どうしてもエディタとターミナル,ブラウザ間の移動が多くなってしまいがちです.そこで,Vim プラグインを使って VimGitHub の連携をスムーズにすることを目的とした記事を書きました.下記のような tips 形式で紹介しています.

  • Vim から Git を使うための Vim 本体の設定
  • Vim からコミットを見る(コミットブラウザ)
  • Vim から GitHub をブラウザでシュッと開く
  • Vim 内でイシュー確認
  • GitHub ではほぼ必須な Markdown ドキュメントの効率的な編集(表記法とか)
  • リポジトリ URL や issue 番号,絵文字の補完
  • Vim + Gist 連携

Git や GitHub 使ったこと無いよ!という方もいると思いますので,どうやって学べば良いかも introduction として書いてみました.

また,他の記事に目をやってみると,

  • ujihisa さんの入門記事.インストールからプラグインの概要まで幅広い内容です.
  • thinca さんの中級者向け機能紹介.矩形選択やオペレータ・テキストオブジェクト,ドットによるリピート,gn など「とりあえず Vim の基本操作は分かった」な人が読むとかなり勉強になる内容です.
  • tyru さんの正規表現解説.Vim の若干とっつきにくく強力な正規表現の解説です.ここまでしっかり Vim 正規表現とその使いみちについてまとまっている内容はなかなか無いですね.
  • mattn さんの Vim の歴史と最新の開発事情について.今年に入ってから version 8 に向けて非常に活発に開発が進んでいる Vim の開発事情と新機能がとても興味深いです.

といった感じで,Vim を使い始めたい初心者,もっと使いこなしたい中級者,Vim ジャンキー各位どの層にもうれしいラインナップとなっています.発売は明日(4/18)らしいので,是非手にとってほしいです.

なお,他の特集については Ubuntu 16.04 LTS の記事とかがとても参考になりました.Python3 や systemd,日本語入力周りの更新,LXD など色々あるもよう.

まとめ

この時期に Vim 関連の特集および別冊を立て続けに出してくるのは技術評論社なかなか攻めてきてるなという印象でした.エディタはプログラミングする上で欠かせないので,春から新しくプログラミングを始めた人とかにリーチすると良いなぁと思っています. 最近は組み込みな現場を離れてウェブサービス開発する部署にいるんですが,周りを見ると Atom 使ってる人が多いですね.Atom とか VS Code の特集も読みたい.

校正などでアドバイスをいただいた編集の方々および vim-jp の方々ありがとうございました.