Yoshi Yamaguchi

セットアップ

この記事は英語の原文を日本語に翻訳したものです。原文: https://adoptingerlang.org/docs/development/setup/

翻訳元: adoptingerlang/adoptingerlang 2025-12-18（コミット 899008f）

ErlangをインストールしていなければErlangのコードを書くことはできません。そのため、当然ながらこの章の最初のステップは、主要なプラットフォームのほとんどでErlang/OTPをインストールするために必要な基本的な手順を一通り説明することになります。ここでの説明は、どのプラットフォームでも基本的なセットアップができることを目指していますが、実際の現場でのErlang開発が基本的な手順だけで済むことはめったにないとわかるはずです。

実際、チームが大きくなり様々なプロジェクトを抱えるようになると、すべてのサービスやライブラリ、コード断片が同じバージョンのErlangをサポートするとは限らず、また一斉にアップグレードされるとも限らない、という状況になりがちです。Erlangを業務で使っている開発者に話を聞くと、(Windowsユーザーを除いて)ほとんどの人は必要なオプションで自分自身のコピーをコンパイルし、複数バージョンを切り替えられるツールを使っていると答えるでしょう。というわけで、その方法についても説明していきます。

また、Erlangコミュニティの公式ビルドツールであるRebar3のインストール方法や、各種テキストエディタの基本設定についても見ていきます。後の章では、KubernetesやPrometheusといったErlang固有ではない他のツールについても扱いますが、ひとまずはErlangそのものから始めましょう。

Erlang/OTPのインストール

最初のステップは、きちんとしたErlang/OTPのインストールを済ませることです。これはすべてのプラットフォームで一様な体験になるわけではありませんが、少なくともこの手順に従う全員が、どんな作業環境でも完全に機能するセットアップを手に入れられるようにします。

バージョンの選択

Erlang/OTPは、後方互換性を壊す変更について明確に定義された基準を持ちつつ、かなり安定して予測可能なスケジュールでリリースされています。

Erlangのバージョンは、Erlang/OTPのシステム原則で説明されている <メジャー>.<マイナー>.<パッチ> という方式で番号が振られています。まれに、他の数字が「分岐」バージョンとして付け加えられることがありますが、気にする必要はまずないでしょう。

実際にありうるバージョンの例を挙げます。

  • 22.0
  • 22.0-rc3
  • 21.3
  • 21.2.3
  • 21.1
  • 19.3
  • 17.0
  • R16B03(これは2014年以降使われていないレガシーなバージョン表記です)

ご覧の通り、パッチが不要な場合は パッチ バージョンは記載されません。Erlangのリリーススケジュールはおおよそ次のようになっています。

  1. 年に一度、2月か3月頃に、次のメジャーバージョンのリリース候補が発表されます( -rc1 や -rc2 のような接尾辞が付きます)。このリリース候補はソースからビルドしたいユーザー向けに提供され、自分のアプリケーションやシステムがそれでうまく動くかをテストできるようになっています
  2. 数か月後(4月から6月)に、メジャーリリースが切られ公開されます。メジャーリリースにはより大きな仮想マシンの変更を必要とする大きな新機能が含まれ、後方互換性を壊す変更も許容されます
  3. 3〜4か月に一度の頻度でマイナーリリースが公開され、通常は安定性の修正や個々のライブラリへの小さな機能追加が含まれます
  4. セキュリティや安定性の理由で重大なバグが見つかった場合には、パッチリリースが発表されることがあります
後方互換性を壊す変更は、通常削除される前に非推奨のサイクルを経るため、適応するための十分な時間が確保されがちです。このポリシーは、EricssonのOTPチームが公開しているサポート・互換性・非推奨・削除というドキュメントに記載されています。

まれなシナリオでは、(たいていは偶発的に)厳格な非推奨化が実際に行われることがあり、コミュニティが回避策を考え出すのに数週間かかることもあります。

したがって、Erlangを採用するチームは、あまり大きく後れを取らないようにするため、メジャーリリースに合わせたメンテナンススケジュールを採用したいと考えるでしょう。時々しかアップグレードしないことも可能ですが、一度にまとめて大量のメンテナンスをするよりも、こまめに少しずつメンテナンスをするほうが楽だとわかるはずです。

なお、パッチレベルのリリースはメーリングリストでのみアナウンスされ、GitHub上のメインリポジトリでタグ付けされることが多く、メインのウェブサイトではパッケージ化されないことに注意してください。

Windows

Windowsユーザーの場合、Erlang開発にはWindows 10を使うことをお勧めします。それ以前のバージョンでも動作する場合はありますが、たとえばRebar3のようなコミュニティツールはWindows 10でしかテストされていません。

Windows上でソースからビルドするのは昔から非常に困難であることが知られているため、ビルド済みのコピーを使うことをお勧めします。

Chocolateyを使っている場合は、Erlangパッケージを取得し、次のようなコマンドで好きなようにインストールできます。

choco install erlang                   # 最新版の場合
choco install erlang --version 21.2 -m # 複数バージョンを許可
choco install erlang --version 20.1 -m # さらにもう1バージョン

これにより、必要なすべてのバージョンが PATH 変数に追加されるので、その後は正しい順序を保つように管理する必要があります。

Chocolateyを使わない場合は、www.erlang.org/downloadsで配布されているバイナリを使うか、あるいはErlang Solutions Ltd.がビルドしたものを使ってください。

これらのバージョン用のインストーラには、必要な手順をすべて案内してくれるウィザードが付属しています。

Erlang/OTPを PATH 変数に忘れずに追加してください。そうすることで、コマンドラインから呼び出せるようになります。

  1. スタートメニューで「システム環境変数」を検索し、「システムのプロパティを編集(コントロールパネル)」を選びます
  2. 開いた「システムのプロパティ」ウィンドウの下部にある「環境変数…」ボタンを押します
  3. Path 変数を選択し(存在しない場合は作成し)、「編集」ボタンをクリックします
  4. インストールパスに合わせたErlang/OTP用のエントリを追加します。通常は C:\Program Files\erl10.2\bin のような形になります。リストの先に置かれたエントリほど先に読み込まれます
  5. 設定を保存します
  6. 実行中のターミナルをすべて閉じて再起動します

長期的に開発を行うのであれば、この方法で複数のバージョンをインストールできるようになります。 PATH 変数内のパスの優先順位を変更・修正することで、どのバージョンを使うかを制御できます。

Windows開発においてこだわりがある場合は、Visual Studioのような、ほぼすべての作業をIDE内で完結できる環境が快適に感じられるかもしれません。Erlangは異なる環境から来ており、本書で使う説明の多くはコマンドラインですべてをビルドすることに主眼を置いています。

Windowsでコマンドラインを実行するためのターミナルを探しているなら、いくつかの選択肢があります。

  • ターミナルとしてPowerShellを使う。本書のほとんどのコマンドはこれで問題なく動くはずですが、一部エッジケースがあるかもしれません
  • Windows用gitをダウンロード・インストールする。これには git-bash シェルが付属しており、本書のほぼすべてのツールやコマンドとうまく連携します
  • より快適なターミナルエミュレータとしてConEmuを試す
  • 上記のほとんどをうまくパッケージ化したWindowsコンソールエミュレータであるCmderを使う
  • 自己責任でCygwinを使う。Cygwinとうまく連携させるにはソフトウェアをソースから再ビルドする必要があり、Rebar3のようなツールは自分がWindows上にいることを動的に検出するため、歴史的にCygwinとやり取りする際にいくつかパスの問題を引き起こしてきました

その後は、お好みのエディタやIDEを使ってErlangのコンポーネントを扱うことができます。

OSX

OSXではHomebrewやErlang Solutions Ltd.のパッケージを使ってビルド済みのErlang/OTPをインストールできますが、これは最初にちょっと試してみたいときだけにすべきです。長期にわたって実際に開発を行う予定なら、代わりに複数バージョンを同時に扱えるようにしておきたいはずです。

これに最もよく使われているツールがkerlです。Kerlは、単一のシステム上で様々なErlang/OTPバージョンをダウンロード・コンパイル・ロードするためのラッパーで、面倒な操作のほとんどを抽象化してくれます。

Kerlはhomebrewから $ brew install kerl を呼び出すか、そのREADMEファイルの手順に従うことでインストールできます。

Erlangをインストールする前に、いくつかの依存関係をインストール・更新する必要があります。主なものとしては、XCodeがインストールされていることを確認し、それからOpenSSLをインストールすることです(OSXにデフォルトで入っているSSLはひどく古いため)。

$ brew install openssl
...
$ ls /usr/local/Cellar/openssl/
1.0.2q

ここで得られるローカルのopensslインストール先のフルパス(ここでは /usr/local/Cellar/openssl/1.0.2q/ )に注目してください。

環境に次のオプションを設定できます。

SSL_PATH=/usr/local/Cellar/openssl/1.0.2q/
export KERL_BUILD_BACKEND="git"
export KERL_CONFIGURE_OPTIONS="--without-javac \
                               --with-dynamic-trace=dtrace \
                               --with-ssl=${SSL_PATH}"

そしてこれが有効になっていることを確認してください(たとえば source ~/.bashrc を呼び出します)。これらのオプションは、ビルドツールが受け付ける、あるいは期待する内容を指定するものです。ここでのものはJavaバインディングを無効にし、先ほど作成した新しいSSLインストールを使うものです。他の設定オプションについてはビルド手順を参照してください。

GUIの利用・ビルドを可能にする Wx のような機能を追加したい場合は、OSX向けビルド手順にさらなる詳細が記載されています。

そこから先は、自分自身でErlang/OTPのバージョンをダウンロード・インストールできます。

$ kerl update releases
...
# kerl build <release> <build name>
$ kerl build 21.3 21.3
...
# kerl install <build name> <target path>
$ kerl install 21.3 ~/bin/erls/21.3/
...
# そのバージョンを有効にする
$ . ~/bin/erls/21.3/activate
# あるいは
$ source ~/bin/erls/21.3/activate

インストールされたバージョンはいつでも有効化できます。デフォルトのバージョンを設定したい場合は、有効化コマンドを .bashrc 設定ファイル(または利用しているシェルのプロファイル)に書いておくことができます。

開発マシンでErlangとElixirの両方を使う予定なら、asdfを検討してみるとよいでしょう。これは複数のプログラミング言語向けのプラグインベースのインストーラで、ElixirとErlangの両方を一度に扱えます。動作させるには autoconf パッケージのインストールが必要になる場合があります。

Erlangで使うには、 asdf plugin-add erlang https://github.com/asdf-vm/asdf-erlang.git を呼び出してErlangプラグインをインストールします。このプラグインは kerl をラップしてそのオプションをすべて再利用しますが、ビルドの管理を asdf の制御下に移します。そのため、これまでの設定手順はそのまま同じですが、呼び出す一連のコマンドだけを次のように変える必要があります。

# asdf install erlang <version>
$ asdf install erlang 21.3
...
# asdf global <name> <version> [<version>...]
# asdf local <name> <version> [<version>...]
# export ASDF_ERLANG_VERSION=<version>

kerl と asdf の主な違いは、 kerl は環境変数を使ってどのバージョンを実行するかを知るのに対し、 asdf はディレクトリ単位で切り替えるために .tool-versions ファイルを任意で使う点です。

Linux

LinuxディストリビューションにはほぼすべてErlangのビルド済みコピーをインストールできるパッケージマネージャがあり、あるいはErlang Solutions Ltd.のパッケージを使うこともできます。ただしOSXの場合と同様に、これは最初にちょっと試してみたいときだけにすべきです。長期にわたって実際に開発を行う予定なら、代わりに複数バージョンを同時に扱えるようにしておきたいはずです。

これに最もよく使われているツールがkerlです。Kerlは、単一のシステム上で様々なErlang/OTPバージョンをダウンロード・コンパイル・ロードするためのラッパーで、面倒な操作のほとんどを抽象化してくれます。

kerlは次のようにインストールできます。

$ curl -O https://raw.githubusercontent.com/kerl/kerl/master/kerl
$ chmod a+x kerl

そしてkerlをパスの通った場所に移動します。kerlはライブラリのビルド時に必要になりそうな不足している依存関係を自動的にチェックして警告してくれるので、そのまま次のコマンドを実行し、指示に従って進めることができます。

まず、環境で次のようにオプションを設定できます。

export KERL_BUILD_BACKEND="git"
export KERL_CONFIGURE_OPTIONS="--without-javac \
                               --with-dynamic-trace=systemtap"

そしてこれが有効になっていることを確認してください(たとえば source ~/.bashrc を呼び出します)。これらのオプションは、ビルドツールが受け付ける、あるいは期待する内容を指定するものです。ここでのものはJavaバインディングを無効にしますが、どのみち自動的にスキップされます。他の設定オプションについてはビルド手順を参照してください。

GUIの利用・ビルドを可能にする Wx のような機能を追加したい場合は、Wx向けビルド手順にさらなる詳細が記載されています。

そこから先は、自分自身でErlang/OTPのバージョンをダウンロード・インストールできます。

$ kerl update releases
...
# kerl build <release> <build name>
$ kerl build 21.3 21.3
...
# kerl install <build name> <target path>
$ kerl install 21.3 ~/bin/erls/21.3/
...
# そのバージョンを有効にする
$ . ~/bin/erls/21.3/activate
# あるいは
$ source ~/bin/erls/21.3/activate

インストールされたバージョンはいつでも有効化できます。デフォルトのバージョンを設定したい場合は、有効化コマンドを .bashrc 設定ファイル(または利用しているシェルのプロファイル)に書いておくことができます。

開発マシンでErlangとElixirの両方を使う予定なら、asdfを検討してみるとよいでしょう。これは複数のプログラミング言語向けのプラグインベースのインストーラで、ElixirとErlangの両方を一度に扱えます。動作させるには autoconf パッケージのインストールが必要になる場合があります。

Erlangで使うには、 asdf plugin-add erlang https://github.com/asdf-vm/asdf-erlang.git を呼び出してErlangプラグインをインストールします。このプラグインは kerl をラップしてそのオプションをすべて再利用しますが、ビルドの管理を asdf の制御下に移します。そのため、これまでの設定手順はそのまま同じですが、呼び出す一連のコマンドだけを次のように変える必要があります。

# asdf install erlang <version>
$ asdf install erlang 21.3
...
# asdf global <name> <version> [<version>...]
# asdf local <name> <version> [<version>...]
# export ASDF_ERLANG_VERSION=<version>

kerl と asdf の主な違いは、 kerl は環境変数を使ってどのバージョンを実行するかを知るのに対し、 asdf はディレクトリ単位で切り替えるために .tool-versions ファイルを任意で使う点です。

FreeBSD

FreeBSDでは、(他の節でも触れているように) kerl を使った体験はうまくいったりいかなかったりします。他のプラットフォームと同じくらいスムーズに動かすために、いくつかパッチが必要になることもあります。良いニュースとしては、BSDのportsやpackagesを使えば、すべて問題なく動作するということです。

これは最も簡単な方法ですが、Erlangのバージョンマネージャが無料で手に入るわけではないため、バージョンの切り替えは少しやりにくくなります。とはいえ、BSDのportsやpackagesを使えば、サポートされているどのバージョンでも好きなようにビルドできます。

たとえば、次のいずれかを呼び出すことができます。

# pkg install erlang # デフォルトのコピー
# pkg install erlang-runtime20  # OTP-20.x
# ls /usr/ports/lang/erlang* # ソースインストール: バージョンディレクトリを選ぶ
erlang/
...
erlang-runtime20/
erlang-runtime21/
erlang-wx/
# cd /usr/ports/lang/erlang-runtime21/
# make config-recursive     # すべての依存関係を設定
# make install

FreeBSDのメンテナーは、主要なサポート対象アーキテクチャで物事がきちんと動き続けるようにすることに概して長けているので、x86にこだわりARMを避けている限り、大きな問題にぶつかることはないはずです。

見た目を整える

作業を終える前に、シェルやターミナルのプロファイルにいくつか環境変数を追加しておくとよいでしょう。具体的には、 ERL_AFLAGS や ERL_ZFLAGS を使うことで、常時 erl 実行ファイルに設定スイッチを追加できます。

ここでは ERL_AFLAGS を使って、2つの便利な機能を有効にします。デフォルトでUnicodeをサポートした文字列を出力することと、Erlangシェルが起動をまたいでコマンドを記憶できるようにシェル履歴を有効にすることです。次の内容を環境に追加してください。

export ERL_AFLAGS="+pc unicode -kernel shell_history enabled"

こうすることで、少しだけ現代的な感覚で使えるようになります。

Rebar3のインストール

Rebar3はErlangコミュニティにおける標準のビルドツールです。Erlangに同梱される他のツール群に加えていくつかのオープンソースツールをまとめ、統一されたプロジェクト構造の下ですべてを機能させます。

Rebar3のインストール方法はいくつかあります。ビルド済みバイナリから、ソースから、そしてより高速に動作するローカルインストール版です。いずれの場合も、Erlangが先にインストールされている必要がある点に注意してください。

ビルド済みバイナリ

ビルド済みバイナリはwww.rebar3.orgにあります。最新の安定版への大きな「Download」ボタンがありますが、もう少し冒険したいのであれば最新の_nightly_ビルドを取得することもできます。

rebar3 のようなコマンドラインユーティリティを置くための ~/bin/ ディレクトリを作るのが一般的で、ダウンロードしたバージョンをそこに置くとよいでしょう。実行できるように chmod +x rebar3 を呼び出し、 ~/.bashrc や ~/.zshrc などに export PATH=~/bin/:$PATH を書いてパスに追加してください。

ターミナルエミュレータではなくPowerShellやcmd.exeからコードを使いたいWindowsユーザーは、 rebar3.cmd ファイルが追加されていることを確認する必要があります。

@echo off
setlocal
set rebarscript=%~f0
escript.exe "%rebarscript:.cmd=%" %*

ソースからのビルド

まずgitがインストールされていることを確認し、リポジトリをチェックアウトしてビルドします。

$ git clone https://github.com/erlang/rebar3.git
$ cd rebar3
$ ./bootstrap

これにより rebar3 スクリプトファイル(Windowsの場合は rebar3.cmd ファイルも)が作成されます。

ローカルインストール

ローカルインストール形式では、これまでにビルドした任意のRebar3バージョンを取り、ローカルディレクトリに展開できます。ツールは後でそこから自己更新できるようになります。

$ ./rebar3 local install  # PATHに通っていないrebar3から開始
===> Extracting rebar3 libs to ~/.cache/rebar3/lib...
===> Writing rebar3 run script ~/.cache/rebar3/bin/rebar3...
===> Add to $PATH for use: export PATH=$PATH:~/.cache/rebar3/bin
$ export PATH=$PATH:~/.cache/rebar3/bin
$ rebar3 local upgrade # これは最新の安定版に更新するために使える
...

エディタの設定

エディタに依存しない方法(言語サーバー経由)

言語サーバーは、コード補完・定義へのジャンプ・インラインの診断といった言語機能を提供する、エディタに依存しないソリューションです。Erlang LS言語サーバーは、Erlangプログラミング言語向けにこれらの機能を実装しています。Emacs、VS Code、Sublime Text 3、Vim、そしておそらくLSPプロトコルに準拠する他の多くのテキストエディタやIDEと統合できます。

特定のテキストエディタでErlang LSを使い始めるには、ドキュメントの「editors」セクションを参照してください。

Visual Studio Code

Pierrick Gourlain氏によるErlang拡張機能がお勧めです。

拡張機能を設定するには、「Preferences」メニューから「Settings」を選びます。VS Codeのウィンドウ内で「Extensions」メニューを展開し、「erlang configuration」セクションまで進みます。すべての値が正しいこと、特にErlangのパスとRebar3のパスが正しいことを確認してください。これが済めば、他のお好みの拡張機能を自由に組み合わせて使う準備が整います。

コードフォーマッタは少し扱いにくく感じられるかもしれません。公式Erlangリポジトリの古いルールに従ってタブとスペースを混在させ、タブ幅は8スペースであることを前提としています。これは他ではあまり使われていない設定であり、もしVisual Studio Codeがそのように設定されていない(たとえば4スペースを使っている)場合、見た目がおかしくなってしまいます。

それ以外の点では、この拡張機能は主要な機能をすべてカバーしています。コード定義間のジャンプ、ビルドツールのサポート(コマンドパレットでは compile・eunit・dialyzer のみサポートされていますが、ターミナルから直接 rebar3 を呼び出すこともできます)、インテリセンス、入力しながらの警告表示、そしてCodeLens機能です。拡張機能のドキュメントを見れば、デバッガのサポート手順も見つかります。

あとは、お好みに合わせてテーマやその他の一般的な拡張機能を設定するだけです。

Emacs

Erlang/OTPには tools アプリケーション( lib/tools/emacs/ )内にEmacsモードが同梱されています。Emacsを使う本書の著者たちは、インストールされている最新のErlangバージョンから直接ロードする形でこのモードを使い続けています。 erlang-mode をより高度にサポートするための代替モードやアドオンにはいくつも選択肢がありますが、ここではIvyによる補完とFlycheckによる構文チェックのみを扱います。ただしその前に、パッケージ設定を分離するツールであるuse-packageが必要です。 use-package を自動インストールするコードはここにあります。起動時に use-package がインストールされるよう、このコードを ~/.emacs.d/init.el に含めてください。あるいは use-package のウェブサイトにあるインストール手順を使ってください。

次の elisp コードは、IvyやFlycheckを使わずに erlang-mode だけをセットアップし、Rebar3・Relxやその他のErlang設定ファイル用にロードするために使えます。

(use-package erlang
  :load-path ("<PATH TO OTP>/lib/erlang/lib/tools-3.0/emacs/")
  :mode (("\\.erl?$" . erlang-mode)
         ("rebar\\.config$" . erlang-mode)
         ("relx\\.config$" . erlang-mode)
         ("sys\\.config\\.src$" . erlang-mode)
         ("sys\\.config$" . erlang-mode)
         ("\\.config\\.src?$" . erlang-mode)
         ("\\.config\\.script?$" . erlang-mode)
         ("\\.hrl?$" . erlang-mode)
         ("\\.app?$" . erlang-mode)
         ("\\.app.src?$" . erlang-mode)
         ("\\Emakefile" . erlang-mode)))

Ivyによる補完サポートを得るには、 ivy-erlang-complete パッケージを追加し、使用するErlangルートをカスタム設定した上で、Erlangモードが設定されたときにその init を実行します。

(use-package ivy-erlang-complete
  :ensure t)

(use-package erlang
  :load-path ("<PATH TO OTP>/lib/erlang/lib/tools-3.0/emacs/")
  :hook (after-save . ivy-erlang-complete-reparse)
  :custom (ivy-erlang-complete-erlang-root "<PATH TO OTP>/lib/erlang/")
  :config (ivy-erlang-complete-init)
  :mode (("\\.erl?$" . erlang-mode)
         ("rebar\\.config$" . erlang-mode)
         ("relx\\.config$" . erlang-mode)
         ("sys\\.config\\.src$" . erlang-mode)
         ("sys\\.config$" . erlang-mode)
         ("\\.config\\.src?$" . erlang-mode)
         ("\\.config\\.script?$" . erlang-mode)
         ("\\.hrl?$" . erlang-mode)
         ("\\.app?$" . erlang-mode)
         ("\\.app.src?$" . erlang-mode)
         ("\\Emakefile" . erlang-mode)))

FlycheckはRebar3のサポートを備えており、Rebar3プロジェクトを自動的に検出できるため、必要なのは flycheck パッケージだけです。

(use-package delight
  :ensure t)

(use-package flycheck
  :ensure t
  :delight
  :config (global-flycheck-mode))

use-package に対する :config (global-flycheck-mode) という引数によって、Emacsで編集するすべてのコードに対してFlycheckが有効になります。 :config で指定した式は、パッケージがロードされた後に実行されます。 :delight という引数は、モードラインにFlycheckを表示しないようにするため、 use-package に delight ユーティリティを使うよう指示するものです。モードラインから外しておくことでスペースを節約でき、特にグローバルに有効化されている場合は現在有効であるとわざわざモードラインに表示する必要もありません。

Flycheckを使うのが好みなら、エラーの全リストを順に追いながら表示するためにhydraをチェックしてみる価値があります。Hydraマクロは、最初のHydraバインディングが実行されたときにのみ機能する短いキーバインディングをセットアップします。次のコードは、 C-c f が呼び出されたときにFlycheckのエラーを表示するための基本的なバインディングをセットアップします。

(use-package hydra
  :defer 2
  :bind ("C-c f" . hydra-flycheck/body))

(defhydra hydra-flycheck (:color blue)
  "
  ^
  ^Errors^
  ^──────^
  _<_ previous
  _>_ next
  _l_ list
  _q_ quit
  ^^
  "
  ("q" nil)
  ("<" flycheck-previous-error :color pink)
  (">" flycheck-next-error :color pink)
  ("l" flycheck-list-errors))

最後に、Erlang専用ではないもののプロジェクト開発時にとても役立つパッケージをいくつか紹介します。

  • magit: Git用のEmacsインターフェースです。MagitはEmacsからGitを呼び出せるだけでなく、変更のステージングからインタラクティブなリベースまで、あらゆる作業のための洗練されたインターフェースを提供します
  • counsel-rg : counselは、先ほどErlangの補完で使ったIvyパッケージを利用するコマンド集です。 counsel-rg はripgrepを使ってプロジェクト内のファイルを横断して文字列を検索します。gitプロジェクト内では git grep のように振る舞い、gitリポジトリ内のファイルのみを検索し、 .gitignore を尊重します。ripgrepは外部コマンドであるため別途インストールが必要です。たとえばUbuntuやDebianでは sudo apt-get install ripgrep を実行してください。 ripgrep がインストールされていれば、 ivy-erlang-complete からもより高速な検索に利用されます
  • swiper: Ivyを使ったバッファ内検索のための isearch の代替です
  • company-mode: company-erlangを通じて ivy-erlang-complete と組み合わせると、このモードは補完候補を自動的にポップアップ表示するようになり、補完をミニバッファに表示するために C-: を使う必要がなくなります
  • flycheck-inline、flycheck-pos-tip、flycheck-popup-tip: これらのパッケージは、Flycheckのエラーをミニバッファではなくエラー箇所に表示するための様々な選択肢を提供します

Vim

GitHub上のvim-erlangグループが可能にしているように、Vimでも非常に凝ったErlangサポートは可能ですが、Vimを使う本書の著者は、できる限り最小限の設定にとどめる傾向があります。

.vimrc ファイルではデフォルトのシンタックスハイライトのままにしておき、それがすべての適切なファイルタイプで使われるようにするだけです。

"also erlang
autocmd BufRead,BufNewFile *.erl,*.es.*.hrl,*.xrl,*.config setlocal expandtab noautoindent
au BufNewFile,BufRead *.erl,*.es,*.hrl,*.xrl,*.config setf erlang

これは当然ながら非常に基本的な内容です。もっと凝った統合も可能ですが、vimを使っている著者はほぼこれだけを使い、あとはターミナルでのRebar3に言語のその他の面倒を任せています。