With a proper intermediate representation, we can begin writing compilers for other languages. Then you can write your extensions in Common Lisp, or Emacs Lisp, or Scheme, or JavaScript, or Perl, or whatever you feel like writing a compiler for. This won't fragment the community, because the runtime will be the same for every language; yes, there will be syntax differences, but in the end, everyone is programming to the same API. This is different than what Vim does with its programming language support (recompile Vim to embed opaque interpreter object, pray when you choose more than one language).
The only problem is that Emacs Lisp is fine for 99.9% of use cases, and it's fast enough for 99.9% of use cases. One worry I have about "proper language support" is that people will start "engineering" Emacs extensions. (By which I mean, treating software designed for interactive use by programmers as though it's "enterprise" software. When you need to write software that must not fail, concepts like encapsulation are very important. But when you're writing software that's designed to be edited by the user while it's running, you can't write it that way. Emacs Lisp explicitly encourages this, but CL, Scheme, and JavaScript don't.)
This has actually been done (possibly badly?) and turned out to be a wash in terms of performance.
Speak for yourself. I also use Emacs daily for 80% of my work and while performance is OK, I would definitely welcome any improvements. Areas where I notice subpar performance are especially:
* paging through or searching in very large buffers (such as large log files), particularly with syntax highlighting enabled
* re-indenting large regions
Also, modes like eterm always feel a bit laggy.
And all the tiny little delays add up. It does matter to me whether skipping to the end of a large file takes 200 ms or 20 ms -- only a little bit but again, it adds up.
I wonder to what extent such a rewrite could be done incrementally. For example, can the redisplay code (which is a big, complicated mess, as one commenter in the article points out) be left in C for a start and "only" the elisp-facing code be ported? If so, this sounds like a viable approach.
I also wonder whether this would help solve the problem of lack of multi-threading in current Emacs.
Or perhaps it's the other way around: adding multithreading to Emacs Lisp would make performance no longer a problem.
(BTW, if you use IMAP with Gnus, I highly recommend using a local IMAP server instead. You can sync to your remote IMAP server with offlineimap. This speeds up Gnus enormously for me; reading my Maildir directly from Gnus is too slow to be usable, but reading it through a local IMAP server makes reading my inbox instantaneous.)
One of the difficulties to be overcome is the huge base of existing elisp code. This code base is part of the attraction of emacs.
That said, I wonder about the possibility of taking an Emacs written in some other language and adding an Elisp interpreter to it such that it could make use of all the existing Emacs elisp out there.
Once you were to rewrite the elisp interpreter, and other calls from C into JavaScript, in theory, running emacs in you're browser isn't actually that absurd.
