el-getをインストールしたので、Wanderlustをel-getでインストールしようとしたらエラーになりました。

次のエラーメッセージが出ました。(gnupack emacs-24.3-20130503 / el-get version 5.1.1dce781)

el-get install apel
el-get: Package apel installed.
el-get: git submodule update ok
el-get: el-get-build apel: c:/app/emacs-24.3-20130503/bin/emacs -batch -q -no-site-file -l APEL-MK -f compile-apel prefix site-lisp site-lisp ok.
el-get: el-get-build apel: c:/app/emacs-24.3-20130503/bin/emacs -batch -q -no-site-file -l APEL-MK -f install-apel prefix site-lisp site-lisp ok.
apel failed to install: (error process byte-compile no longer connected to pipe; closed it) [2 times]
el-get-installation-failed: process byte-compile no longer connected to pipe; closed it

(el-get 'sync 'wanderlust)を評価して同期でインストールしようとするとこのエラーは出ないようなので(別のエラーは出るw)、非同期の時だけの問題のようです。

(let* (...略...
       (shell-file-name (or (and (eq system-type 'windows-nt)
                                 (executable-find "cmdproxy.exe"))
                            shell-file-name))
       ...略...)
  ...処理の本体...

;;; el-getが使用するshell-file-nameを決める。
;;; el-get-build内(el-get version 5.1.1dce781)で似たような判定をしているが、
;;; その関数内だけでは不十分。
(setq my-el-get-shell-file-name
   (or (and (eq system-type 'windows-nt)
            (executable-find "cmdproxy.exe"))
       shell-file-name))

;;; プロセスを呼び出す前に my-el-get-shell-file-name を適用する。
;;;
;;; el-get-build内(el-get version 5.1.1dce781)で同じような処理をしているが、
;;; それでは不十分。非同期インストールの時はel-get-build関数は処理の完了を
;;; 待たずに終わってしまうので。
(defadvice el-get-start-process-list (around my-el-get-start-process-list--modify-shell-file-name activate)
  (let ((shell-file-name my-el-get-shell-file-name))
    ad-do-it))

org-modeやらmagitやらWanderlustやら、Emacs Lispを最新版へ更新するのが億劫になってきたのでEmacsのパッケージ管理システムを検討してみました。

Emacs24からはpackage.elというのが標準で使えるようになったそうで、package-list-packagesでいきなりパッケージのリストが表示されるというお手軽さなのです。
でも、このシステムはパッケージのリポジトリへの登録にハードルがあるらしく、扱えるパッケージに限りがあるようなのです(参考:elispをpackageとel-get両方で管理する - $shibayu36->blog;)。

なので、el-getを試してみることにしました。公式サイトは dimitri/el-get です。

インストールは簡単で、scratchバッファなどから次のelispを実行するだけ。

;; So the idea is that you copy/paste this code into your *scratch* buffer,
;; hit C-j, and you have a working el-get.
(url-retrieve
 "https://raw.github.com/dimitri/el-get/master/el-get-install.el"
 (lambda (s)
   (goto-char (point-max))
   (eval-print-last-sexp)))

のはずだったのですが、Windows上でgnupackのemacs-24.3-20130503を使っていると落ちます。強制終了です。
どうも、httpsから任意のページをurl-retrieveしようとしただけで落ちるみたいです。
Emacs内部に組み込まれたgnutls、実際にはlibgnutls-28.dll内で問題が起きるようです。
解決方法は elpa形式じゃない野良elispをpackage-installする #Emacs @robario や cookieswap補助、gist.el、ちょっとtombloo - うぇぶとらばぁす にありました。

(eval-after-load
  "gnutls"
  '(setq gnutls-trustfiles (mapcar 'expand-file-name gnutls-trustfiles)))

gnutlsが読み込まれる前に上を実行しておけば(.emacsのel-getの設定等より先に書いておけば)落ちなくなりました。
どうもlibgnutls-28.dllがcygwin的なパスを認識できないことが原因のようです。expand-file-nameを通すことでWindows形式の絶対パスに展開され、落ちなくなるようです。

というわけで、無事にインストールできました。el-get-list-packageでパッケージの一覧を見ることが出来ます。iでマークしてxでインストールできます。

公式の Basic Setup のところに書いていますが、.emacsは次のようにすると良いみたいですね。

(add-to-list 'load-path "~/.emacs.d/el-get/el-get")

(unless (require 'el-get nil 'noerror)
  (with-current-buffer
      (url-retrieve-synchronously
       "https://raw.github.com/dimitri/el-get/master/el-get-install.el")
    (goto-char (point-max))
    (eval-print-last-sexp)))

(add-to-list 'el-get-recipe-path "~/.emacs.d/el-get-user/recipes")
(el-get 'sync)

こうすると、el-getがインストールされていなければ自動的にインストールされます。
.emacsをバージョン管理して他のマシンと共有している場合は便利ですね。

.emacsを共有している他のマシンにも同じパッケージを自動的にインストールしたいことがあると思います。
そういう場合は、

(el-get 'sync
  'color-moccur
  'magit
)

のように'syncの後にパッケージ名を書いておくと良いみたいです。(参考: 自分の el-get のワークフローについて整理する - そんなこと覚えてない)

git-encwrapper のバグを修正しました。

git-encwrapper は、gitのencoding属性(.gitattributesで指定)を活用してgit diffの出力の文字コードを統一したり、git applyの入力の文字コードを統一されたものから元に戻したりするgitラッパーです。

• エンコーディングを調整するラッパーを使ってMeadow上のMagitで部分的なstage(apply)をする

ところがCygwinを64bit版にしたときになぜかgit-encwrapperが動かなくなってしまいました。
原因を突き止めるのが面倒だったので、elisp側でなんとかするコードを書きました。

• 複数の文字符号化方式が混在しているときのmagit文字化け対策コード(magit 1.2.0用)
• my-magit-encoding.elの修正

今日 magit.el を開発最新版へ更新したら、案の定上のelispは使えなくなってしまいました。
magit.elの中をざっと見てみたのですが、プロセスを呼び出すところ(つまり、フックすべきところ)が沢山あり、
修正は大変そうでした。

なので、再びgit-encwrapperを復活させることにしました。

調査した結果、次の二つの問題が見つかりました。

• -cオプションを使っているとgitコマンド名を誤認識する不具合
• NULLポインタの判定ミス

前者は「git -c diff.submodule=short diff」のようなコマンドラインへの対応です。
ハイフンで始まらない一番最初のコマンドライン引数をコマンド名として扱っていたので、
「diff」ではなく「diff.submodule=short」がコマンド名だと認識されていました。

後者は単純なミスで、if(p)と書くべきところをif(*p)と書いていたというものです。
おそらくこれによって動いたり動かなかったりしていた模様です。

これらを修正したところ、おおむね正常に動いているようです。