Emacs Lisp is slow. There has been a multi-decade effort to make Guile support ELisp, and using Guile to make Emacs more performant.
Cross platform UI, with a faster Lisp, would allow Emacs to be even more special.
Cross platform UI, with a faster Lisp, would allow Emacs to be even more special.
It's not 100% ready for day-to-day use yet—the deferred compilation logic seems to be recompiling more often than it has to—but I've been quite happy with it so far, and it will make a substantial improvement for Emacs users once it's stable and rolled out. Hoping it can be released with Emacs 28 or 29 at the latest :).
How could native code solve that?
Guile at least could.
As a guiler I want Emacs to be guile-based, but I totally understand the Emacs POV: guile is an external dependency with unsecure maintainership.
Guile Emacs was the work of one (very talented) guy. He's moved on to other things, but it's not inconceivable that another Guile fan will pick up the torch some day.
If enough Guile/Emacs fans get together this might actually turn in to a viable, maintainable project... this is, after all, how Neovim started. Just some people who were unsatisfied with where Vim itself was going, and teamed up to make their alternate vision a reality -- with great success.
Guile Emacs work is actually a much smaller task than Neovim, as Neovim's authors rewrote Vim from scratch, whereas Guile Emacs has a much more humble aim of simply allowing eLisp to be hosted on the Guile VM.
It could still happen.
The problem with integrating it is that you need someone with good knowledge about guile (since the elisp implementation is pretty bad currently) but even more important: someone who know Emacs internals (not many).
Yes, on some modes there is a visible delay between pasting text and being able to type again, or writing some code and it telling me it's wrong. But the one kind of interaction that matters is always flawless.
Many editors do not get this right.
I’d try one of the LSP based approaches instead these days.
If you want to use emacs as a an alternative to VSCode, or IDE in general, you'll find high quality plugins that will enable you to do so. But then you might experience slow downs.
As emacs is single-threaded (people will come and tell me it's not anymore, I know, but in practice it still is) you'll feel any slow downs in those plugins. Emacs typing latency isn't great.
It's a mixed bag really. It can be fast, it can be slow. It's still my favorite editor.
Emacs has a certain feel to it. Hard to put the finger on, but the movement of the cursor and the scrolling, it just feels nice for me. Like a well worn favourite T-Shirt.
I'm not looking to encouragement to change (after 20 years in Vim that ship has likely sailed for good), I was just curious if the speed of Emacs lisp was a frequent bugbear.
But overall I'm a very happy emacs convert. It's extremely malleable and pleasant development environment and I think it definitely deserves all the gushing articles/posts its been receiving past few years.
Anyway, while elisp might not be the fastest language around, it's not the origin of all slowness in emacs. Crufted design is also a big culprit. The dated regex-machine is often mentioned as a big problem, making syntax highlighting especially painful.
Though I'm not a Rust fan, and would infinitely prefer Guile Emacs, I am kind of half-hoping Remacs succeeds so Emacs can finally put all of that legacy C behind it.
Multi-second lag on type and navigating isn't acceptable. Org-mode is especially bad.
I ended up going in the other direction: kept emacs, got mostly rid of windows (I have it in a VM for the odd occasion where I need to use a windows-specific program. The fact that my company is flexible on the work OS is a huge bonus for me.