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

71–80 of 136 posts

Re: A vision of a multi-threaded Emacs

#71

Post by joseph8th »

taeric wrote: post #48
CJefferson wrote: post #5

Note: Not at all an emacs expert, but know some stuff about trying to parallelise a long-standing language ( GAP -- www.gap-system.org , 30 year old maths language). I'd strongly recommend something like Javascript's "web workers", where each thread lives in an almost entirely independent memory space, with sharing limited to explicitly named buffers. The problem with traditional "everything shared by default" thread…

I'd argue that emacs already has that with process buffers using sentinels. :D By and large, if you don't write blocking code, it doesn't block. Big caveat here is the TRAMP logic to establish connections can block. Not sure why those weren't done in a more async way.

This is my only real gripe, as well. I really like Tramp, so I use it anyway, but I gripe about it when it hangs

Re: A vision of a multi-threaded Emacs

#72

Post by bitwize »

jrockway wrote: post #61
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…

> 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 whil…

> I think you're missing the point.

I don't. "The only thing that matters in software is the experience of the user." The Emacs user experience is full of I/O hangs; the VSCode experience is not. This is a problem that needs to be solved if Emacs is ever to have a significant installed base again.

Re: A vision of a multi-threaded Emacs

#73

Post by hierandthere »

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?

How often do you start Emacs? I do that maybe once a week.

Re: A vision of a multi-threaded Emacs

#74

Post by massysett »

tom_ wrote: post #63
massysett wrote: post #59

Earlier quoted context omitted.

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?

I quit and restart Vim dozens of times daily.

I’m not saying there’s something wrong with leaving Emacs running. But it’s a workaround. When I used Emacs, startup time was not a problem. But I didn’t use a bunch of packages.

Re: A vision of a multi-threaded Emacs

#75

Post by bitwize »

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?

Emacs starts up in half a second or less for me. I use a vanilla configuration and don't update packages every time.

Re: A vision of a multi-threaded Emacs

#76

Post by hierandthere »

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.

While I did not ditch Emacs nor do I plan to do so, I agree, that TRAMP is a constant source of grief. It is great in its functionality, but frequent freezing is annoyingly cold.

Re: A vision of a multi-threaded Emacs

#77

Post by burtness »

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.

You can change it to export in the background:

  (setq org-export-in-background 't)
https://orgmode.org/manual/The-Export-Dispatcher.html

Re: A vision of a multi-threaded Emacs

#78

Post by hatmatrix »

jrockway wrote: post #61
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…

> 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 whil…

If this is the core of the problem, how does VSCode solve it? It seems users report less latency issues with VSCode - have they figured out how to handle the two-way communication better?

Re: A vision of a multi-threaded Emacs

#79

Post by armitron »

bitwize wrote: post #72
jrockway wrote: post #61

Earlier quoted context omitted.

> 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 whil…

> I think you're missing the point. I don't. "The only thing that matters in software is the experience of the user." The Emacs user experience is full of I/O hangs; the VSCode experience is not. This is a problem that needs to be solved if Emacs is ever to have a significant installed base again.

> The Emacs user experience is full of I/O hangs

I can't remember the last time I had an I/O hang in Emacs. I'm also fairly active in the mailing list and various forums, I/O hangs are not really what's being discussed day to day.

So I have to ask, are you projecting or what makes you say something like that?

Re: A vision of a multi-threaded Emacs

#80

Post by appletrotter »

armitron wrote: post #79
bitwize wrote: post #72

Earlier quoted context omitted.

> I think you're missing the point. I don't. "The only thing that matters in software is the experience of the user." The Emacs user experience is full of I/O hangs; the VSCode experience is not. This is a problem that needs to be solved if Emacs is ever to have a significant installed base again.

> The Emacs user experience is full of I/O hangs I can't remember the last time I had an I/O hang in Emacs. I'm also fairly active in the mailing list and various forums, I/O hangs are not really what's being discussed day to day. So I have to ask, are you projecting or what makes you say something like that?

As a third party in this conversation, and someone who uses emacs daily - I/O hangs seem to be something that is a pretty frequent issue for users.

My emacs likes to crash sometimes, usually a few times a week. Hopefully I’ll be able to take some time to bisect my config and see what’s going on. Looks like a memory leak.

Post reply on HN