Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A vision of a multi-threaded Emacs

coredumped.dev

Post reply on HN
Print view View original

31–40 of 136 posts

Re: A vision of a multi-threaded Emacs

#31

Post by dotancohen »

metroholografix wrote: post #10
Kaze404 wrote: post #6

I'd love to see this someday, as an Emacs user. One of my biggest frustrations with Emacs is how it can simply just hang while waiting for anything IO bound (like a response from LSP). It mostly only happens when opening a new file, while in VSCode for example the file is opened immediately and things like LSP and syntax highlighting are loaded in the background.

That multi-threading will solve this issue, is a common misconception. Emacs already supports asynchronous I/O and has sentinels for exactly that. However, not everything that runs on Emacs is taking advantage of that functionality. It is therefore up to you, to use the proper package (or not use the wrong one) / configure Emacs in such a way, so that this sort of issue is avoided. I can definitely say that if you're…

I just got into emacs last year, for Org mode. Startup times drive me crazy.

What would be the correct way to configure my .emacs file to e.g. check for package updates in a background process?

Re: A vision of a multi-threaded Emacs

#32

Post by alex_smart »

light_hue_1 wrote: post #20
metroholografix wrote: post #10

Earlier quoted context omitted.

That multi-threading will solve this issue, is a common misconception. Emacs already supports asynchronous I/O and has sentinels for exactly that. However, not everything that runs on Emacs is taking advantage of that functionality. It is therefore up to you, to use the proper package (or not use the wrong one) / configure Emacs in such a way, so that this sort of issue is avoided. I can definitely say that if you're…

> I can definitely say that if you're experiencing I/O hangs, it's either misconfiguration or bad code in a package that you loaded. As an emacs user and package developer of 20 years I can definitely say you are totally wrong. This is the kind of dismissive, unhelpful, and frankly extremely discouraging attitude that is slowly killing emacs. Instead of taking responsibility for the fact that emacs is incredibly slow…

If your lsp-client code is doing anything where you need binding with a native library or the speed of emacs lisp is a factor, you are doing it wrong. All an lsp-client needs to do is make requests to the lsp-server, listen to the responses and update the UI. It literally doesn't matter how slow emacs-lisp is.

The only way an lsp-client could be slow is by making a request to the server and then blocking on the response - which is wrong and the package writer's fault because they are not using the asynchronous api emacs provides for communicating with a process.

Re: A vision of a multi-threaded Emacs

#33

Post by jhgb »

light_hue_1 wrote: post #24
jhgb wrote: post #21

Earlier quoted context omitted.

> and an incredibly slow language Languages are not slow or fast; their implementations are. There's absolutely nothing wrong with Emacs being programmed in Lisp and it sure as hell isn't "a poor architectural decision". If Emacs is slow because of its implementation of Emacs Lisp, it's time to fix its implementation of Emacs Lisp.

> There's absolutely nothing wrong with Emacs being programmed in Lisp and it sure as hell isn't "a poor architectural decision" I love Scheme and Lisp. I've probably written several million lines of code in both Scheme and Lisp and I've contributed code to several Lisp and Scheme compilers. But languages are absolutely slow or fast! There are fast Schemes and Lisps and there are slow ones. Emacs has probably the slo…

> I've probably written several million lines of code in both Scheme and Lisp

BTW you do realize that this would put you at (sustained, average) several hundred lines of code per day (every day) over your lifetime? That sounds almost depressingly bleak to me. How does one have a life outside of that?

Re: A vision of a multi-threaded Emacs

#34

Post by alex_smart »

dotancohen wrote: post #31
metroholografix wrote: post #10

Earlier quoted context omitted.

That multi-threading will solve this issue, is a common misconception. Emacs already supports asynchronous I/O and has sentinels for exactly that. However, not everything that runs on Emacs is taking advantage of that functionality. It is therefore up to you, to use the proper package (or not use the wrong one) / configure Emacs in such a way, so that this sort of issue is avoided. I can definitely say that if you're…

I just got into emacs last year, for Org mode. Startup times drive me crazy. What would be the correct way to configure my .emacs file to e.g. check for package updates in a background process?

Don't check for package updates during startup? Setup a cron job to upgrade the packages while you are asleep?

Re: A vision of a multi-threaded Emacs

#35

Post by chrsig »

medstrom wrote: post #30
chrsig wrote: post #15

Earlier quoted context omitted.

This is putting a lot of blame on the user, who likely has no clue how emacs i/o behaves. > if you're experiencing I/O hangs, it's either misconfiguration or bad code in a package that you loaded I mean...yes. That's the issue. The issue is that it's possible to have i/o hangs caused by misconfiguration or elisp packages. The solution isn't to tell the user to do something different, it's to make it so that elisp exe…

How would you make it impossible to make the UI unresponsive? Given that lots of packages directly want to do stuff with UI?

I'm not going to have a great answer for how, especially in something with as much legacy as emacs. And I certainly don't mean to imply that solving the problem is easy (or possible for 100% of cases), or otherwise detract from efforts that the community has made.

My intent was to highlight on what a good solution looks like from a user perspective.

Off the top of my head, in an incredibly hand-wavey fashion:

A quick win would be to set a timeout on every single i/o action, with the default timeout being quite low. That doesn't remove the problem, but it'd probably be a good start towards easing the user pain. Bringing an indefinitely long hang down to 1s is a win.

For a total solution, I'd consider looking into implementing a concurrency model with a preemptive scheduler, probably using erlang as inspiration. have updates to the ui becoming a message sent to the ui inbox, and the routine for rendering the ui just reading from the inbox and applying the given command.

This is without thought to how to actually implement that, and what implications it would have on legacy elisp, or how legacy elisp could be brought into a CSP world without breakage.

So just some armchair architecting on a day off for a project I've never worked on :)

Re: A vision of a multi-threaded Emacs

#36

Post by SoftTalker »

Kaze404 wrote: post #6

I'd love to see this someday, as an Emacs user. One of my biggest frustrations with Emacs is how it can simply just hang while waiting for anything IO bound (like a response from LSP). It mostly only happens when opening a new file, while in VSCode for example the file is opened immediately and things like LSP and syntax highlighting are loaded in the background.

I use Emacs all day, every day at work for the last 20 years. I'd like to see these changes too, but honestly it's not even close to being on my top 10 of frequent frustrations. The average web app is way less responsive, suffers random hangs, HTTP 500 errors, browser freezes, etc. than I experience in Emacs.

Re: A vision of a multi-threaded Emacs

#37

Post by NeutralForest »

dotancohen wrote: post #31
metroholografix wrote: post #10

Earlier quoted context omitted.

That multi-threading will solve this issue, is a common misconception. Emacs already supports asynchronous I/O and has sentinels for exactly that. However, not everything that runs on Emacs is taking advantage of that functionality. It is therefore up to you, to use the proper package (or not use the wrong one) / configure Emacs in such a way, so that this sort of issue is avoided. I can definitely say that if you're…

I just got into emacs last year, for Org mode. Startup times drive me crazy. What would be the correct way to configure my .emacs file to e.g. check for package updates in a background process?

You should use `use-package` to manage your packages and defer their loading to when you use them. I have over 100 packages in my init.el and my Emacs loads in less than a second.

Re: A vision of a multi-threaded Emacs

#38

Post by jhoechtl »

metroholografix wrote: post #10
Kaze404 wrote: post #6

I'd love to see this someday, as an Emacs user. One of my biggest frustrations with Emacs is how it can simply just hang while waiting for anything IO bound (like a response from LSP). It mostly only happens when opening a new file, while in VSCode for example the file is opened immediately and things like LSP and syntax highlighting are loaded in the background.

That multi-threading will solve this issue, is a common misconception. Emacs already supports asynchronous I/O and has sentinels for exactly that. However, not everything that runs on Emacs is taking advantage of that functionality. It is therefore up to you, to use the proper package (or not use the wrong one) / configure Emacs in such a way, so that this sort of issue is avoided. I can definitely say that if you're…

As an innocent user I tell you that LSP mode just works whereas Eglot needs tailoring to be a joy to use.

Re: A vision of a multi-threaded Emacs

#39

Post by contravariant »

dotancohen wrote: post #31
metroholografix wrote: post #10

Earlier quoted context omitted.

That multi-threading will solve this issue, is a common misconception. Emacs already supports asynchronous I/O and has sentinels for exactly that. However, not everything that runs on Emacs is taking advantage of that functionality. It is therefore up to you, to use the proper package (or not use the wrong one) / configure Emacs in such a way, so that this sort of issue is avoided. I can definitely say that if you're…

I just got into emacs last year, for Org mode. Startup times drive me crazy. What would be the correct way to configure my .emacs file to e.g. check for package updates in a background process?

Using Doom emacs was the easiest way for me to get fast loading times. It provides some sane defaults that should be pretty fast in most cases. It might be worth checking out.

Re: A vision of a multi-threaded Emacs

#40

Post by TacticalCoder »

Kaze404 wrote: post #6

I'd love to see this someday, as an Emacs user. One of my biggest frustrations with Emacs is how it can simply just hang while waiting for anything IO bound (like a response from LSP). It mostly only happens when opening a new file, while in VSCode for example the file is opened immediately and things like LSP and syntax highlighting are loaded in the background.

> ... while in VSCode for example the file is opened immediately and things like LSP and syntax highlighting are loaded in the background.

I'm not saying you're not experiencing what you're describing but I find that weird because I use Emacs with LSP and the system is responsive while LSP loads up. And I'm using lsp-mode, not Eglot (I should really try Eglot). I mostly use it for Clojure: I'm using both Cider and lsp-mode and they work fine together. And as soon as I open any Clojure source file, I can keep using Emacs while LSP starts (which is not that slow btw: only about three seconds I'd say). LSP is one of those things that runs in another process, so it's one of those case, for me at least, where Emacs acts like if it was multithreaded. I haven't seen this lock up / freeze while waiting for some LSP server answer.

For example I'll typically open a Cojure file, lsp-mode shall begin loading automatically and then I manually launch Cider: everything happens "simultaneously" and I'm not blocked.

I'll play more attention with other LSP servers (like the CSS one) but nothing strikes me as slow or frozen.

If there's one thing I could complain about is that when I'm busy doing other things (because my Emacs ain't blocked), I see spurious LSP messages telling me where it's at kinda distracting me.

Now I take you're using a native-comp Emacs? And a fast JSON parsing lib?

Emacs 28, native comp, lsp-mode, AMD 3700X, NVMe SSD, 16 GB of RAM. A good machine but nothing crazy fast.

Post reply on HN