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

91–100 of 136 posts

Re: A vision of a multi-threaded Emacs

#91

Post by chlorion »

mdkdkdk wrote: post #23
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've seen you post this criticism before, but the line "volunteers on GitHub" is pure FUD. Is the Eglot guy paid for writing Eglot, or he hosts somewhere else, so it's better? "The code is nowhere near as good" according to you? Give a concrete example of where the LSP code has real deficiencies; Eglot isn't as fully featured, is more opinionated, and its stans are more annoying. Sounds to me like the LSP project is…

Yup, I have seen this person post something similar at least once before as well and it's pure misinformation at best.

Both projects are very good and everyone should give both a shot and see which they prefer, but spreading misinformation about one project because you prefer another is stupid and childish.

A quick peek at the github contributors insights also shows that the overwhelming majority of code is contributed by 3 people and not "volunteers on github", but even if it was mostly worked on by volunteers it would make no difference at all.

Code quality is not something that can be trivially disproved like the volunteer thing, but as someone who has spent a bit of time poking around in both projects, neither look any better code quality wise to me. The main thing is that lsp-mode is just much, much larger and prefers to use non-native APIs and packages at times. This is purely a difference in style and opinion rather than "quality".

Re: A vision of a multi-threaded Emacs

#92

Post by ehaliewicz2 »

gorgoiler wrote: post #88

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?

emacs isn't pureful functional, and I don't think much lisp code ever was

Re: A vision of a multi-threaded Emacs

#93

Post by BeetleB »

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.

A no-config Emacs has a rapid startup time - it's instant on my PC.

> or an acceptance of “fit your workflow around Emacs” than it is truly a solution, which would be to reduce startup times.

I don't see a problem with this. Emacs is a general purpose platform, and it's silly to expect really fast startup times if you're using it as a general purpose platform. People aren't expecting Linux to have an instant startup time if you have a large number of services running - why expect it from Emacs?

Re: A vision of a multi-threaded Emacs

#94

Post by oh_sigh »

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.

If a process isn't using any resources, is it really running at all?

(Of course it doesn't really use no resources - it consumes a finite PID among other things)

Re: A vision of a multi-threaded Emacs

#95

Post by hadjian »

jhoechtl wrote: post #38
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…

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

Hm, strange. As I remember, eglot’s design goal was zero configuration. Could you elaborate a bit? For context, I use go, had gopls installed and just had to start eglot. All xref shortcuts worked immediately.

Re: A vision of a multi-threaded Emacs

#96

Post by dotancohen »

complex1314 wrote: post #41
dotancohen wrote: post #31

Earlier quoted context omitted.

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?

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…

Terrific, thank you.

Re: A vision of a multi-threaded Emacs

#97

Post by dotancohen »

BeetleB wrote: post #93
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.

A no-config Emacs has a rapid startup time - it's instant on my PC. > or an acceptance of “fit your workflow around Emacs” than it is truly a solution, which would be to reduce startup times. I don't see a problem with this. Emacs is a general purpose platform, and it's silly to expect really fast startup times if you're using it as a general purpose platform. People aren't expecting Linux to have an instant startup…

Actually, reducing OS startup time used to be a goal. I think that stock Ubuntu on run-of-the-mill hardware (spinning rust) was down to 14 seconds bios-to-login at some point when they made an effort on that front.

Re: A vision of a multi-threaded Emacs

#98

Post by dotancohen »

contravariant wrote: post #39
dotancohen wrote: post #31

Earlier quoted context omitted.

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.

Thanks. I just left Spacemacs for vanilla. A distro was a great way into the Emacs ecosystem, but now I'd like to configure the thing to my use cases specifically.

I might look at the doom config and try to divine how they're getting such fast loading times. Thank you for the suggestion.

Re: A vision of a multi-threaded Emacs

#99

Post by kazinator »

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.

This kind of problem can be solved without threads. Single threaded programs can do things instead of waiting for I/O to complete.

In a Lisp you should have continuations and whatnot to be able to the event-driven programming for that without the inconvenience of having to express all the background tasks as transitions in a state machine.

Re: A vision of a multi-threaded Emacs

#100

Post by dotancohen »

alex_smart wrote: post #34
dotancohen wrote: post #31

Earlier quoted context omitted.

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?

It seems that Emacs does the check automatically, no? I have looked briefly on how to disable that but I didn't have the prerequisite knowledge at the time to understand what was happening. I'll look at that again, thank you.
Post reply on HN