今回 Emacs Lisp の実装ガイドラインを改訂し新たなポリシーとして再定義した。整理したポリシーを一文で言えば、Emacs 設定を数十年単位で壊さず維持するための設計規約である。本稿で扱うポリシーは、Emacs 設定を単なる一時的なカスタマイズではなく、数十年単位で維持する個人インフラとして扱うための設計規約である。中心にあるのは、新しい機能を積極的に取り込むことではない。過去の設定を壊さず、歴史的挙動を守りながら、必要な進化だけを上層に積み増していくことである。この前提に立つと、Emacs Lisp の実装方針は単なる書き方の好みではなく、長期互換性、変更耐性、依存関係制御、移行コスト管理を含むアーキテクチャ論になる。GNU Emacs は長い歴史を持ち、古い設定や古い Lisp 資産が現在でも継続して使われる珍しい環境であるため、この視点は誇張ではない [1][2][3]。
一般的なモダン設定では、新しい UI、completion framework、LSP、tree-sitter、外部 package 群を積み上げて快適さを得る構成が多い。しかし、その快適さは upstream の更新、パッケージの保守状況、依存関係の変動、Emacs 本体の API 変化に強く依存する。短期的には合理的でも、長期的には rewrite、設定崩壊、起動不能、使い慣れた操作系の破壊に結びつきやすい。本稿のポリシーは、その逆側に位置する。すなわち、stable core を保ち、変わりやすい要素は optional extension として切り離し、API 変化は compatibility layer で吸収し、依存関係は最小限に抑える。要するに、Emacs 設定を「長く使うこと」それ自体を設計目標に据えるのである。
1. ポリシーの中心思想は「過去の設定を壊さないこと」である
このポリシーの最重要原則は、過去に動いていた設定をできるだけ壊さないことである。ここで言う「壊さない」とは、単に起動時エラーを出さないという意味ではない。長年使ってきたキーバインド、フック、関数の呼び出し順序、暗黙の前提、作業手順、体で覚えた workflow を含めて維持するという意味である。Emacs 設定は単なる記述ファイルではなく、個人の運用史そのものが沈殿したプログラム資産である。したがって「古いから整理する」「モダンではないから書き直す」という発想は、このポリシーでは正当化理由にならない。歴史的挙動が保持されていること自体が価値だからである。
GNU Emacs は長年にわたり後方互換性を重視してきた。公式の履歴資料を見ると、1970 年代の起源から GNU Emacs の継続的発展に至るまで、古い利用資産の継承が文化として根付いていることが分かる [2][3]。このため、本ポリシーは Emacs の文化に逆らうものではなく、むしろその極端に安定志向な側面を、個人設定のレベルまで意識的に延長したものといえる。
| 観点 | 一般的なモダン設定 | 本ポリシー |
|---|---|---|
| 最優先事項 | 新機能の導入と現在の快適性を優先する。 | 歴史的挙動の保持と長期安定性を優先する。 |
| 古いコードの扱い | 古い実装は整理や rewrite の対象になりやすい。 | 動いている限り資産として保持し軽々しく触らない。 |
| 設定の位置づけ | 編集環境の現在形を作るための設定ファイルである。 | 長期運用される個人インフラの構成要素である。 |
2. Emacs 設定は短命な設定ではなく長期プログラム資産である
通常のアプリケーション設定は、OS 更新や製品更新のたびに作り直されても大きな問題にならない場合が多い。しかし Emacs では事情が異なる。.emacs、init.el、自作 elisp、独自コマンド、個人用ライブラリが何年も何十年も継承されることが珍しくないからである。Emacs Lisp Reference Manual が示すように、Emacs は拡張可能な Lisp 環境そのものであり、利用者は editor の利用者であると同時に、自分自身の環境を実装する開発者でもある [1][4]。この構造では、設定とコードの境界は薄くなる。
このため、Emacs 設定は disposable configuration ではなく long-lived asset として扱う方が合理的である。ここで重要なのは、資産とは単にコード量の多さを指さないことだ。長年使われてきた設定には、edge case への対応、微妙な環境差の吸収、作業手順に最適化された操作系、壊れやすい順序関係を避ける経験則などが含まれている。これらはソース中に明示されていなくても、実際には高い価値を持つ。したがってこのポリシーは、設定の寿命を「その日の快適さ」ではなく「人間の生命に近い長さ」で評価する。
| 対象 | 一般的な寿命感覚 | 長期運用ポリシーでの見方 |
|---|---|---|
| 一般アプリ設定 | 数年単位で作り直しても大きな問題になりにくい。 | 本稿の中心対象ではない。 |
| shell 設定 | 10 年以上継承されることが多い。 | 長期資産として扱うべき代表例である。 |
| Emacs 設定 | 20 年規模で継承されても不自然ではない。 | 個人インフラとして設計するべき対象である。 |
3. バージョン番号ではなく機能の存在で分岐する
このポリシーの実装原則として特に重要なのが、version check ではなく capability detection を使うことである。Emacs は同じメジャーバージョンでも、distribution による patch、backport、feature backfill、ビルドオプション差の影響を受け得る。そのため「このバージョンだからこの機能があるはずだ」と決め打ちする設計は危険である。Debian のような distribution は policy に基づいて安定性と保守性を重視するため、上流版と現実の挙動が単純には一致しないことがある [5][6]。
Emacs Lisp には、そのための素直な手段が用意されている。関数存在確認には fboundp、変数存在確認には boundp、feature の有無には featurep を用いる。さらに、JSON のように新旧 API が共存し得る領域では、現在の環境に存在する実装だけを選択する方が安全である [7][8]。つまり重要なのはバージョン表記ではなく、実際に今この環境で呼べるかどうかである。
| 判定対象 | 使う手段 | 意味 |
|---|---|---|
| 関数 | fboundp | その関数が現在の環境で呼び出し可能かどうかを確認する。 |
| 変数 | boundp | その変数が現在の環境で束縛済みかどうかを確認する。 |
| feature | featurep | その機能集合が読み込み済みで利用可能かどうかを確認する。 |
4. Stable Core と Optional Extension を分離する
長く使う設定を壊れにくくするためには、変わりにくい部分と変わりやすい部分を同じ層に置かないことが重要である。Emacs 設定で変わりにくいのは、基本 Lisp、builtin package、長年使ってきた基本操作、歴史的に維持したい挙動である。一方で、変わりやすいのは tree-sitter、icons、completion framework、外部 package、現代的 UI のような周辺拡張である。これらを同一層に混在させると、周辺拡張の不安定さが core に侵入し、起動不能や workflow の破壊を引き起こしやすくなる。
したがって、このポリシーでは stable core を先に確立し、その上に optional extension を重ねる。Emacs 29 以降では tree-sitter 機能が利用できるが、公式マニュアルも treesit-ready-p や parser の準備状況を確認しつつ利用する前提で記述している [9][10][11]。これは「機能がある環境でだけ上積みする」という思想と整合する。旧環境では core だけで動き、新環境では extension が加わる。この非対称性こそが長寿命の鍵になる。
| 層 | 主な内容 | 設計上の役割 |
|---|---|---|
| Stable Core | 基本 elisp、builtin package、歴史的設定、古い Emacs でも動く処理を置く。 | 数十年単位で生存させる土台として扱う。 |
| Optional Extension | tree-sitter、icons、modern UI、外部 package、強化機能を置く。 | 利用可能な環境でだけ有効化し土台を汚染しない。 |
5. API 変更は Compatibility Layer で吸収する
API が変化したとき、多くの設定では「古いコードを書き換える」という判断になりやすい。しかしこのポリシーでは、まず compat layer を挟めないかを考える。理由は単純で、既存コードに直接手を入れると、見えている API 呼び出しだけでなく、歴史的に積み重なった期待値まで変えてしまうからである。Emacs Lisp Manual が示す loading、features、byte compilation の構造を踏まえると、環境差や API 差を局所的に吸収するための薄い adapter を置くことは十分に自然である [4][12][13]。
構造は「historical code → compatibility layer → current API」である。この方式では、修正点が compat layer に集中するため、変更の伝播が止まる。旧設定本体を温存したまま、新 API への移行だけを中間層で吸収できる。ソフトウェアアーキテクチャの用語で言えば、これは adapter や facade の考え方に近い。重要なのは、API 変更そのものをなくすことではなく、API 変更が core に直撃しない構造を事前に持つことである。
| 要素 | 役割 | 変更時の責務 |
|---|---|---|
| Historical Code | 長年使ってきた設定本体と歴史的挙動を保持する。 | 原則として直接変更しない。 |
| Compatibility Layer | 旧 API と新 API の差分を局所的に吸収する。 | 新旧差分が出たとき最初に調整する場所とする。 |
| Current API | Emacs 本体や周辺機能の現在の呼び出し先である。 | 変化しても core へ直接波及させない。 |
6. 依存関係は最小化し、外部 package は任意にとどめる
依存関係は利便性をもたらすが、同時に不安定性の流入口でもある。外部 package は API 変更、保守者不在、repository 消失、非互換更新の影響を受けやすい。MELPA は Emacs エコシステムに大きな活力を与えてきたが、長期運用という観点では「ある日なくなるかもしれない」ことを前提に扱う方が安全である [14]。一方で package.el の仕組み自体は Emacs 本体に組み込まれており、公式 manual でも package archive や package file の扱いが整理されている [15][16]。
したがって、このポリシーでは優先順位を builtin、optional packages、MELPA の順に置く。ここで重要なのは「MELPA を使うな」ではない。「MELPA に core の生存を依存させるな」である。機能が減ることは許容しても、起動不能になることは許容しない。graceful degradation を前提に、外部 package は optional extension として切り離す。これにより package 消滅や API break の被害は edge に閉じ込められる。
| 優先順位 | 依存先 | 採用理由 |
|---|---|---|
| 1 | builtin | 本体と一緒に配布され長期互換性と保守性が高い。 |
| 2 | optional packages | 利便性を得つつ無くても core が生き残る構造を作りやすい。 |
| 3 | MELPA | 有用だが長期安定性より変化の速さを前提に扱うべきである。 |
7. Rewrite を避け、Incremental Evolution を選ぶ
このポリシーが大規模 rewrite に否定的なのは、保守的だからではない。rewrite は最も破壊的な変更だからである。長く使われた設定には、見えていない依存、微妙な挙動、暗黙の前提、慣れた操作順序が蓄積されている。ソースを現代的に書き直しただけでも、interactive な振る舞い、hook の順序、読み込みタイミング、エラー時の退避動作などが変わり得る。GNU Coding Standards でも、保守性や明確さは重要視されるが、それは利用者環境の破壊を正当化するものではない [17]。
したがって本ポリシーは「動いているコードは高い価値を持つ」という前提に立つ。コードの古さ、見た目の古臭さ、現代的でない style は、それ単独では rewrite の理由にならない。必要な変更がある場合は、compat layer の導入、optional extension への切り出し、条件付き分岐の追加など、局所的な手段で吸収する。ここでの基本姿勢は rewrite ではなく incremental evolution であり、変化を小さく、影響範囲を狭く、目的を限定して実施することである。
| 変更手法 | 短期的な見え方 | 長期運用上の評価 |
|---|---|---|
| 大規模 rewrite | 見た目は整理され近代化されたように見える。 | 隠れた依存や身体化された workflow を壊す危険が高い。 |
| 局所的な修正 | 地味で古いコードが残るように見える。 | 影響範囲が小さく履歴資産を保存しやすい。 |
| compat layer の追加 | コード量は増えるが意図は明確になる。 | 変更の伝播を止めるため長期運用に向く。 |
8. Deprecated API は監視するが、壊れるまで消さない
長期設定の敵は突然の全面崩壊ではなく、ゆっくり進む API 非推奨化である。Emacs Lisp には byte compilation があり、警告やエラーは Compile-Log を通じて把握できる [13][18][19]。このポリシーでは byte-compile warnings を健康診断として使う。つまり、非推奨 API の兆候を早めに検知し、必要なら compat layer を挟み、条件分岐や代替呼び出しを用意する。しかし、警告が出たからといって即座に旧コードを全面削除するわけではない。
重要なのは、deprecated であることと、今すぐ実害があることを区別することである。警告は将来リスクのシグナルではあるが、即時の削除命令ではない。動いている歴史的コードを維持しながら、移行可能性だけを準備する。この姿勢により、利用者環境を守りつつ将来の変化にも備えられる。壊れない限り古いコードは消さないという原則は、怠慢ではなく、変更コストと資産価値を比較した結果の合理的判断である。
| 監視対象 | 確認手段 | 基本対応 |
|---|---|---|
| 非推奨 API | byte compilation の警告や関連文書の更新で把握する。 | まず互換層や条件分岐で吸収できないかを検討する。 |
| 未知の関数や変数 | Compile-Log や byte compiler のメッセージを確認する。 | 環境差か実装漏れかを切り分けて局所的に修正する。 |
| 将来の破壊的変更 | NEWS と manual の差分を追って予兆を把握する。 | 壊れる前に fallback を用意し本体は急に書き換えない。 |
9. Lexical Binding は現代標準として採用するが、互換性を壊すためには使わない
Lexical binding は現代の Emacs Lisp 実装で重要な基盤であり、公式 manual でも lexical binding の意味、dynamic binding との差、移行方法が整理されている [20][21][22]。予測しやすい scope、closure の自然な扱い、保守性の向上という観点から、現代的な設定では lexical-binding: t を明示することは合理的である。本ポリシーでも、各 .el ファイルでこれを標準にする方向は妥当である。
ただし重要なのは、これを modernization の象徴として振り回さないことである。lexical binding は長期保守性を上げるために使うのであって、古い環境や既存コードを切り捨てるために使うのではない。移行時には、dynamic binding を前提とした既存コードがどこにあるか、どの変数が意図的に動的であるべきかを確認しなければならない。つまり lexical binding の採用もまた、rewrite ではなく controlled migration として行うべきである。
| 論点 | 採用理由 | 注意点 |
|---|---|---|
| 予測可能性 | 変数の有効範囲が明確になり読みやすさが増す。 | 動的束縛を前提にした古いコードは挙動確認が必要である。 |
| 保守性 | closure や局所変数の扱いが安定し意図を保持しやすい。 | 移行時に暗黙の依存を壊さない配慮が要る。 |
| 標準化 | 現代の Emacs Lisp の実践として自然な基準になっている。 | 採用それ自体を目的化すると本来の長期互換思想を損なう。 |
10. 新しい UI と非同期処理は便利だが core に昇格させない
tree-sitter、parser-based font lock、icon package、高度な completion UI、非同期通信や非同期処理は、現代の Emacs における利便性を大きく向上させる。しかしそれらは変化頻度が高く、環境依存も強い。tree-sitter については、公式 manual 自体が grammar の存在、buffer サイズ、parser 準備状況など複数条件を前提に説明しており、常時利用を無条件に前提としていない [10][11][23]。また use-package も現在は Emacs 本体側に取り込まれているが、その利用は package-centered な設定文化を強めやすい [24][25]。
したがって、このポリシーでは新しい UI や async enhancement を optional extension として扱う。古い Emacs、minimal environment、remote environment、低依存環境でも core が維持されることを優先する。利便性向上は重要だが、それは core の生存と引き換えにしてよい価値ではない。高速化や視覚改善を重ねるときほど、それが失われても環境全体が倒れないように層を分けるべきである。
| 機能群 | 利点 | 本ポリシーでの位置づけ |
|---|---|---|
| tree-sitter 系機能 | 構文解析に基づく高精度な font lock や操作性向上を得られる。 | 環境条件が整う場合だけ有効化する optional extension とする。 |
| modern UI | 視認性や操作快適性を大きく改善できる。 | 無くても core の workflow が維持できるように設計する。 |
| async 処理 | 待ち時間の低減や応答性の改善に寄与する。 | 基本は synchronous とし可能な環境だけで強化する。 |
11. この設計は Debian 的でもあり UNIX 的でもある
本ポリシーは Emacs ローカルの奇妙な流儀ではない。むしろ Debian や UNIX の長期安定志向と構造的によく似ている。Debian Policy は distribution 全体の整合性と安定性を強く意識しており、技術的要求だけでなく、環境全体を壊さない構造を重視する [5][6]。また UNIX 的思想では、小さな部品、安定した interface、漸進的変化、userspace を壊さない姿勢が重要視される [26]。
Emacs 設定を長期運用インフラとして扱うと、同じ論理が自然に現れる。stable core は base system に相当し、compat layer は transitional package や wrapper に相当し、optional extension は Suggests や Recommends 的な任意拡張に近い。つまりこのポリシーは「Emacs 設定を OS レベルの基盤と同じ発想で設計する」立場であり、その意味で Debian 的、UNIX 的なのである。
| Emacs 側の要素 | Debian / UNIX 側の対応 | 共通する思想 |
|---|---|---|
| Stable Core | base system や壊してはならない userspace に近い。 | 土台の安定性を最優先し上で進化させる。 |
| Compatibility Layer | wrapper、compat package、移行吸収層に近い。 | 変更を局所化して既存利用資産を守る。 |
| Optional Extension | 任意 package や追加機能群に近い。 | 無くても全体は動くという構造を維持する。 |
12. POSIX shell の長期運用設計とも強く似ている
このポリシーは Emacs Lisp 専用の発想に見えるが、実際には POSIX shell の長期運用設計ともよく似ている。/bin/sh で動く最小コアを保ち、bash 専用機能は可能なら optional にし、command -v で capability detection を行い、環境差は wrapper で吸収する。ここでも中心は portability と stability であり、convenience はその上に載る。GNU の文書群や POSIX 的運用文化を見ても、長寿命スクリプトでは「存在するなら使う、無ければ fallback する」という設計が自然である [17][26]。
Emacs 側で fboundp、boundp、featurep を使うことは、shell 側で command -v や wrapper 関数を使うことに近い。つまり、本ポリシーは editor customization というより long-lived script asset の設計原則である。言い換えれば、対象言語は Emacs Lisp だが、思想の所属先は運用設計である。
| shell 設計の要素 | Emacs 設計での対応 | 共通する原則 |
|---|---|---|
| POSIX sh を土台にする | 基本 elisp と builtin を土台にする。 | 安定した最小コアを先に確立する。 |
| command -v による確認 | fboundp や featurep による確認を行う。 | 実在する機能だけを利用する。 |
| wrapper 関数で環境差を吸収する | compatibility layer で API 差を吸収する。 | 変更の影響範囲を局所化する。 |
13. 一般的な Emacs 設定文化との違いをどう見るべきか
現在の Emacs 利用者全体を見れば、このポリシーは主流派ではない。use-package、completion framework、LSP、tree-sitter、外部 package を組み合わせて productivity を高める設定は非常に多いし、Doom Emacs や Spacemacs のような distribution 型の利用も一般的である [24][25]。この文化では、Emacs は editor productivity tool として使われやすく、環境の寿命よりも現在の快適性が重視される。
一方、本ポリシーは operations-oriented である。editor の快適さを否定するのではなく、それを core ではなく edge に置く。新しい package を否定するのではなく、それが無くても動くように構造化する。したがって本ポリシーは「保守的だから新しいものを嫌う」のではなく、「新しいものを壊れやすい場所に隔離する」設計なのである。この違いを見誤ると、単なる old-fashioned な主張に見えてしまうが、実際には change containment を重視したアーキテクチャ論である。
| 設定文化 | 主目的 | 長期運用ポリシーとの違い |
|---|---|---|
| package 積み上げ型 | 現在の快適性と機能充実を重視する。 | 依存関係が増えやすく core まで不安定になりやすい。 |
| framework 型 | 完成済み環境を速く得ることを重視する。 | upstream の設計変更や upgrade 方針に従属しやすい。 |
| 長期運用型 | 数十年使える環境寿命と再現性を重視する。 | 派手さは少ないが変更耐性と継承性が高い。 |
14. このポリシーは Stable Core / Evolving Edge の時間軸アーキテクチャである
本ポリシーを抽象化すると、これは単なるモジュール分割ではなく、時間軸を設計対象にした architecture である。ソフトウェアの各部分は同じ頻度で変化しない。基本 Lisp、歴史的設定、builtin package は変化が遅く、UI、外部 API、外部 package、現代的拡張は変化が速い。したがって、low change rate の要素を core に、high change rate の要素を edge に分離するのが合理的である。compatibility layer はその中間で temporal decoupling を担う。つまり、変更の速度が違うものを同じ層に押し込めないための設計である。
この見方に立つと、本ポリシーは temporal architecture、あるいは separation by rate of change を個人設定に適用したものと理解できる。年単位で見ると、core はほとんど変えず、API 差が出たら compat layer を直し、時代に応じて extension を更新するだけで済む。結果として upgrade risk は下がり、rewrite cost は減り、workflow の継続性は高まる。つまり本ポリシーは、構造だけでなく時間に耐えるための設計なのである。
| 層 | 変更頻度 | 時間軸上の役割 |
|---|---|---|
| Stable Core | 非常に低い。 | 10 年から 30 年単位で維持する土台として残す。 |
| Compatibility Layer | 中程度である。 | API 変更や環境差が出たときだけ局所的に調整する。 |
| Evolving Edge | 高い。 | 時代に合わせて追加、交換、削除を行う。 |
15. 結論
ここまでの議論を一文でまとめるなら、このポリシーは「Emacs 設定を数十年運用可能な個人インフラとして設計する思想」である。核心は、過去の設定を壊さないこと、バージョン番号ではなく機能存在で分岐すること、stable core を保ち、変化しやすい要素を optional extension として分離すること、API 変更を compatibility layer で吸収すること、依存関係を最小化して graceful degradation を前提にすることである。これは Emacs Lisp の細かな style guide ではなく、long-lived configuration architecture である。
また、この設計は Emacs に固有の奇妙なこだわりではない。Debian 的な安定志向、UNIX 的な漸進的進化、POSIX shell の長寿命スクリプト設計、そしてソフトウェアアーキテクチャにおける Stable Core / Evolving Edge と同型である。したがって本ポリシーは、単なる editor customization の話ではなく、エンジニアの個人環境を職業人生に近い時間尺度で維持するための設計原則だと位置づけられる。長く使うほど、そして多くの breakage を経験するほど、この発想の合理性は増していく。
| 最終原則 | 意味 |
|---|---|
| Backward Compatibility First | 歴史的挙動と長年の workflow を最優先で守る。 |
| Capability Detection | バージョン番号ではなく実際に存在する機能だけを利用する。 |
| Stable Core | 長期生存させる土台を最小依存で維持する。 |
| Compatibility Layer | API 変更と環境差を中間層で局所的に吸収する。 |
| Optional Extension | 便利さは上層に積み増すが土台の生存と引き換えにしない。 |
参考文献
- GNU Emacs Lisp Reference Manual. https://www.gnu.org/software/emacs/manual/elisp.html
- GNU Emacs Release History. https://www.gnu.org/software/emacs/history.html
- GNU Emacs Further Information. https://www.gnu.org/software/emacs/further-information.html
- Top. GNU Emacs Lisp Reference Manual. https://www.gnu.org/s/emacs/manual/html_node/elisp/
- Debian Policy Manual. https://www.debian.org/doc/debian-policy/
- Debian Policy Manual PDF. https://www.debian.org/doc/debian-policy/policy.pdf
- Parsing JSON. GNU Emacs Lisp Reference Manual. https://www.gnu.org/software/emacs/manual/html_node/elisp/Parsing-JSON.html
- Package Files. GNU Emacs Manual. https://www.gnu.org/software/emacs/manual/html_node/emacs/Package-Files.html
- Using Tree-sitter Parser. GNU Emacs Lisp Reference Manual. https://www.gnu.org/software/emacs/manual/html_node/elisp/Using-Parser.html
- Developing Major Modes with Tree-sitter. GNU Emacs Lisp Reference Manual. https://www.gnu.org/software/emacs/manual/html_node/elisp/Tree_002dsitter-Major-Modes.html
- Parser-based Font Lock. GNU Emacs Lisp Reference Manual. https://www.gnu.org/software/emacs/manual/html_node/elisp/Parser_002dbased-Font-Lock.html
- Loading. GNU Emacs Lisp Reference Manual. https://www.gnu.org/software/emacs/manual/html_node/elisp/Loading.html
- Compiler Errors. GNU Emacs Lisp Reference Manual. https://www.gnu.org/s/emacs/manual/html_node/elisp/Compiler-Errors.html
- MELPA. https://melpa.org/
- Simple Packages. GNU Emacs Lisp Reference Manual. https://www.gnu.org/software/emacs/manual/html_node/elisp/Simple-Packages.html
- use-package User Manual. https://www.gnu.org/software/emacs/manual/html_mono/use-package.html
- GNU Coding Standards. https://www.gnu.org/prep/standards/
- Byte Compilation. GNU Emacs Lisp Reference Manual. https://www.gnu.org/s/emacs/manual/html_node/elisp/Byte-Compilation.html
- Compilation Functions. GNU Emacs Lisp Reference Manual. https://www.gnu.org/s/emacs/manual/html_node/elisp/Compilation-Functions.html
- Lexical Binding. GNU Emacs Lisp Reference Manual. https://www.gnu.org/software/emacs/manual/html_node/elisp/Lexical-Binding.html
- Converting to Lexical Binding. GNU Emacs Lisp Reference Manual. https://www.gnu.org/software/emacs/manual/html_node/elisp/Converting-to-Lexical-Binding.html
- How let Binds Variables. An Introduction to Programming in Emacs Lisp. https://www.gnu.org/software/emacs/manual/html_node/eintr/How-let-Binds-Variables.html
- Language Grammar. GNU Emacs Lisp Reference Manual. https://www.gnu.org/software/emacs/manual/html_node/elisp/Language-Grammar.html
- History. use-package User Manual. https://www.gnu.org/software/emacs/manual/html_node/use-package/History.html
- Byte-compiling. use-package User Manual. https://www.gnu.org/software/emacs/manual/html_node/use-package/Byte_002dcompiling.html
- Unix Philosophy. https://en.wikipedia.org/wiki/Unix_philosophy