Hacker News Reader

Comment by taeric | Hacker News Reader

I'm still not entirely clear that most people understand the problems that well. The way you would hear it on most forums, emacs blocks whenever you do anything that takes time. Nevermind compilation mode being a thing basically forever.

So, yes, you can block the UI thread. There have been ways to not do that basically forever. I welcome better ways to manage this, but there will always be some way to do code on the UI thread, such that it will always be possible to somewhat block things.

The alternative is to make all code preemptive, it seems. And that just begs for race conditions on the shared mutable state that is the editor.

View on HN

So this is a complaint I do have. But in fairness, I do worry a little that I've used Emacs for so long as my primary text editor that I've lost perspective of what the failure rates are for other text editors. I remember Atom being absolutely terrible about this, and thinking that Emacs was basically as good if not significantly better at not blocking the UI whenever it needed to think.

The problem is I had to use Atom for a while seriously before I understood how often it failed for me. If you're just trying out a text editor to see if it's comfortable, you don't see these failure modes as clearly. So I've tried VSCode before, but I don't know if it's better or worse at avoiding hanging the UI, because I don't use it constantly all day long with a ton of packages installed.

If I had to make a list of all the times I get frustrated at Emacs, a long operation that has nothing to do with the UI blocking everything is pretty high on the list, that is a regular complaint that I have. I feel comfortable saying that I wish Emacs packages would get better at this, and maybe there are ways to improve it within Emacs.

But I guess truthfully for all I know VS Code could have the same problem but even worse.

I agree that making code preemptive is probably not a good idea.

> The way you would hear it on most forums, emacs blocks whenever you do anything that takes time. Nevermind compilation mode being a thing basically forever.

Sure, it’s possible to write code that doesn’t block the UI, but it’s very difficult in Emacs and just about every built-in functionality is an offender. This includes network operations, which can block forever. You’d be laughed out of the room if you implemented a text editor today that can lock up completely and indefinitely with M-x package-list-packages.

I'm a little confused, as that doesn't seem to block on my machine? Is it something that used to block, but doesn't anymore?

You are right that it is difficult in many respects. But it is far from impossibly difficult. And most of the tricks you could do to make it easier typically lead to some silly hard edge cases in the code.

> I'm a little confused, as that doesn't seem to block on my machine?

Me too.

I routinely run emacs on a Raspberry Pi IV building large rust projects

Blocking has never been an issue

I bury the compilation buffer and carry on as usual

The main problem I have is too many options and possibilities

I think a better thing to do is organise all the third party packages with decent documentation

The documentation in the package ecosystem ranges from barely adequate to woeful with the emphasis on the latter

package.el went async in 25.1, so apparently my memory of package-list-packages locking up due to connection issues was from the many years of Emacs 24.

package-list-packages does not do network operations in the foreground unless package-menu-async is nil. It's t by default. package-refresh-contents does, but I've always been able to C-g to abort at any time.

Reply on news.ycombinator.com