Earlier quoted context omitted.
I mean, I get this in principal. I'm curious in practice. How many things aren't already waiting on another foreign process that take time? Edit: I could see some things like syntax highlighting being a benefit. Though, I somewhat expect those to already be moving to lsp tricks. Layout, in general, makes sense to be a bit more responsive. But I'm not clear how general threading helps with that. Edit2: are there good…
The big things are indeed being outsourced to separate processes. LSP handles a lot, I also see some attempts at moving syntax highlighting to tree-sitter[0]. But all such work means a good chunk of code is running inside a foreign process, whose behavior cannot be easily inspected or modified at runtime. But there are a lot of various smaller things in Emacs and elisp module ecosystem that would benefit from being a…
Emacs 27.2
111–115 of 115 posts
Re: Emacs 27.2
#112Earlier quoted context omitted.
I mean, I get this in principal. I'm curious in practice. How many things aren't already waiting on another foreign process that take time? Edit: I could see some things like syntax highlighting being a benefit. Though, I somewhat expect those to already be moving to lsp tricks. Layout, in general, makes sense to be a bit more responsive. But I'm not clear how general threading helps with that. Edit2: are there good…
I stopped using Gnus because its elisp freezes Emacs (I now use mu4e, which has a separate process). I would guess Eww would have a similar issue, although I've never been able to get it to work (I use emacs-w3m, which has a separate process). I've found some programming modes to be very slow and prone to freezing; most noticably Scala using Metals (which uses lsp).
That said, valid points. I am curious to benchmark parts of emacs now. (I turned off most programming features, since most of my code is remote and the network at home kills me.)
Re: Emacs 27.2
#113Re: Emacs 27.2
#114Earlier quoted context omitted.
I'm actually somewhat unclear in what the goals of threading are, at times. Pushing a process out and having a sentinel on a buffer has long been possible. What is the aim?
Make it more light-weight and do it without needing a foreign binary. If your elisp program needs to offload some computations to a background thread, you don't want to make a binary specifically for it - it would destroy the flexibility and portability of otherwise perfectly fine elisp code.
Most of the Emacs code I've seen that spawns a process spawns a short shell script: no custom binary needed.
Re: Emacs 27.2
#115Earlier quoted context omitted.
I stopped using Gnus because its elisp freezes Emacs (I now use mu4e, which has a separate process). I would guess Eww would have a similar issue, although I've never been able to get it to work (I use emacs-w3m, which has a separate process). I've found some programming modes to be very slow and prone to freezing; most noticably Scala using Metals (which uses lsp).
Do you know what makes it freeze? My gut would be that they did not set a buffer with a sentinel, such that even with threading, they would have still don't a blocking call there. That said, valid points. I am curious to benchmark parts of emacs now. (I turned off most programming features, since most of my code is remote and the network at home kills me.)
For Gnus it was using the built-in fetchers like nnrss, which would block the Emacs process until downloads finished. Using a cron job to fetch RSS feeds avoided this, but it would still take a while to check for updates even from local files. This was around 2012, so Gnus might have improved since.
FYI my current setup is described at http://chriswarbo.net/blog/2017-01-14-rss_to_maildir.html