ライセンスの下に提供されています。Emacsは、フリーソフトの世界で最も長く、継続的に開発されてきたアプリケーションの1つです。考え方によっては、30年以上を経て、これを複数世代のプロジェクトと見なすことができます。これだけ長寿であると課題もあります。Emacsコミュニティの多くの人たちは、そろそろエディタ内部のLispインタプリタを、より高速で最新のものにリプレースする時だと結論付けてきましたが、Emacsの大半が動作している基礎となる仮想マシンを入れ替えると、LispによるEmacs特有の性質に与える影響を含め、大規模な影響が出ます。TempletonのGuile-Emacsへの作業状況に関して質問をしています。Guileインタプリタに入れ替えます。Lispを含む、その他の複数言語もサポートしています。GuileのエンジンはEmacs内部のLispインタプリタよりも早いと報告されていますが、他にも並行性や、Guileをサポートする他の言語で書かれたEmacs拡張をサポートする可能性があるなど、貴重な機能を複数提供しています。Codeプロジェクトの中でGuile-Emacsに取り組んできたTempletonは、GuileのエンジンにEmacsをリベースするその他多くの利点を列挙しています。その中には、完全な数の階層、構造体型、CLOSベースのオブジェクト指向、外部機能インターフェース、限定継続、モジュールシステム、健全なマクロ、複数値、スレッドなどが含まれています。Emacsの中にあるモジュールの大半は、評判のいいかなりまとまった外部の拡張一式と同様、Guile-Emacs上で安定して動作していると報告しています。EmacsをGuileインタプリタ上に移植するとなると、考慮すべきはるかに厳しい要件があります。ユーザは、全てのEmacs拡張――サードパーティーの拡張と自分のパーソナルコードの両方を含むが、問題なく動作し続けることを期待しています。これは大変な難題です。Zaretskiiが指摘したとおり、GuileはGNUのユーティリティを欠いたシステム上ではあまり安定していません。それに、GuileはGNUプロジェクトの公式の拡張言語ではありますが、Emacsそのものに比べれば現在は非常に小さなプロジェクトです。Guileの開発者に大規模なプロジェクトのニーズを突然押し付けては(Emacsコミュニティ全体のバグレポートを押し付けることになるのは言うまでもありません)、Guileプロジェクトのリソースに大きな負担になるでしょう。Kastrupは、そのような負担をGuileチームが担えるのか不安でした。新しいユーザを急激に増やすことは、Guileプロジェクトにとって良いことになりえます。新たなコントリビュータを引きつけるでしょう。結果は保証されません。~さらに、GuileとEmacsがどれだけしっかり連携すべきなのかという問いがあります。2つのプロジェクトは現在、内部で異なる文字コードを使用しています。テキストはGuileインタプリタへ入出力する際、必ずデコードとエンコードが必要になるのです。この非効率さは間違いなく理想的ではありません。Kastrupも述べているように、文字コードを統一しようとする試みは危険です。Emacsは本来テキストエディタですから、その歴史的に、正しくないエンコードの文字があっても許していました。ユーザーにその対処をまかせるという方法を取ったのです。Emacsはディプレイに表示する目的のために正しくない列を生のバイト列へ変換し,ファイルに保存する際はそのまま書き込みます。Guileには他にも心配すべき用例があります。無効な文字のシーケンスが入力された場合にエラーを出力するプログラムを実行する場合です。Weaverは、SQLクエリに文字列を渡すことは、“未加工のバイト”コードを保護しておくと有害に利用されかねない状況の例であると言及しています。Weaverはさらに、Guile内部の文字コードを、Emacsでも使っているようにUTF-8へ変更することを望んでいると述べています。未解決で行き詰まっている問題も挙げており,前に進む前にさらなる熟慮が必要であると述べています。共通の文字コードを見つけることは、可能かもしれません。EmacsとGuileの統合におけるハードルは、それだけではないのです。Lispが、より標準化された別のLisp方言に、意図的に“発展”する可能性を示唆する人もいます。そのような発展は、いかなる場合においても容易ではないでしょうが、Guileのネイティブ言語であるSchemeへは特に用意ではないでしょう。Lispへ適用することは、まだありえるかもしれません。それでも、決してとるにたらないということではないでしょう。2つの言語の間には、多くの領域で互換性があります。いえ、ほんの少しの非互換が、開発者に苦痛を与える結果を招く可能性があります。Lispには存在しないと述べています。Monnierは、さらに困難な問題を指摘しました。Lispではfalseが代入されたブーリアン型変数と空リストが等しいと見なされるのに対し、他のLisp方言ではそう見なさないという問題です。基本的に、Schemeは#f、()、nilを全く別の3つのオブジェクトとしてもっています。Lispのnilと見なします。Lisp内に収まる限り、その処理は(おそらく)動きはするでしょう。いくつかのScheme言語では、画面に出力したとたんに、新しい値に変わるかもしれません。nilと似てはいても、`eq’で等しいと見なされないからです。このような基本的な言語の構造を再定義するには、非常に深くまで悪影響を及ぼすかもしれません。それは、数十年分もの価値を持つ既存のコードや、Emacs開発者のコミュニティに対してです。Lispインタプリタの基礎がしっかりしたものであっても、Schemeの土台は恐らく不便なところに現れてしまうだろう、とMonnierは付け加えています。関連した課題があります。Lispが唯一の言語のままであるべきなのでしょうか。GuileがSchemeや完全に無関係なオプションであるJavaScriptのような他の言語を同じようにサポートする限り、GuileベースのEmacsは全く別の関数のインターフェイスをサポートするべきですし、ユーザが自分の選んだ言語でEmacs拡張を書ける、といった状況が生まれます。これに対する意見は、はっきりと分かれているようです。Lordを含む)技術者の中には、JavaScriptといった無関係な言語をも受け入れている人もいます。Monnierといった他の技術者も、他言語との真の統合が可能なのか、疑問を抱きました。Colascioneのように、常に人気がある多言語をサポートしようと試みることは、無駄な努力になるだろうと主張する人もいます。Lisp以外の言語で書かれたEmacs拡張のサポートを加えることは、大きな牽引力があるようには見えません。緊急に考慮すべき課題があまりにも多くあります。EmacsをGuileインタプリタにリベースにするよう追求することを決めたプロジェクトの場合は、特にそうです。Lispインタプリタに替わるものについては議論されてきました。Lispを提案しています。他の選択肢もせいぜいGuileと同じように統合に伴う困難がつきものです。単純に、多くのアクティブに開発されているGPL3互換のLispインタプリタが選ばれるとは限らないからです。少なくともGuileは公式のGNUプロジェクトですし、その開発チーム内の複数のメンバは、Emacsとともに取り組む可能性についてサポートすると表明しています。現在の状況として、Emacs内部のLispインタプリタをGuileにリプレースすることに関しては公式に合意されていません。TempletonのGuile-EmacsはEmacsの開発者コミュニティで多くの賞賛を集めました。さらなるテストが必要になりそうです。それによって、キーとなる部分でいくつかの確固とした決定が、GuileとEmacsの技術者の間で交わされるかもしれません。何をもって統合とみなすか、ということについての決定です。した会話(例えば文字列の扱いについての議論)が今なされていますし、有望な理由もあります。具体的なスケジュールやロードマップを期待するのは、いずれも時期尚早のままであると言えるでしょう。ツイート翻訳に対するフィードバックがございましたら、メールまたはGitHubのIssueよりお寄せください。関連した投稿IRCは死んだ。Ltd.リクルートグループサイトへ。