Emacs-jit: Emacs with an Emacs Lisp JIT compiler | Hacker News Reader

Emacs-jit: Emacs with an Emacs Lisp JIT compiler

github.com

78 pointskruhft17 comments

This is interesting, but I have to be honest: if you are using emacs lisp to do raytracing, then wow.

I love emacs and its extensibility but it already is so extremely fast with zero latency for the normal things emacs is used for: editing. Even very complex editing operations with plugins that do all kinds of wild things are you type are as fast as I can blink. In what normal emacs use cases is a JIT needed?

Having been bitten by my byte compiled code being out of date, I could see this as a good alternative to byte compiling my whole directory.

But, in general, I agree. I have wanted multi threaded for some background tasks. Can't think of the last time I was held up by the lisp being slow.

> if you are using emacs lisp to do raytracing, then wow.

There's a great old saying: Emacs is a great operating system, it just needs a good text editor.

Indeed, Emacs is a great example of how a productivity-oriented OS should look like - giving you a very powerful and efficient set of user-interface operations, and then letting you use them everywhere, no matter the task you're doing.

Pretty much the exact opposite of a normal OS - hence many of us in Emacs world do treat our editor as an OS, and prefer to do everything within it.

If you are one of those die-hard emacs fans I'd love to hear how you would feel about using EXWM. It's an emacs window manager for X.

Screenshots found here: https://github.com/ch11ng/exwm/wiki/Screenshots

+1 EXWM for a tiling window manager. Very nice setup.

Unnecessary, you can split windows in Emacs, view PDFs in Emacs, run a shell in Emacs, browse directories in Emacs. The only thing you can't do in those screenshots is run Firefox, and I'm happy to alt-tab between my fullscreen Emacs session and my fullscreen FF session

Emacs's editor is good. The real problem is the awful default configuration. If you want convenient Emacs then you should define your own favorite keystrokes (with global-set-key) and download useful tools like speedbar (via MELPA) for convenient file browsing, etc.

I know Emacs for 25+ years, I saw many editors come and go. Today I am still using Emacs because its ability to be customized, and the simplicity of the plugin system is still unmatched.

Are you talking about this: https://www.emacswiki.org/emacs/SpeedBar

Is it not already in emacs without need for melpa?

If it manages to increase performance even further, there could still be some benefits to it. I often use spacemacs on my Asus C100P using Crosh (via crouton).

Generally, it works great. But in some scenarios I get the occational (short) hang - and that kind of thing starts to annoy me a bit after some time.

But spacemacs is the most bloated emacs distro in all of human history. I tried it and immediately went back to my slim emacs settings that do just what I want and have no other fluff installed.

I have seen several modes like nxml that are fairly slow. Perhaps it is the implementation of those modes but editing XML in Eclipse is faster particularly far large files (and eclipse is a pig).

I'm fairly certain folks always would prefer a faster editor albeit I doubt the JIT will help for most cases (a new VM as well as better concurrency might help though... aka guile and some major rewriting).

Parsing of source code, calculation of completions, etc.

You could always use more performance to turn your editor into a better IDE. If the Lisp was faster, some of the C could be rewritten in Lisp, which would be smaller and more portable. A future IntelliJ or Visual Studio could be written with Emacs.

> if you are using emacs lisp to do raytracing, then wow.

Just a good, computationally intensive benchmarking task :)

Could an approach like this (with caching the compiled binaries) potentially be a solution to the emacs dumping problem?

As the author of this patch, and someone that's followed the dumping problem as well on the list, and someone that follows emacs development I would say that...no, this is not a portable solution to the problem that would be accepted.

libjit does offer the ability to compile the code to a static vector that can be written to disk but that would then put machine specific code in the output .elc files making them unportable.

Also, at this state with the JIT it's not possible yet to fully compile all of the emacs bytecode; there are still some lurking bugs that need to be squashed that I'll (or someone else) hopefully have time to look into in the future to get this to 100%.

Reply on news.ycombinator.com