1. 48
  1.  

  2. 12

    I’ve been doing this for a few months and it’s a huge quality of life improvement. I don’t have a very heavy emacs config, but it still takes a couple of seconds to launch emacs- enough to make me reluctant to open it for quick edits. Emacs client makes that almost instantaneous. I also tend to open a lot of frames for different work contexts, and having a persistent client really makes it nicer to manage- especially lately as I’ve switched up my window manager and keyboard and have had a bad string of accidentally killing windows in my DE lately.

    1. 7

      I actually stopped doing this a little while ago partly because of the user environment stuff mentioned in the article but mostly because of some oddities that crept up when connecting to my machine over SSH and attaching to the Emacs daemon. Sometimes it would refuse to start a TTY client for reasons that remain a mystery.

      As for the environment stuff, I consider exec-path-from-shell to be an awful hack that I simply can’t trust. (Going so far as to say “it gives Emacs a bad name” is on the cusp of acceptable, but too damning.) If you’re going to set enviroment variables for use by Emacs started through systemd, then you should look at environment.d. If you know it’s going to be started through GDM, then you can take advantage of the fact that $HOME/.profile is sourced by /etc/gdm3/Xsession.

      And if you do use environment.d, then beware of the contents of /usr/lib/environment.d/99-environment.conf on Ubuntu 20.04 (and possibly others) that sets PATH without any regard for the current value; it will probably be the last environment conf file run if you follow the number-prefix model. You can run

      SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator
      

      to see how the environment conf files will be processed.

      1. 3

        Recently I have stumbled on https://gitlab.com/blak3mill3r/emacs-ludicrous-speed/ and have decided to recreate the results with simple shell scripts combined with sudo (so without a service at all, and directly using criu not the python wrapper) and it does make emacs process restore blazing fast as advertised.

        When dumping “emacs –daemon” it runs within my user’s own environment - no magic required, and is pretty much good enough for me.

        Only hiccup I had was the need to recompile Emacs without dbus for the dump process to work flawlessly but that’s a small price I think (criu can’t dump a process with connected unix sockets and disabling dbus in emacs was easier than shutting down dbus daemon).

        I’m running this setup just for couple of days only, so can’t say anything about stability of the approach but even now I can say I love it. I might dump the approach (pun intended) when native compilation gets merged to master just to have even less apparent complexity. I guess it won’t be faster - hard to beat restoring from a process image probably but might be good enough.

        1. 2

          Thanks for the feedback! I’ll add a mention of environment.d in the article.

        2. 4

          This is a very good presentation of a concept that I’ve been struggling to grok. Kudos.

          1. 3

            Thanks!

          2. 4

            There is nothing stopping you from doing the same thing and running Emacs as a launchd service for those who still want the Mac but also a persistent emacs server in the background.

            1. 3

              Yeah, you can do it, but using the client is not as convenient - e.g. you need to use Automator to create some wrapper around emacsclient -c so you can invoke this from Spotlight. (https://stackoverflow.com/questions/39464975/launch-emacsclient-with-gui-from-dock-on-mac-os-x) And coming from Linux launchd is not the most appealing service manager. :-) This is one area where there’s plenty of room for improvement in macOS.

              1. 4

                This is probably Stockholm Syndrome from my days on the farm, but I always really liked launchd.

                1. 1

                  Managing launchd with Nix is a breeze.

                2. 3

                  Homebrew includes the launchd definition (brew services launch emacs). Invaluable for Spacemacs.

                3. 4

                  This is nearly identical to what I do except I keep my emacs.service in ~/.config/systemd/user. Makes more sense, to me anyway, for keeping my personal dotfiles organized.

                  1. 3

                    I recently built Emacs 27 and found the startup time on that so fast that I simply wasn’t worried about trying to improve it. If your use case requires background Emacs obviously that doesn’t help, but I was impressed.

                    1. 7

                      Emacs boots pretty fast with no config, but with a huge config it’s a whole different story.

                      1. 2

                        I have a medium config, with modern package management. I’d expect 27 to still be noticeably faster with a large config.

                    2. 3

                      I’ve been playing with running emacs as a daemon and the one thing that I can’t figure out how to get to work “right” is project (python virtual environment)-specific processes.

                      My emacs configuration boots quickly enough on my Mac laptops and most cloud environments I work in. I recently changed jobs and in my new AWS+EFS+corpAD world emacs often takes over a minute to start (discussed a bit with the author of the straight package manager. I think, based on a bit of strace output, that the delay is due to emacs walking down all of the directories on my load-path and trying to each file that it needs (many of which are in the system dir, which is at the end. The pathology is something about this environment, I stood up a personal instance with an EFS home dir and didn’t have this problem.

                      In my current world the dev tools for various python projects are part of those project’s venv, so I end up having to kill and restart the daemon as I change what I’m doing.

                      Is there a better way that I could be managing this?

                      1. 3

                        And I thought the article was about Emacs being reimplemented in systemd! Wouldn’t have been that surprising ;)

                        1. 2

                          Sorry to disappoint! :D :D :D

                        2. 1

                          I hate to be that guy, because this thread very much feels like an emacs safe space, but I’ll go ahead anyway.

                          I’d always run Emacs as a daemon (server) and I’d connect this daemon from multiple instances of emacsclient. This was both elegant and efficient

                          I’m sorry, but that does not sound elegant or efficient to me. emacs is the only editor I’m aware of that’s so slow you have to run it as service to keep it snappy. That’s the exact opposite of efficient.

                          Speaking of which, how is it possible after all these years that there’s no other lisp centred editor out there with any significant user base besides emacs? Is it really that hard to write? Or are people that commited to keeping emacs around?

                          1. 3

                            I’m sorry, but that does not sound elegant or efficient to me

                            Emacs optimises for user efficiency, not computer efficiency.

                            1. 2

                              The daemon is to allow a start-from-scratch to happen only once, which can take a few seconds. After that, new instances launch instantly.

                              It has nothing to do with how snappy it is in interactive use as an editor. But it that regard, it’s also snappy.

                              1. 2

                                The daemon is to allow a start-from-scratch to happen only once, which can take a few seconds. After that, new instances launch instantly. It has nothing to do with how snappy it is in interactive use as an editor.

                                Right. I understand that. Even with that clarification I maintain my position.

                                1. 1

                                  I guess you’ve never used IntelliJ or VSCode or anything based on Electron, just to name a few?

                                  1. 1

                                    Used them? Yes. I’ve tried Atom, and intelliJ. I’ve used PyCharm and Eclipse at work. I have vscode installed on my work laptop presently. But I would never call myself a user of them.

                                    Those are designed to be IDEs though. While they are slow, intellij especially, they are a different category of software.

                                    Apples to apples. Compare Emacs to Vim, kakoune, nano, vi, Ed, or xi. All start fairly instantly regardless of your configuration and none require you to have a service run in the background.

                                    1. 3

                                      To get it out of the way first – I’d guess that most emacs users would gladly accept a snappier version of emacs, both in terms of startup time, and in terms of packages that don’t slow down the user experience. There are plenty of projects aiming to make emacs faster in one way or another. But I think that to set one’s focus solely on performance will always miss the point as to why people pick emacs in the first place. Or put another way, if performance is your #1 feature in an editor, then emacs is probably not for you. I think emacs users love their editor despite its performance issues.

                                      Compare Emacs to Vim, kakoune, nano, vi, Ed, or xi.

                                      Yeah, so I’d never compare emacs to any of these editors, except for maybe vim given its decent - if not ergonomic - extensibility. The only similarities I can think of between emacs and these other editors are that they’re either both old, or were initially designed to run in the terminal, or generally give the user some sort of hacker street cred.

                                      To me, and to most other emacs users I’ve talk to, our “aha” moment with emacs was realizing that, more than a text editor, it’s a live-programmed computational environment with a programmable text interface. It’s actually quite a modular environment within its borders. It’s up to the user as to whether this value prop grabs them or not. The editor part of emacs turns out to really just be one part of a much broader toolchain which integrates in powerful/whimsical/confusing ways. It’s sort of a ridiculous tool, and I think that once a user decides that they like this, they end up putting up with the warts including not only performance, but inconsistent APIs, weird defaults, and other issues that are commonly found in older technologies that survive this long.

                                      1. 1

                                        Yeah, I put emacs with IntelliJ and Atom; if you’re not using it as an IDE, it starts basically instantly. Maybe vi can be a valid comparison, if it’s similarly set up for all the code related business, but otherwise, your examples are outrageously invalid.

                                        So yeah, your argument boils down to, “I hate emacs because it provides an easy and built in mechanism for quickly opening an advanced editor window with any files I need to edit,” so thanks for your insight!

                                        1. 2

                                          I hate emacs

                                          Let’s slow down here. I never said that. I never even implied it.

                                          I did, however, say that it doesn’t seem fair to call having a text editor as service “efficient”. And I stand by that.

                                          I also stand by my question of how there are no lisp focused competitiors to emacs. Why does vi have so many clones or vi-like competitors and emacs none? Surely I’m not the only one that thinks that’s odd.

                                2. 1

                                  I actually think most editors nowadays have a client-server architecture. At the very least, vim does. From there it’s a small step to manage the server with a service manager.