[julian37]

I use Emacs daily for 80% of my work and its performance is not an issue.

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.

[technomancy]

> 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.

[julian37]

Good point. Adding multi-threading while keeping the existing elisp compiler would definitely improve responsiveness, maybe enough so to turn the issues I mentioned into non-issues. That said, the proposed approach has the potential to kill two birds with one stone: add multi-threading AND improve raw performance.

[Arelius]

The problem with multi-threading in emacs isn't a lack of libraries to support threads, as CL would supply, but rather the complexities of synchronization of a large existing codebase, which porting to CL would have no effect.