Will we be ever seeing multithreading in emacs?

Short answer: No Long answer: Maybe

No. The only hope is through forked projects from emacs. emacs-ng and lem are one of them, so keep an eye there

[Primitives for threading are already there](https://www.gnu.org/software/emacs/manual/html_node/elisp/Threads.html). However, changing the core code and package to leverage those primitives is another matter. I think that the prospects look good but it might be 5-10 years.

Give it a few decades, sure. Is it probable in the next 5 years? No

What features would multithreading enable? (Genuine question; not a troll.)

Doing something long like fetching emails / feeds while doing something else. Or not blocking emacs when tramp fail to connects. Not blocking workflow in general…

I just setup Mu4e yesterday and I think you just answered whyI couldn't do stuff in my 2nd buffer while mail was being checked.... doh.

Wasn't there another thread on this 5 minutes ago?

There is always remacs

These are I/O operations and emacs supports non blocking I/O, so it's up these packages to utilize it. Tramp and co. should be fixed which could be done with current Emacs too.

I'm hoping for garbage collecting in background if this is possible since I think that most of the time, I'm waiting for that although I've set the threshold(s) to large numbers.

Alright good to know, but why gnus, tramp are still not fixed ? I’m sure the blocking problem is not bothering only me ?!

These are big/old packages which need time and effort to fix, and I guess there are no volunteers willing to put in the work.

Emacs already has 50 years, do we need to wait for it to turn a century old?

> although I've set the threshold(s) to large numbers. Could be why you're having issues in the first place, depending on how *large* you meant

Multi-threading is hard...

If you're in a rush, you could start working on it.

Just have to wait for "always" to happen.

This. Larger numbers = garbage is collected less often, but more is collected at once when it is collected, meaning (typically) longer pauses. Smaller numbers = garbage is collected more often, but less is collected at once, meaning (typically) shorter pauses. I've seen [gcmh](https://github.com/emacsmirror/gcmh) recommended as a library that configures the garbage collector for you. Not sure if it is truly a "one size fits all" solution though.

I have just that personally because the default threshold is *really* low (setq-default ... gc-cons-threshold (* 8 1024 1024) ; We're not using Game Boys anymore read-process-output-max (* 1024 1024) ; Increase read size for data chunks ...) Edit: added read-process increase

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49065 I get that from your pov, a recalcitrant volunteer is the same as no volunteer. GP can try Commercial Emacs if he's interested in a non-blocking, cooperatively threaded gnus.

It would have been more worthwile to break down the submission into a series of smaller patches to get it into emacs core than forking emacs. The codes will diverge and the fork will not be synchronized/maintained after a while, because it is too much work to resolve conflicts with the main branch. At least that's what usually happens.

You can use the fork and work on porting the fixes back upstream in small bits

Upvote for the code comment.

It should be done by the fork author. It's his code after all and it's also in his interest to get the code into emacs to share the maintenance work with core developers.

I don't see why that needs to be the case, the commercial emacs repository is gpl licensed.

Because the emacs maintainers have a lot to do anyways, so they won't browse the code there, trying to take the useful parts. It has to be done by the submitter to break the patch into smaller chunks and submit those as patches for acceptance, answering questions by the maintainers, make modifications if necessary, etc.

I said "you". If you are "the emacs maintainers" and you don't want to do it, that's fine. Doesn't change the fact that this patchset doesn't need it's author to fix it. The author made some fixes, cool - clearly they don't want to deal with cutting them up. Either someone else does it or it won't happen :)

My current garbage collecting hacks are visible on https://github.com/novoid/dot-emacs/actions#garbage-collection-magic-hack I don't have the issue that garbage collecting takes place rarely and take long. It takes place frequently and lasts for 5-15 seconds AFAIR.