Emacs ApplicationDevelopment

kiwanami

自己紹介

● kiwanami● さくらいまさし● 福岡で医療系のソフトウエア研究開発● ユーザーインタフェースに注目

過去

● kansai-emacs #2 : deferred.el● kansai-emacs #3 : 3D demo● kansai-emacs #4 : Emacs and async

● fukuoka-emacs #2 : skype.el● fukuoka-emacs #3 : world cafe● YAPC Asia 2011 : Emacs and DBI

Emacsでのアプリケーション開発とは？

Emacs Levels

● 使う、設定、カスタマイズ● 自前関数・コマンド

　　<< 壁 >>● メジャーモード● Emacsアプリ

Emacsアプリ開発の難しさ

● そもそもエディタである● スタートラインがはるか後方

● データの持ち方、部品がすこし独特● Emacs World に慣れる

● エディタのオブジェクトとスコープの理解

→ 霧を抜けると別世界

トピック

Emacsアプリ開発のとりかかり

● スコープ● データはどこへ保存するべきか

● 作り方・設計● エディタの上でどう作るか

データはどこへ保存するべきか？

言語的スコープ

● ローカル変数● グローバル変数● レキシカルスコープ● ダイナミックスコープ

→ 変数がどう見えるか

Emacsの主要オブジェクト

● バッファ→ ファイル、データ

● フレーム（端末）● ウインドウ

→それぞれにデータをひも付けることが出来る

A B C

アプリにとってのスコープ

● セッションデータ● Emacsでアプリ動作中に保持しているデータ

● 永続データ● Emacsが終了しても残るデータ

永続データ

● アプリ起動時に読み込みたい→ ローカルファイル例：recentf, anything, ac, elmo など多数

● ネットワーク経由で読み込みたい

→ ネットワーク例：navi2ch, cacoo, calfw-ical など

● データベース

→ 外部プログラム（ほとんど無いに等しい）

セッションデータ

● バッファにひもつけたい場合→バッファローカル

● バッファにまたがる場合

→グローバル

セッションデータ（続）

● グローバルは避けてなるべく狭いスコープ● 複数起動、組み合わせ

→ バッファローカル、クロージャ● グローバルに置く場合

● 単なる変数アクセスでなく、関数経由でのアクセスに限定する

● その他テクニック● コントロール用バッファ、親子バッファ

データの置き方はわかった。次は、どう作るか。

Emacsの自然な形式

● アプリケーションの境界がバッファ● バッファローカル変数 → model● バッファ → view● keymap/コマンド → controller

→ ほとんどがこの形

問題

● バッファごとに独立している● たくさんviewを組み合わせたい時は？

例：ECB, gdb

● バッファ間の関係● 独立か親子関係か、全員killするべきか

● バッファがたくさんある場合のウインドウ管理● 独自制御だと混ぜられない

例：wl, lookup, popwin, e2wm

UI部品：低レベル

● ボタン● 形(face)、キー・マウス(keymap)● action-lock

● レイアウト● 固定幅フォント、ウインドウ幅・高さ● 右寄せ、左寄せ、中央寄せ

● ポップアップメニュー● 普通のメニュー、GUIメニュー● anything などの minibuffer 系● popup.el などの overlay 系

UI部品：高レベル

● テーブル● みんな自前実装：dired, list-processes, list-buffers● ctable.el

● ツリー● tree-widget (widgetのパーツ)● dire-x.el

● フォーム● widget か独自実装

フォームライブラリ widget

● Emacs標準添付● 歴史が古く、かなり独特の世界● 作り手にとってはかなりつらい

● 必要なコード量多すぎ● 融通が効かない● Hackしまくりで混ぜられない

→ Webのフレームワーク相当が必要

Emacs Lisp 言語方面

● GUIはOOPによる設計が自然でノウハウも多い● Emacsでのオブジェクトシステム

● defstruct, eieio(CLOS)● 独自OOP実装多い

– luna, widget, ewoc, e2wm, skype– eieio の標準添付で統一されるか？

現状のまとめ

● バッファをまたぐ場合は、データのスコープやバッファ間の関係が重要

● CLOS知らなくても作れるが、後で便利● Emacs上でのUI構築はまだまだ発展途上● フォーム作る場合は widget しかない

→ フレームワークの登場が待たれる!!!

既視感

● 画面遷移をまたぐ場合は、データのスコープや画面間の関係が重要

● prototype知らなくても作れるが、後で便利● ブラウザ上でのUI構築はまだまだ発展途上● UI作る場合はDOMの理解が重要

→ フレームワークが乱立中!!!

JSによるアプリ開発と現状そんなに変わらない!!!

Emacsで幸せ実現!!!