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 so

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.