However, one of the reasons that Emacs is so great is the absolute wealth of libraries available for it. It's been aroud a long time and people like it a lot so there's pretty much an Emacs Lisp library to integrate _any_ tool, to help editing _any_ kind of source/configuration file etc. It would take many lifetimes to replicate this in a different language.
see also the history section in Luke Gorrie's Distel paper: http://fresh.homeunix.net/~luke/distel/distel-euc.pdf This was followed by Ermacs, a concurrent Emacs clone written completely in Erlang. Ermacs is fairly complete – it has major modes for Erlang and Scheme programming, a built-in Erlang shell, and support for efficiently editing large files. However, once the core editor was complete, it was obvious that GNU Emacs has an incredibly large set of wonderful features, and that extending Ermacs to include “enough” of them was completely out of the question. The lessons learned from Ermacs lead to Distel,.. how is Yi going to avoid that trap?
I've thought a little about writing a Haskell -> Elisp compiler, so that people could contribute to Emacs by writing Haskell, but I've got doubts about its feasibility.
Luke's Distel seems to have been very successful for erlang <-> emacs interaction, enabling erlang modes for emacs to be written in erlang, with tools that actually understand erlang. this seems to suggest that easy communication with some good-haskell-system-api-based haskell code might be a promising equivalent? http://fresh.homeunix.net/~luke/distel/ both emacs and vim can pass buffer segments and editing session information to external (haskell) code, working as text or file transformers, and both emacs and vim can be controlled by such external code. so haskellers can already use haskell to extend emacs/vim functionality, it just isn't very convenient when it goes beyond transforming text. i would much prefer if vim exposed a standard ffi, instead of all those specific bindings to popular scripting languages and tools, but even without a proper ffi, haskell code cooperating with vim script can already be written. and similarly for emacs, i suspect. so it may just be a matter of doing less of the ide work in elisp/vimscript, and of introducing an explicit interface for inter-process communication between the editor frontend and some haskell-system-api-based backend. claus