[iLemming]

> because it was not multi-threaded

I'm honestly curious, what kind of multi-threading you use, in whatever you're using now instead of Emacs? Can you share some practical example(s)? I'm not trying to trick you, I'm just curious for what kind of complex tasks possible there and where Emacs comes short.

[abstractbg]

The main one was C++ intellisense on a large codebase. It felt unusable due to the single threaded bottleneck. Mind you, this was a decade ago or more by now.

[zingar]

I fetch my google calendar every few minutes to get everything into my agenda. The API request is async, but writing to the calendar file and some additional processing made Emacs hang for 10 seconds at a time. The LLM-inspired solution was to spawn entire new emacs processes to do the work in the background. It's pretty cool that it works, but it feels like it shouldn't - and wouldn't with 2+ threads - have been that complicated.

[iLemming]

Ah, so for stuff like that, it seems current strategy is to build a "server" part that handles concurrency (in a different language) - that's how lsp servers work, and projects like eca-emacs. If I ever get to build something like what you've described I'd probably write the server part in Clojure, Janet, Jank or Jolt¹ or maybe even Zig or Rust. It is a nice, practical example - exactly the stuff I've been asking about, thank you for providing it. I agree, it would be nicer if this kind of stuff was possible without complicated hacks.

---

¹ https://github.com/jolt-lang/jolt

[tmtvl]

Curious that your comment was dead for whatever reason. I vouched for you because I'm also curious at what a user would need concurrency for in a text editor (I mean, granted, Emacs is a Lisp implementation with an amazing text editor attached so in theory someone may want concurrency for programming something in Elisp).

[andros]

To avoid UI freezes, separate event processing from rendering (for example). It's very common to see the interface freeze while a complex command is running.