[HN Gopher] A vision of a multi-threaded Emacs (2022)
       ___________________________________________________________________
        
       A vision of a multi-threaded Emacs (2022)
        
       Author : tosh
       Score  : 66 points
       Date   : 2024-02-17 10:20 UTC (1 days ago)
        
 (HTM) web link (coredumped.dev)
 (TXT) w3m dump (coredumped.dev)
        
       | sapiogram wrote:
       | > Level 2 - memory safe and data races allowed
       | 
       | > Languages where parallelism is memory safe, but can still lead
       | to data races.
       | 
       | > This includes Java and Go.
       | 
       | Despite this common misconception, parallel Go is absolutely not
       | memory safe: https://blog.stalkr.net/2015/04/golang-data-races-
       | to-break-m...
        
       | tra3 wrote:
       | As a user, after using emacs for the past couple of years this is
       | where emacs shows its age vs the "newcomers". Every once in a
       | while the whole UI is blocked when a long running task is
       | invoked. Still, I love using emacs.
        
         | rickstanley wrote:
         | I'm a newcomer, started using Emacs in 2022, well, not vanilla,
         | but Doom Emacs. I was immediately hooked! The defaults are sane
         | for my workflow, and to make it short: it boosted my
         | productivity. _But_ , I've been bitten many times by Emacs' UI
         | nature, unfortunately, mainly in big repos. It's not bad enough
         | to drive me away though.
         | 
         | I has gotten better over this past year, I've noticed many
         | improvements with Nativa Compilation and Tree-Sitter, not sure
         | if it can get even better; I sure hope so.
        
       | finaard wrote:
       | We're now at Emacs 29. I've been following the threads stuff back
       | then out of curiosity - but never seen it as game changer, as
       | most of the annoyances where stuff hangs could just be solved by
       | using async methods.
       | 
       | I just went over all my packages - I'm not using a single one
       | which does make use of the threads API. I used to use lsp-mode,
       | which _does_ create a thread in one situation - which also
       | could've been solved by doing async calls.
       | 
       | A lot of the stuff that should've used async, but didn't got
       | fixed, plus there's an external library to move some other stuff
       | along. I've moved gnus (which used to be notorious for blocking
       | everything) into my main emacs process years ago - and last year
       | even tried setting up a new notebook without the local imap, and
       | made it directly go to upstream servers. Turns out, so much
       | improvements landed in the imap code over the years that doing
       | this works so well now that I've dropped the local cache from all
       | my existing systems by now.
        
         | rickstanley wrote:
         | > I _used_ to use lsp-mode
         | 
         | Do you not use it any more? Have you switched to Eglot or
         | something?
         | 
         | I use lsp-mode, was going to switch to eglot, but it doesn't
         | have the features that lsp-mode has, like lsp-ui (as far as I
         | can remember), and the last time a compared (last year), the
         | performance impact was somewhat noticeable.
        
       ___________________________________________________________________
       (page generated 2024-02-18 23:00 UTC)