nine_k
9 hours ago
> Aiming for modern design, multi-threaded Elisp, 10x performance and 100% Emacs compatibility.
I'm afraid that 100% compatibility may be very often at odds with multi-threaded elisp. So much in Emacs depends on global state :-/
thih9
9 hours ago
Current status of the compatibility is[1]:
> ~95%, closing the last gaps
If coding with LLMs taught me anything, it’s that this last 5% can be “load-bearing”.
grim_io
9 hours ago
That's where all the smoking guns are buried.
nickpeterson
9 hours ago
That's why I use a belt and suspenders to pick them up.
dan-robertson
9 hours ago
Most state is buffer-local rather than global. Note also that there is already some amount of multi-threading in elisp.
One thing you could imagine is doing some kind of mvcc system so that if two tasks don’t interfere with each other, they can execute in parallel (and if not, abort one and rerun it sequentially).
But maybe that still doesn’t work because all the things that should be run concurrently are using the same buffer and doing manipulations of it. You could imagine trying to make save-excursion introduce an opportunity for parallelism: split into a separate thread for the body as that thread is no longer modifying global cursor state (in some sense). Don’t let two threads write to the same buffer for concurrent tasks that should appear sequential, but do allow them to read in parallel (surely most things are merely reading).
However I’m not sure you actually need all that cleverness. I think you could have some combination of:
- tools to make multithreaded elisp more viable
- manual attention to improve major sources of slowness by introducing parallelism (eg font-lock, rendering, autocomplete, indentation). A stupid thing could be precomputing (in the background) what would happen in the user pressed RET (or TAB) and then being able to execute it sooner if they press that key.