Live data from Hacker News

A vision of a multi-threaded Emacs

coredumped.dev

111–120 of 136 posts

Re: A vision of a multi-threaded Emacs

#111

Earlier quoted context omitted.

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.

Thank you Alex. I'm configuring that now.

Re: A vision of a multi-threaded Emacs

#112
post #63

Earlier quoted context omitted.

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.

I never used to quit vim either!

Re: A vision of a multi-threaded Emacs

#113
post #93

Earlier quoted context omitted.

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.

And stock Emacs load time is virtually instant.

Re: A vision of a multi-threaded Emacs

#114

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?

https://blog.d46.us/advanced-emacs-startup/ has some good pointers.

Re: A vision of a multi-threaded Emacs

#115

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.

Maybe you're using (use-package foo :ensure t) or something similar? I did that before, and if there was some package that simply wasn't available it would of course check and not find anything every time I started emacs. I don't use :ensure t any more (I check the elpa folder into git along with my init file for keeping it in sync across machines)

Re: A vision of a multi-threaded Emacs

#116

Earlier quoted context omitted.

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

Thanks for the tip, I'll try it out!

Re: A vision of a multi-threaded Emacs

#117

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.

That makes sense, I don't need to recompile that often but when recompiling relatively large notes (~50 pages) with lots of minted code blocks and the like, it's annoying.

Re: A vision of a multi-threaded Emacs

#118

Earlier quoted context omitted.

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

You should have everything managed by use-package for coherence, even when you don't defer. For example,

(use-package org-evil :ensure t ;; download if not present :defer t ;; defer loading hook (org-mode . org-evil-mode)) ;; start this mode in org buffers

(use-package csv :ensure t :defer t) ;; modes are usually smart enough to know in which buffer they start

and so on for all your packages. If you NEED something to start when Emacs open, you can remove the `:defer t` macro. There are also other useful things like `:init` `:config` `custom`, you should check out the docs!

Re: A vision of a multi-threaded Emacs

#119

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.

My fresh emacs startup time is a couple of seconds, not super snappy but then it has a reasonably large config to load. Reducing startup time is nice but I think vanilla emacs actually already starts quickly. How would you even be able to prevent people from adding heavy stuff to their config? It's possible to defer loading of packages until you need them but I think it would be hard to enforce by default, given that Emacs is really just a lisp machine and the config file is a lisp program.

I normally never exit Emacs. This is not because of startup time. To me it's like the web browser; I use it all the time, have a workspace dedicated to it and it's natural to keep lots of buffers open. My muscle memory takes care of jumping between open buffers.

Re: A vision of a multi-threaded Emacs

#120
post #45

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.

These issues are often interactions between packages. I use TRAMP daily without freezing, but only when I disable company mode in shell modes. VSCode certainly requires much less of this tweaking, even with a variety of extensions installed.
Post reply on HN