• tyler3505@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    I mean, multithreading is always welcome and I see its uses, even for emacs, however I cannot think of any primary uses where it could possibly be a dealbreaker not to have.

  • Mal_Dun@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Yeah it sucks that this is missing, but on the other hand you have Emacs server and clients to circumvent this.

  • rileyrgham@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    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…

  • AIDS-RAT@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    It might not be a dealbreaker for me per say, but it’s absolutely something that should be included one day.

    • peterhoeg@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Out of curiosity - what are your use-cases where the lack of multi-threading is an issue?

        • nv-elisp@alien.topB
          link
          fedilink
          English
          arrow-up
          1
          ·
          11 months ago

          No detail in your response. How would Tramp benefit from multithreading in any way that isn’t achievable already with an asynchronous approach?

        • terminal_prognosis@alien.topB
          link
          fedilink
          English
          arrow-up
          1
          ·
          11 months ago

          Are you sure the problem there is threading? I’m pretty sure it is not. There’s very little CPU usage. The problem is TRAMP is written synchronously when it should be asynchronous, not that it doesn’t have threads.

  • kr44ng@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Since I use Emacs solely for text creation/manipulation, and I don’t know what multithreading is, I voted No.

  • -dag-@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    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.

    • terminal_prognosis@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 months ago

      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.

      • Thaodan@alien.topB
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        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.

    • thetemp_@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      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.

      • Thaodan@alien.topB
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        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.

  • Jerror@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    It’s the biggest obstacle for sure. If we had multithreading I would go all in

      • Jerror@alien.topB
        link
        fedilink
        English
        arrow-up
        1
        ·
        11 months ago

        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

          • Jerror@alien.topB
            link
            fedilink
            English
            arrow-up
            1
            ·
            11 months ago

            None. Vim is zippy as shit. Emacs stutters on files an order of magnitude smaller than it takes to slow down Vim. In no small part because my Emacs is bloated but I like my Vim minimalist, but still mainly just because Vim is faster than Emacs period, and not by a little.

            I don’t mean no MT is a hard pass on Emacs for me obviously. But every time I pass up Emacs to use another editor it’s a performance issue which multithreading would take care of handily, even if it went no further than a separate thread for the UI.

          • Jerror@alien.topB
            link
            fedilink
            English
            arrow-up
            1
            ·
            11 months ago

            None. Vim is zippy as shit. Emacs stutters on files an order of magnitude smaller than it takes to slow down Vim. In no small part because my Emacs is bloated but I like my Vim minimalist, but still mainly just because Vim is faster than Emacs period, and not by a little.

            I don’t mean no MT is a hard pass on Emacs for me obviously. But every time I pass up Emacs to use another editor it’s a performance issue which multithreading would take care of handily, even if it went no further than a separate thread for the UI.

  • noooit@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    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.

  • lebensterben@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    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.

    • janoc@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      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.

  • RumbuncTheRadiant@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    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.

  • AnnasGrassHopper@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    I think the question is malformed. It’s obviously not a deal breaker for the vast majority of the people in this subreddit, but I bet a good percentage of people would enjoy it.

  • FLMKane@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    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.