4 ms·

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

by oefrha 3y ago

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

taeric 3y ago
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.
- worik 3y ago
  > 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
- oefrha 3y ago
  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.
jorams 3y ago
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.

4 ms·

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

by oefrha 3y ago

taeric 3y ago
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.
- worik 3y ago
  > 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
- oefrha 3y ago
  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.
jorams 3y ago
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.