Hacker News Reader

Comment by abstractbg | Hacker News Reader

Interesting improvement. My biggest issue with Emacs and the reason that I left it was because it was not multi-threaded. I wonder if is/can be multi-threaded now.

View on HN

Concurrency is a source of many bugs and complexity. Emacs have a few async mechanisms and they’re good enough for most tasks. The async nature of other editors does not really matter as you’re still waiting for actions to complete.

You have libraries for multithreading. I use them myself for parallel tasks. However, how events and redrawing work is a completely different matter.

> 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.

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).

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.

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.

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

How do you sync your google calendar with org-agenda?

org-gcal … bit of a pain getting the Google API config right but so far so good.

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.

Reply on news.ycombinator.com