I voted "Yes", but I meant "Yes, to use LSP without blocking the whole thing everytime".
this post was submitted on 20 Nov 2023
1 points (100.0% liked)
Emacs
7 readers
1 users here now
A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!
Get Emacs
Rules
- Posts should be emacs related
- Be kind please
- Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.
Emacs Resources
Emacs Tutorials
- Beginner’s Guide to Emacs
- Absolute Beginner's Guide to Emacs
- How to Learn Emacs: A Hand-drawn One-pager for Beginners
Useful Emacs configuration files and distributions
Quick pain-saver tip
founded 1 year ago
MODERATORS
A lot of very useful software is not multithreaded. Hell, javascript is not multi-threaded.
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?
The part where I need to type something, but the process is blocked
Since I use Emacs solely for text creation/manipulation, and I don't know what multithreading is, I voted No.
The only "performance" issue for me is lsp - but that tends to be at first run on a large framework. And since my "old" laptop (x1c6) is about 1000x faster than the one I started using emacs on in the early 2000s it really isnt an issue.
Less haste, more speed...
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 didn't say it would be easy. ;)
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.
I'm also using Gnus with IMAP directly too but connecting to a remote Dovecot on my root server. Fetching takes maybe 1 or 2 seconds at max.
I filter all my mails on my server before hand.
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?
Magit
Networking activity is a prime example of something where threading is least likely to be a clearly superior solution. Heavy CPU use is where threading may be the superior choice and a single event-loop thread is not. IO waiting is not.
I stay away from stupid plugins that block my main thread, so of course it's a deal breaker. I want to use those shitty plugins whose authors don't know what they are doing.
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.
And wouldn't work, given that except for the actual pushing pixels to the screen everything else is done by the Lisp code. So you would need to tightly synchronize the two threads to the point of it being useless.
Having a separate "rendering" thread works for applications where you can queue up rendering tasks and then execute them in the background. Such as a game engine.
Not an interactive text editor that has not been designed with such architecture in mind because threads didn't even exist back in the day.
No, but it would be nice to have some day in the near future.
No, but it would be nice to have some day in the near future.
I'm gonna vote yes. I've been using Emacs since 2008, but if I had to start again today I would probably not pick it up, lack of multithreading is partially why.
Multithreading is a grand good source of instability and bugs, please don't.
Multiprocess if you must, but unless you have a language like erlang / elixir multithreading is a bug prone nightmare.
I answered yes, but I really mean "kindof"
Is this about Elisp threading or Emacs using threads to implement rendering and executing Elisp etc?
It's a dealbreaker for certain applications (e.g., window management). It's not a dealbreaker for Emacs as a whole.
Actually, to be clear: most of the pain is with blocking I/O. But Emacs does have support for asynchronous I/O. The problem is that there is too much code that uses blocking I/O rather than asynchronous I/O.
If you want a multithreading Emacs contribute to https://github.com/lem-project/lem. That will probably get you there faster than with Emacs.
Truth is it isn't Emacs that you want, but the features it has. Just replicate them in Lem.