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

61–70 of 136 posts

Re: A vision of a multi-threaded Emacs

#61

Post by jrockway »

chrsig wrote: post #15
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…

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…

> This is putting a lot of blame on the user

I think you're missing the point. Emacs already contains all the support necessary to make LSP not lock up the UI, LSP simply doesn't use it. So if you say "LSP is a great use case for multi-threaded Emacs", that's not correct.

The problem with LSP specifically is that Emacs doesn't really know what the language server is going to do, and if it let you update the text while the language server was also updating the text, it would have to have some way to merge the changes that you made while the language server was busy. There would need to be some spec for that, or more likely, another trip to the language server to figure out what to do. You could, of course, edit the text while that second trip was happening, and this algorithm never converges to a finished state. So, it locks the UI so you can't make any edits until the text from the language server comes back. That's the easy way out, but at least it results in an algorithm that terminates.

The way to fix this is to figure out where the time is being spent. If it's on JSON marshaling/unmarshaling, speed that up. If it's because the language server is slow, speed that up. The only compromise right now would be to let you edit buffers in a different project while the language server is processing something. I don't think anyone wants to do that; "I don't want LSP to lock up Emacs" really means "I want my language server to perform all operations instantly." So get out that profiler for your language server, I think.

Re: A vision of a multi-threaded Emacs

#62

Post by xxpor »

light_hue_1 wrote: post #56
jhgb wrote: post #52

Earlier quoted context omitted.

Grad school doesn't last forty years though...or does it?

I should hope not! Also, 40 years? 1000000/40/52 ~> You're assuming the average developer writes 500 lines of code per week? That seems absurdly slow.

I'm lucky if I write 500 lines of code a quarter these days....

Re: A vision of a multi-threaded Emacs

#63

Post by tom_ »

massysett wrote: post #59
complex1314 wrote: post #41

Earlier quoted context omitted.

Use emacsclient and have a emacs server running at all times. Super fast startup times, you can even use emacsclient -nw (or make an alias 'e' for that) in the terminal for fast edits with instantaneous startup. You could also make a script that starts emacs as a client only if a server already is running #!/bin/sh if [ "$#" -eq 0 ] then echo "Starting new Emacs process ..." >&2 nohup emacs > /dev/null 2>&1 & elif em…

This is really “just leave Emacs running all the time,” which is more of a workaround or an acceptance of “fit your workflow around Emacs” than it is truly a solution, which would be to reduce startup times.

Why do you quit though? I don’t quit other programs... why is Emacs different?

Re: A vision of a multi-threaded Emacs

#64

Post by joseph8th »

massysett wrote: post #59
complex1314 wrote: post #41

Earlier quoted context omitted.

Use emacsclient and have a emacs server running at all times. Super fast startup times, you can even use emacsclient -nw (or make an alias 'e' for that) in the terminal for fast edits with instantaneous startup. You could also make a script that starts emacs as a client only if a server already is running #!/bin/sh if [ "$#" -eq 0 ] then echo "Starting new Emacs process ..." >&2 nohup emacs > /dev/null 2>&1 & elif em…

This is really “just leave Emacs running all the time,” which is more of a workaround or an acceptance of “fit your workflow around Emacs” than it is truly a solution, which would be to reduce startup times.

Once it starts it does almost nothing unless you're using it, and then it's still a lightweight document editor, not an Electron app

Re: A vision of a multi-threaded Emacs

#65

Post by kwhitefoot »

metroholografix wrote: post #28
alex_smart wrote: post #25

Earlier quoted context omitted.

Gnus has been around since the mid 90s (and predates the addition of asynchronous url-retrieve api to emacs). It is unfair to compare it with packages that written in the last couple of years. I don't use Gnus so I have never bothered looking at its internals, but if it is locking your emacs for twenty seconds checking email, it is probably not doing much asynchronously. It is notoriously hard to convert existing syn…

This. Gnus is a behemoth, has been around for decades and is also the result of many contributions from many different people. It will take time for it to evolve (it's slowly happening). Lars is amazing by the way, his relentless Emacs work and prolific bug killing in the last few years should be praised to high heavens.

Not only that but he is incredibly responsive to random people (including me in the past) reporting bugs in Gnus. Years ago I reported something on a Friday morning and he replied directly to me with a workaround by the afternoon.

Re: A vision of a multi-threaded Emacs

#66

Post by [deleted] »

yakubin wrote: post #45
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…

For me the most frequent source of freezes was Tramp. It led me to ditch Emacs for VSCode (with the remote editing extension) at least for my dayjob (I still use Emacs for my own projects). Tramp is an official built-in package, so it's not as if I downloaded a random package from GitHub.

[deleted]

Re: A vision of a multi-threaded Emacs

#67

Post by kwhitefoot »

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?

Why does Emacs startup time bother people so much? It's pretty quick for me and only happens once every few months anyway.

Re: A vision of a multi-threaded Emacs

#68

Post by OrderlyTiamat »

NeutralForest wrote: post #43
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.

My biggest pet-peeve is Org freezing when I'm exporting to PDF.

I've had that fixed in the past by simply adding an ampersand to org's compile command. This does make it run in the background but makes it ring the bell a number of times. Now when I'm editing and want to see the compiled pdf side by side I just start a bash while loop that recompiles continually with latexmk.

Re: A vision of a multi-threaded Emacs

#69

Post by KMag »

d0mine wrote: post #53
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.

You don't need multiple threads to perform IO asynchronously. And in reverse, using threads won't prevent lock-ups: the opposite is likely. [Pre-emptive] threads compared to external processes require much more careful coordination that is hard to achieve if you are installing dozen of emacs packages written by different people that manipulate the same state. unrelated, it is one of the arguments in favor of GIL such…

Agreed. Raw threads are almost always the wrong application-level concurrency abstraction. Actors/Erlang-style concurrency and futures are both much better abstractions for application programmers. I'm also a big fan of threads with compile-time proofs against data races, a la Rust, but I can appreciate it's a lot to learn for many application programmers.

Re: A vision of a multi-threaded Emacs

#70

Post by michaelmrose »

rprospero wrote: post #17
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…

While I appreciate the comments on Eglot vs LSP, the number one package that hangs my system is Gnus. It's still my favourite e-mail client, but I'm cut off from coding for twenty seconds every time I check my e-mail. Are we really ready to declare that Lars Magne Ingebrigtsen is a substandard Emacs Lisp coder?

I use mu4e so I don't know if the workflow converts but I watch for new email outside of Emacs entirely and upon new email run offlineimap and after sync have it run mu4e-update-index via emacsclient.

This means Emacs always has an up to date view of my email within a ~30 second window of the email being received and all I'm asking it to do is query mu which takes ms.

Post reply on HN