A vision of a multi-threaded Emacs • Hacker News Board

Re: A vision of a multi-threaded Emacs

#101

Post by dotancohen » Tue, May 31, 2022, 5:59 AM UTC

NeutralForest wrote: post #37

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?

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.

Thank you. I'm not using many packages, so I'm not sure what to change. Using csv for example:

  $ grep csv ~/.emacs
   '(package-selected-packages '(csv-mode org-evil dash)))

If I want evil all the time but csv only when needed, I should change that to the following?

   '(package-selected-packages '(org-evil dash)))
   '(use-package '(csv-mode)))

Re: A vision of a multi-threaded Emacs

#102

Post by dotancohen » Tue, May 31, 2022, 6:00 AM UTC

hierandthere wrote: post #73

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?

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

I start Emacs every few minutes, for Org mode notes.

Re: A vision of a multi-threaded Emacs

#103

Post by throwaway_1_1_1 » Tue, May 31, 2022, 6:13 AM UTC

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?

No post body was provided.

Re: A vision of a multi-threaded Emacs

#104

Post by alex_smart » Tue, May 31, 2022, 6:18 AM UTC

dotancohen wrote: post #100

alex_smart wrote: post #34

Earlier quoted context omitted.

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.

>It seems that Emacs does the check automatically, no?

Nope, it for sure does not.

Re: A vision of a multi-threaded Emacs

#105

Post by billfruit » Tue, May 31, 2022, 6:19 AM UTC

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.

Also large 100mb+ text files seems to bring scrolling to a crawl in Emacs.

Re: A vision of a multi-threaded Emacs

#106

Post by alex_smart » Tue, May 31, 2022, 6:22 AM UTC

dotancohen wrote: post #102

hierandthere wrote: post #73

Earlier quoted context omitted.

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

I start Emacs every few minutes, for Org mode notes.

You do not have to start a new instance of Emacs every time. You can tell emacs to start a server and then use emacsclient to connect to your already running instance of emacs.

Re: A vision of a multi-threaded Emacs

#107

Post by retcon » Tue, May 31, 2022, 6:25 AM UTC

natrys wrote: post #50

light_hue_1 wrote: post #20

Earlier quoted context omitted.

> 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 presupposition that anything is killing Emacs - much less this - requires concrete proof. Because if anything, in my (likewise subjective) experience it's the complete opposite. I see more forum activity from newcomers and more high quality packages emerging each year than ever before. > like an insistence to not using fast native libraries How? Even disregarding graphics and font stack which almost entirely leve…

>I see more forum activity from newcomers

It terrifies me how often new users today are gasping for breath on the shores, ungainly four limbed tetrapods gasping for breath...this isn't progress and it's not evolution, there's so much more of everything but it's not at all higher quality for novice users than I grew up on forty years ago.

> more high quality packages emerging each year than ever before

I question my own ability to quantify modern software quality. Compared with what? My working lifetime has been dominated by corporate shovelware and that's absorbed multiple generations of misguided human and fiscal wealth creating structural deficit immeasurable compared to the Cambrian bounty of my early years. Edited last sentence for clarity.

Re: A vision of a multi-threaded Emacs

#108

Post by harperlee » Tue, May 31, 2022, 6:36 AM UTC

ehaliewicz2 wrote: post #92

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

Exactly, lisp was always multiparadigm, and only more recently clojure has pushed forward the idea that being as purely functional as possible (with immutable data structures and pure functions) is something that works pretty well in a lisp.

Re: A vision of a multi-threaded Emacs

#109

Post by alex_smart » Tue, May 31, 2022, 6:43 AM UTC

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…

> 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)

>Finally for LSP, I always recommend Eglot over LSP Mode

As far as I can tell, Eglot also just blocks waiting for the server response.

Unfortunately, that is the current state of the emacs package ecosystem. Org mode freezes emacs. Magit freezes emacs. Most package writers just don't bother writing their packages with asynchronous I/O in mind. There is no point blaming the user.

Re: A vision of a multi-threaded Emacs

#110

Post by dotancohen » Tue, May 31, 2022, 7:02 AM UTC

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.

Acceptable workaround, though. I don't mind when people XY analyze my problems, often those with experience in a field will be mindful of details that I did not know.

For what its worth, I've got at least 23 (service --status-all) daemons already running on this desktop. So leaving things running in the background until they are needed has precedent.