4 ms·

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 so

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.

tom_ 4y ago
Why do you quit though? I don’t quit other programs... why is Emacs different?
- massysett 4y ago
  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.
  - tom_ 4y ago
    I never used to quit vim either!
  - ghosty141 4y ago
    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
joseph8th 4y ago
Once it starts it does almost nothing unless you're using it, and then it's still a lightweight document editor, not an Electron app
BeetleB 4y ago
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?
- dotancohen 4y ago
  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.
  - BeetleB 4y ago
    And stock Emacs load time is virtually instant.
oh_sigh 4y ago
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)
dotancohen 4y ago
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.
nurbl 4y ago
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.

tom_ 4y ago

Why do you quit though? I don’t quit other programs... why is Emacs different?

massysett 4y ago
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.
- tom_ 4y ago
  I never used to quit vim either!
- ghosty141 4y ago
  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

joseph8th 4y ago

Once it starts it does almost nothing unless you're using it, and then it's still a lightweight document editor, not an Electron app

BeetleB 4y ago

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?

dotancohen 4y ago
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.
- BeetleB 4y ago
  And stock Emacs load time is virtually instant.

oh_sigh 4y ago

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)

dotancohen 4y ago

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.

nurbl 4y ago

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.