Emacs: すべてはサービスに見えるクライアント構築モデル

Emacs は単なるエディタではなく、OS カーネルレベル以上の機能を統括・制御できる強力なプラットフォームであり、事実上「オペレーティングシステムとして機能」する能力を備えています。このため、「Emacs で生活する」という考え方も根拠を持って成り立ちます。

本稿では、Emacs がどのようにしてクライアント側を構築し、すべての外部サービスを内部の関数として表現できるかを検証します。

---

クライアント・サーバーモデル

まず前提となる概念を確認します。

• 基本定義

  • リソースを提供する側（サーバー/サービス）と、リソースを求める側（クライアント）間でタスクを分割する相互作用の模式図です。
  • クライアントはサーバーへリクエストを送り、サーバーから応答を受けます。

• 通信の範囲

  • 取引はネットワーク越しに行われることもあれば、システム内での局地的処理でも可能です。
  • REST スタイルのソフトウェアアーキテクチャにおいて、このモデルが一般的です。

---

Emacs をクライアントとして捉える

Emacs は以下の 3 つの主要コンポーネント（懸念点）を完備しており、これらを組み込みライブラリまたはサードパーティ製パッケージで実装可能です。

1. UI（ユーザインタフェース）

必要な場合のみ起動され、ユーザーと対話するための層です。

• ミニバッファ: 入力や出力の表示領域
• バッファ: ファイルやプロセスの表示ウィンドウ
• コンプリート (補完): タブレットキーで機能名などを補完する機能
• 表付きリスト表示モード: 構造化データの可視化
• 可変ピッチテーブル (vtable): メタ情報（バッファ、ファイル等）を管理
• テンポラリー: トランジエント（一時）なデータ領域

2. クライアントエッジ

サービスとの通信を担うサブシステムです。

• URL 操作:

  url-retrieve

  や

  url-generic-parse-url

  など
• ソケット (TCP/UDP): 直接のネットワーク通信
• SMTP: メールクライアントとしての機能
• シリアライゼーション: データの形式変換（JSON, XML など）

3. ローカルデータベース

サーバーと同期されるデータの表層表現です。実装要件により管理方法が異なります。

• 集合体
• アソシエーションリスト
• プロパティリスト
• ハッシュテーブル
• SQLite: リレーショナルデータベースの利用

💡 設計の柔軟性

• 実装要件は、Emacs クライアントの複雑さを決定します。
• 「重い作業」を処理できる既存のコマンドラインユーティリティがあれば、それを事実上のサービスとして再定義し、シェルコール経由でアクセスできるように可能です。

---

Elisp: 統括言語としての役割

上記すべての機能は、**Emacs Lisp (Elisp)**という動的プログラミング言語を通じてアクセスされます。

• 特徴: 実行時の高い自由度によるアドホックな動作が可能。
• 達成すること: Emacs がアクセス可能なあらゆる振る舞い（Elisp 関数からシェルコマンドまで）の複雑な統括を実現。

---

実践例:

wttr.in

天気予報クライアントの構築

外部天気予報サービス

wttr.in

を利用し、Emacs 内だけで天気情報を表示するクライアントを作成します。

エキゾースチブ・アプローチ（純粋な API クライアント）

Web サービスから JSON を取得し、それをパースしてミニバッファに表示します。

ステップ 1: URL の構築

wttr--request-url

関数で、場所名をエンコードした URL を生成します。

(defun wttr--request-url (location)
  "Construct wttr.in URL with LOCATION."
  (let* ((base-url (url-generic-parse-url "https://wttr.in"))
         (encoded-location (string-replace " " "+" location))
         (query (format "/%s?0&format=j1" encoded-location)))
    (setf (url-filename base-url) query)
    (url-recreate-url base-url)))

ステップ 2: JSON の取得とパース

fetch-json-as-hash-table

がネットワークリクエストを行い、JSON をハッシュテーブルへ変換します。

• unwind-protect

  : ダウンロードしたバッファを確実に削除しメモリリークを防ぐ。

• url-http-end-of-headers

  : HTTP メタデータヘッダーをスキップ。

(defun fetch-json-as-hash-table (url)
  "Fetch URL with expected JSON response and return a `hash-table'."
  (let ((data-buffer (url-retrieve-synchronously url)))
    (if (not data-buffer)
        (error "Failed to fetch data from %s" url)
      (unwind-protect
          (with-current-buffer data-buffer
            (goto-char url-http-end-of-headers)
            (json-parse-buffer :object-type 'hash-table))
        (kill-buffer data-buffer))))))

ステップ 3: データの抽出と表示

wttr--report-message

が JSON から温度や天気状況を抜き出し、人間が読みやすいフォーマットに変換してミニバッファへ出力します。

(defun wttr--report-message (jsondb)
  "Generate weather report message from JSONDB."
  (let* ((nearest-area (wttr--get-first jsondb "nearest_area"))
         (area-name (map-elt (wttr--get-first nearest-area "areaName") "value"))
         (region (map-elt (wttr--get-first nearest-area "region") "value"))
         (country (map-elt (wttr--get-first nearest-area "country") "value"))
         (current-condition (wttr--get-first jsondb "current_condition"))
         (temp_c (map-elt current-condition "temp_C"))
         (temp_f (map-elt current-condition "temp_F"))
         (weather-desc (map-elt (wttr--get-first current-condition "weatherDesc") "value")))
    
    (let ((area-list (list area-name region country))
          (full-area-string (string-join (reverse area-list) ", ")))
      (format "%s: %s°C, %s°F %s"
              full-area-string temp_c temp_f weather-desc))))

ステップ 4: メインコマンドの統合

上記モジュールを組み合わせて、ユーザーが場所名を入力すれば結果を表示する

wttr

コマンドを作成します。

(defun wttr (location)
  "Show weather conditions for LOCATION from `https://wttr.in' in mini-buffer.
Result is also stored in `kill-ring'."
  (interactive "sWhere (default: local): ")
  
  (condition-case err
      (let* ((url (wttr--request-url location))
             (jsondb (fetch-json-as-hash-table url))
             (msg (wttr--report-message jsondb)))
        (kill-new msg)
        (message "%s" msg))
    (error (message "ERROR: %s" (cdr err))))))

📊 コードの軽量化 実装した

wttr.el

のソースコードは、cloc ユーティリティでの計測によれば、わずか 67 行です。 Emacs の API は高いレベルの抽象化を提供しており、短くして済むのが特徴です。

---

エンド・ツー・エンド・アプローチ（シェルコマンドを利用）

Emacs が動的言語であるため、重厚な外部処理を Python スクリプト (

weather

) に行い、Emacs側は結果のみを扱うという代替案も可能です。

この場合、Elisp コードは以下のように単純化されます。

(defun weather (location)
  "Call weather script with LOCATION and show result in minibuffer."
  (interactive "sWhere (default: local): ")
  
  (let* ((weather-cmd "weather")
         (cmd (if location 
                  (format "%s %s" weather-cmd location) 
                weather-cmd))
         (result (shell-command-to-string cmd)))
    (kill-new result)
    (message result)))

• 役割の分離:

  weather

  スクリプトが事実上のサービスとなり、リクエストと処理を担当します。
• 統合の容易さ:

  Elisp

  は動的プログラミング言語であるため、外部ツールとの統合をアドホックに行いやすいです。

---

結論

上記の実装から明らかになりましたように、Emacs 内であればすべてはサービスに見えるのです。

1. 多様なライブラリで UI、通信、データ管理を実装可能。
2. Elispの動的特性により、外部ツール（API やシェルコマンド）を簡単に取り込める。
3. 「重たい作業」を外部にオフロードすることも、Emacs 内部で完結させることも自由自在。

この柔軟性が、「Emacs だけで生活する」というライフスタイルを支える基盤となっています。