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

121–130 of 136 posts

Re: A vision of a multi-threaded Emacs

#121

Post by unhammer »

dotancohen wrote: post #101
NeutralForest wrote: post #37

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

The package-selected-packages is just the list of installed packages, doesn't load anything.

You can set

    (setq use-package-always-defer t)
so anything you load with use-package will only be loaded on-demand. Or you can do it per package with e.g. `(use-package csv-mode :defer t)`.

Also make sure you don't set use-package-always-ensure and don't `:ensure t` or it'll try to install anything that's not installed on startup. If you want fast startup, it's better to explicitly install with M-x package-install

Re: A vision of a multi-threaded Emacs

#122

Post by __d »

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…

I wonder if it would be possible to automatically rewrite the elisp code to whatever new runtime was chosen? Assuming the new language is still more-or-less a Lisp ... maybe?

Re: A vision of a multi-threaded Emacs

#123

Post by Kaze404 »

appletrotter wrote: post #80
armitron wrote: post #79

Earlier quoted context omitted.

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

To add to this, my Emacs never crashes but at least once a week I'll run an innocent command (sometimes just opening magit) and it will become unresponsive indefinitely, with the only way of closing it being sending a kill command from the terminal.

Re: A vision of a multi-threaded Emacs

#124

Post by NeutralForest »

unhammer wrote: post #121
dotancohen wrote: post #101

Earlier quoted context omitted.

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

The package-selected-packages is just the list of installed packages, doesn't load anything. You can set (setq use-package-always-defer t) so anything you load with use-package will only be loaded on-demand. Or you can do it per package with e.g. `(use-package csv-mode :defer t)`. Also make sure you don't set use-package-always-ensure and don't `:ensure t` or it'll try to install anything that's not installed on star…

Always defer is a bad idea because some packages are required at startup or look for variables defined at startup (which is why `:init`) is a thing. Also, `:ensure t` only installs what is not installed at startup, but it does so only once and the following updates are to be made by hand. Once this is done, it does not try to install the packages anymore unless you remove them. This is how you get both fast startup and feature availability. Agreed on not using `always-ensure`, there are builtin packages that do not need it and will error out, this is why you should `:defer` and `:ensure` yourself.

Re: A vision of a multi-threaded Emacs

#125

Post by anthk »

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?

Sadly it's common with Gnus.

Re: A vision of a multi-threaded Emacs

#126

Post by ghosty141 »

hadjian wrote: post #95
jhoechtl wrote: post #38

Earlier quoted context omitted.

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.

Lsp comes with preconfigured flycheck for example.

Re: A vision of a multi-threaded Emacs

#127

Post by ghosty141 »

massysett wrote: post #74
tom_ wrote: 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.

Emacs is not supposed to be used like vim. The stereotype of living inside emacs doesnt exist for no reason.

Apart from that, without too many paclages stsrtup time is not an issue imo

Re: A vision of a multi-threaded Emacs

#128

Post by agumonkey »

rcthompson wrote: post #89
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?

queues of compare-and-swap microtransactions

Re: A vision of a multi-threaded Emacs

#129

Post by alex_smart »

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…

You don't need to do all that. Just run emacsclient with `emacsclient -a ""`.

From the man page:

    -a, --alternate-editor=COMMAND
           If  the  Emacs  server  is  not  running, run the specified shell command instead.  This can also be specified via the ALTERNATE_EDITOR environment variable.  If the value of ALTERNATE_EDITOR is the empty string, run
           "emacs --daemon" to start Emacs in daemon mode, and try to connect to it.

Re: A vision of a multi-threaded Emacs

#130

Post by ParetoOptimal »

ghosty141 wrote: post #126
hadjian wrote: post #95

Earlier quoted context omitted.

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.

Lsp comes with preconfigured flycheck for example.

I just switched to eglot from lsp-mode, flymake worked by default.
Post reply on HN