You must log in or register to comment.
A lot of very useful software is not multithreaded. Hell, javascript is not multi-threaded.
I dream of a world gnus wont hang emacs.
I guess you should try Commercial Emacs, then.
If the author could only communicate better and bring his changes upstream…
I tried to see what do make of his first patch against Emacs 28 that bring threading to Gnus however it was quite hard to rebase/split them up as the original patch was just one big blob.
E.g. he doesn’t just add threading to Gnus but also remove or rename variables, e.g. secondary select methods. He doesn’t explain changes, he adds unnecessary or rude comments to the commits or code.
I live in that world by outsourcing article fetching to external services and storing all messages/articles locally. The basic setup is this:
Emails:
- Offlineimap syncs 2 Gmail accounts and connects directly to…
- Dovecot as an IMAP server. Dovecot, stores the emails in Maildir format and Gnus’s nnimap backend gets them from the local Dovecot server.
RSS/Atom feeds:
- A program called Feed2exec saves RSS and Atom feeds in Maildir format. Dovecot monitors those folders and serves them to nnimap along with the emails. There is at least one other program that fetches newsfeeds to Maildir, but Feed2exec is in debian.
All 3 of these services do their job regardless of whether Emacs is running, and nnimap is super fast when the server is local.
I don’t read actual newsgroups anymore. If I did, I’d install Leafnode for them. But I wonder if the nntp backend would benefit to the same extent that nnimap does.
at least emacs needs two threads, one for rendering interface and one for the lisp interpreter. this isn’t the multi threading some people hope for but this is much easier to implement and at face level it hides freezes.
It might not be a dealbreaker for me per say, but it’s absolutely something that should be included one day.
Out of curiosity - what are your use-cases where the lack of multi-threading is an issue?
Tramp
It’s the biggest obstacle for sure. If we had multithreading I would go all in
All in on what?
Every time emacs starts to chug I shrug and spin up vim. Maybe I could make that happen less often if I spent a while de-bloating and shopping around for faster packages, but as long as UI is trapped in the same thread as everything else I just don’t think I can pull off the sort of optimization that’ll make emacs snappy everywhere I’d like it to be. And cpu performance is ever skewing towards more cores than faster cores, at least for AMD. Emacs is underwater and still sinking, it seems; and much as I’d like to invest so many hours making it my one-stop editing shop I have no intention of going down with the ship.
But hell if emacs were multithreaded I would run EXWM
What threaded applications are you using in Vim?
Dealbreaker? No. Major issue? Yes.
Anything over network really needs multithreading. The async hacks are ok, but eventually everything has to sync up again, which is a giant freeze on everything.
What evidence do you have for this?
I like the lack of multithreading because it makes programming Emacs extensions simpler.
For professional work, yes, for just goofing off at home, no
You’ll need to explain that to those of us who use Emacs for professional work. What fails for you? In particular, what fails that needs threading to be resolved?