GNU Emacs は、フリーソフトの世界で最も長く、継続的に開発されてきたアプリケーションの1つです。考え方によっては、30年以上を経て、これを複数世代のプロジェクトと見なすことができます。しかし、これだけ長寿であると課題もあります。Emacsコミュニティの多くの人たちは、そろそろエディタ内部のLispインタプリタを、より高速で最新のものにリプレースする時だと結論付けてきましたが、Emacsの大半が動作している基礎となる仮想マシンを入れ替えると、Lispによる Emacs特有の性質 に与える影響を含め、大規模な影響が出ます。

この話題は以前にも上がりましたが、最近では9月11日にChris WebberがEmacs開発リストに、Robin Templetonの Guile-Emacs への作業状況に関して質問を しています 。その名前から分かるように、Guile-Emacsは内部のEmacs Lispエンジンを GNU Guile インタプリタに入れ替えます。Guileインタプリタは元々 Scheme 言語（Lispの方言）をサポートするために書かれていましたが、今日はEmacs Lispを含む、その他の複数言語もサポートしています。

GuileのエンジンはEmacs内部のLispインタプリタよりも早いと報告されていますが、他にも並行性や、Guileをサポートする他の言語で書かれたEmacs拡張をサポートする可能性があるなど、貴重な機能を複数提供しています。この5年間、一連のGoogle Summer of Codeプロジェクトの中でGuile-Emacsに取り組んできたTempletonは、GuileのエンジンにEmacsをリベースする その他多くの利点を列挙しています 。その中には、 完全な数の階層、構造体型、CLOSベースのオブジェクト指向、外部機能インターフェース、限定継続、モジュールシステム、 健全なマクロ 、複数値、スレッドなど が含まれています。今のところ、TempletonはGNU Emacsの中にあるモジュールの大半は、評判のいいかなりまとまった外部の拡張一式と同様、Guile-Emacs上で安定して動作していると報告しています。

しかし、EmacsをGuileインタプリタ上に移植するとなると、考慮すべきはるかに厳しい要件があります。ユーザは、全てのEmacs拡張――サードパーティーの拡張と自分のパーソナルコードの両方を含むが、問題なく動作し続けることを期待しています。これは大変な難題です。Eli Zaretskiiが 指摘した とおり、GuileはGNUのユーティリティを欠いたシステム上ではあまり安定していません。それに、GuileはGNUプロジェクトの公式の拡張言語ではありますが、Emacsそのものに比べれば現在は非常に小さなプロジェクトです。Guileの開発者に大規模なプロジェクトのニーズを突然押し付けては（Emacsコミュニティ全体のバグレポートを押し付けることになるのは言うまでもありません）、Guileプロジェクトのリソースに大きな負担になるでしょう。中でもDavid Kastrupは、そのような負担をGuileチームが担えるのか 不安 でした。新しいユーザを急激に増やすことは、Guileプロジェクトにとって良いことになりえます。もちろん、新たなコントリビュータを引きつけるでしょう。しかし結果は保証されません。~

さらに、GuileとEmacsがどれだけしっかり連携すべきなのかという問いがあります。例えば、2つのプロジェクトは現在、内部で異なる文字コードを使用しています。つまり、テキストはGuileインタプリタへ入出力する際、必ずデコードとエンコードが必要になるのです。この非効率さは間違いなく理想的ではありません。しかし、Kastrupも 述べているように 、文字コードを統一しようとする試みは危険です。Emacsは本来テキストエディタですから、その歴史的に、正しくないエンコードの文字があっても許していました。ユーザーにその対処をまかせるという方法を取ったのです。Emacsはディプレイに表示する目的のために正しくない列を生のバイト列へ変換し，ファイルに保存する際はそのまま書き込みます。

しかしGuileには他にも心配すべき用例があります。例えば無効な文字のシーケンスが入力された場合にエラーを出力するプログラムを実行する場合です。Guile開発者のMark H. Weaverは、SQLクエリに文字列を渡すことは、“未加工のバイト”コードを保護しておくと有害に利用されかねない状況の例であると 言及しています 。Weaverはさらに、Guile内部の文字コードを、Emacsでも使っているようにUTF-8へ変更することを望んでいると 述べて います。しかし，未解決で行き詰まっている問題も挙げており，前に進む前にさらなる熟慮が必要であると述べています。

共通の文字コードを見つけることは、可能かもしれません。しかしEmacsとGuileの統合におけるハードルは、それだけではないのです。Stefan Monnierのように、Emacs Lispが、より標準化された別のLisp方言に、意図的に“発展”する可能性を 示唆する 人もいます。そのような発展は、いかなる場合においても容易ではないでしょうが、Guileのネイティブ言語であるSchemeへは特に用意ではないでしょう。Emacs Lispを Common Lisp へ適用することは、まだありえるかもしれません。しかしそれでも、決してとるにたらないということではないでしょう。2つの言語の間には、多くの領域で互換性があります。とはいえ、ほんの少しの非互換が、開発者に苦痛を与える結果を招く可能性があります。例えばTempletonは、Emacs拡張でよく使われているEmacsのバッファローカル変数に対応する機能が、Common Lispには存在しないと 述べています 。しかしMonnierは、さらに困難な問題を 指摘しました 。それは、Emacs Lispではfalseが代入されたブーリアン型変数と空リストが等しいと見なされるのに対し、他のLisp方言ではそう見なさないという問題です。

基本的に、Schemeは#f、()、nilを全く別の3つのオブジェクトとしてもっています。ですからGuile-Emacsは、その中の一つをEmacs Lispのnilと見なします。すべての処理がEmacs Lisp内に収まる限り、その処理は（おそらく）動きはするでしょう。しかしいくつかのScheme言語では、画面に出力したとたんに、新しい値に変わるかもしれません。nilと似てはいても、`eq’で等しいと見なされないからです。

このような基本的な言語の構造を再定義するには、非常に深くまで悪影響を及ぼすかもしれません。もちろんそれは、数十年分もの価値を持つ既存のコードや、Emacs開発者のコミュニティに対してです。しかし、たとえGuileのEmacs Lispインタプリタの基礎がしっかりしたものであっても、Schemeの土台は恐らく不便なところに現れてしまうだろう、とMonnierは付け加えています。「 私は、特別に注意していないと、Guileランタイムで発生したエラーシグナルのいくつかについては、Schemeスタイルのデータを使うことになったり、Emacs Lisp側へこぼれたりするのではないかと思っています 」

関連した課題があります。Emacsを開発するに当たって、Emacs Lispが唯一の言語のままであるべきなのでしょうか。GuileがSchemeや完全に無関係なオプションであるJavaScriptのような他の言語を同じようにサポートする限り、GuileベースのEmacsは全く別の関数のインターフェイスをサポートするべきですし、ユーザが自分の選んだ言語でEmacs拡張を書ける、といった状況が生まれます。これに対する意見は、はっきりと分かれているようです。Richard Stallmanが、EmacsにおけるScheme拡張についてサポートする考えがあることを 表明する 一方で、他の（Phillip Lordを 含む ）技術者の中には、JavaScriptといった無関係な言語をも受け入れている人もいます。またMonnier といった 他の技術者も、他言語との真の統合が可能なのか、疑問を抱きました。Daniel Colascioneのように、常に人気がある多言語をサポートしようと試みることは、無駄な努力になるだろうと 主張する 人もいます。

短中期において、Emacs Lisp以外の言語で書かれたEmacs拡張のサポートを加えることは、大きな牽引力があるようには見えません。緊急に考慮すべき課題があまりにも多くあります。EmacsをGuileインタプリタにリベースにするよう追求することを決めたプロジェクトの場合は、特にそうです。Lispインタプリタに替わるものについては議論されてきました。例えばKristian Nygaard Jensenが 組み込みできるCommon Lisp を 提案 しています。しかしながら、他の選択肢もせいぜいGuileと同じように統合に伴う困難がつきものです。なぜなら単純に、多くのアクティブに開発されているGPL3互換のLispインタプリタが選ばれるとは限らないからです。少なくともGuileは公式のGNUプロジェクトですし、その開発チーム内の複数のメンバは、Emacsとともに取り組む可能性についてサポートすると表明しています。

現在の状況として、Emacs内部のLispインタプリタをGuileにリプレースすることに関しては公式に合意されていません。TempletonのGuile-EmacsはEmacsの開発者コミュニティで多くの賞賛を集めました。しかし、さらなるテストが必要になりそうです。それによって、キーとなる部分でいくつかの確固とした決定が、GuileとEmacsの技術者の間で交わされるかもしれません。何をもって統合とみなすか、ということについての決定です。そうした会話（例えば文字列の扱いについての議論）が今なされていますし、有望な理由もあります。しかし具体的なスケジュールやロードマップを期待するのは、いずれも時期尚早のままであると言えるでしょう。