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

81–90 of 136 posts

Re: A vision of a multi-threaded Emacs

#81

Post by txru »

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…

As mostly a heavy user, most of the time I find emacs quite snappy.

Where do you find your package code most throttled? Do you have a top-3 wishlist you would want the core team to put in?

Re: A vision of a multi-threaded Emacs

#82

Post by pzone »

convolvatron wrote: post #8
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…

one really nasty conflating issue is that emacs uses a mess of globals. partially because of the domain but largely because of dynamic binding and the lack of namespaces. emacs really needs to be hoisted onto another language and runtime. everyone says this but no one can really conceive of doing this and rewriting or at least refactoring all the elisp extensions. I guess guile emacs is still alive? I should really t…

Guile-Emacs is no longer alive. The only other project similar since then has been remacs, but that aimed to replace the C core, not elisp. It also lost momentum. I believe adding parallelism to elisp will be more feasible and successful than another rewrite. It's not a bad language really.

Re: A vision of a multi-threaded Emacs

#83

Post by ungamedplayer »

tgbugs wrote: post #26

One big challenge for multi-threaded Emacs is that there are many elisp libraries and common patterns around buffer modification that make implicit assumptions about sequential and exclusive execution. The various race conditions that would appear in a multithreaded context would be a nightmare to debug because they would likely only occur sporadically and would be hard to reproduce. I would love to be wrong about th…

> One big challenge for multi-threaded Emacs is that there are many elisp libraries and common patterns around buffer modification that make implicit assumptions about sequential and exclusive execution.

It might be naive of me, but why not limit the process execution to the state and buffer that its working in ?

I know that this does not answer the multi processor per buffer problem, but its a better start.

Re: A vision of a multi-threaded Emacs

#84

Post by anotherevan »

OrderlyTiamat wrote: post #68
NeutralForest wrote: post #43

Earlier quoted context omitted.

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.

> I just start a bash while loop that recompiles continually with latexmk.

There's the -pvc option in latexmk that[1], "continuously check all input files for changes and re-compile the whole thing if needed and always display the result," depending on if your PDF viewer will refresh.

That may obviate the need for a bash while loop.

[1] https://mg.readthedocs.io/latexmk.html

Re: A vision of a multi-threaded Emacs

#85

Post by jrockway »

hatmatrix wrote: post #78
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…

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?

For the purposes of this argument I went and installed VSCode. I cloned kubernetes/kubernetes, opened a random file, added fmt.Println("hello") at the wrong indentation level somewhere, and pressed save. While gopls is initializing, it pops up a thing saying "waiting for code actions from the language server" (or similar; it wants the language server to "gofmt" the file). After that completes, the line I wrote appears at the right indentation level in the editor, but what's on disk is `fmt.Println("h` at the wrong indentation level.

Emacs behaves in a different but still incorrect way. It writes the entire fmt.Println statement at the wrong indentation level, locks up for a while, and decides that there was no formatting to do. VS Code will be fast after a while, but Emacs never gets fast; every reformat request locks up the UI for several seconds and doesn't actually reformat. VS Code remains responsive, but it's difficult to get the reformatted text on to disk. (Sometimes it does it, though.)

My main conclusion is that you're screwed if you have to work on k8s day to day. But on a more serious note, this isn't really an issue that can be solved with a UX tweak; the class of problem is "the optimal algorithm for providing instant hints on a codebase that is 214k lines hasn't been discovered yet". Yes, editors can let you mutate the text while it's working on something in the background; and if you turn of language server support that's fine. The key problem is merging your edits with its set of assumptions, and that's what's going to be slow.

Re: A vision of a multi-threaded Emacs

#86

Post by nverno »

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…

The worst non-package related offender is long lines imho. I think opening a file or buffer with a long line is the only immediately obvious hanging I see running plain emacs. I know there are a lot of technical difficulties, but fixing this issue would be a nice UX improvement.

Re: A vision of a multi-threaded Emacs

#87

Post by hinkley »

jlokier wrote: post #16
admax88qqq wrote: post #7

Earlier quoted context omitted.

WebWorkers are not very useful as a result. The communication overhead of copying data between two memory spaces usually dwafs any apeedups you could get from doing the work in parallel. It's easier to implement as a language and runtime, but to get truly high performance on today's many thread many core machines you need shar d memory concurrency more like Java

> to get truly high performance on today's many thread many core machines you need shared memory concurrency more like Java JavaScript supports shared memory concurrency. Shared memory¹ is available in browser WebWorkers these days.² Atomic ops for building multi-threaded data structures³ are available too⁴. Including primitives for thread synchronisation⁵⁶ used by mutexes, condvars, producer-consumer queues, etc. ¹…

Arrays of bytes are practically useless in Javascript. And the message passing system for NodeJS workers is almost as useless because it's just as alien to the rest of the javascript normal people write as shared byte arrays is. What we needed was message passing implemented as an async operation that awaited a response. Bidirectional emit() operations don't scale.

If you were building something on top of them using wasm then you probably wouldn't even know what the primitive was. But we're not. We're writing Javascript, and it's a damned shame.

When someone takes a really long time to make a really bad solution, there's frequently not enough group will to correct the issue. This will be the bullshit we are stuck with for the next ten years.

Re: A vision of a multi-threaded Emacs

#88

Post by gorgoiler »

One would have thought a purely functional piece of software written in Lisp was the poster child for parallel execution. Emacs clearly can’t easily do that, as per the article — the core of what it does is stateful — but what are some good examples where scaling horizontally with pure functions has worked?

Re: A vision of a multi-threaded Emacs

#89

Post by rcthompson »

tgbugs wrote: post #26

One big challenge for multi-threaded Emacs is that there are many elisp libraries and common patterns around buffer modification that make implicit assumptions about sequential and exclusive execution. The various race conditions that would appear in a multithreaded context would be a nightmare to debug because they would likely only occur sporadically and would be hard to reproduce. I would love to be wrong about th…

Couldn't you implement things such that any number of readers can access a buffer concurrently, but modification requires exclusive access?

Re: A vision of a multi-threaded Emacs

#90

Post by chlorion »

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…

>Finally for LSP, I always recommend Eglot over LSP Mode, as Eglot is written by an Emacs contributor that has deep knowledge of Emacs and Emacs Lisp. LSP Mode is written by volunteers on Github, and the code is nowhere near as good.

This isn't really true at all, but even if it was, lsp-mode has a larger scope and has many more features than eglot. It's also much more actively maintained/developed than eglot is.

Anyways, most FOSS code is written by volunteers. I really don't think that's a great argument against a FOSS project.

Also see:

https://github.com/emacs-lsp/lsp-mode/graphs/contributors

https://github.com/emacs-lsp/lsp-mode/pulse/monthly

https://github.com/joaotavora/eglot/pulse/monthly

Post reply on HN