I think these tips all make a lot of sense in realms far beyond emacs. Anywhere tech debt creeps in… Other editors, Linux desktop configs, software build tool systems, and software development itself. There something alluring about tweaking a system to be customized in a “perfect” but personally way… but it often only bites you in time. the longer I work with computers the more I appreciate resisting unnecessary connivance tweets, and learn to live with the defaults :)
One of the most painful tweaks I have made is switching to a non qwerty keyboard layout… this basically forced me to reconfigure loads of software, which all just feels like a mess of unnecessary work and maintenance. Especially since I use vi like bindings wherever possible and all vi mode defaults are qwerty based. I often consider scraping it all and going back to qwerty, but I’m not sure if I’m ready to relearn basically all my muscle memory for all software again. So for now I try to keep things the way they are, and resist adding complexity when possible.
> There something alluring about tweaking a system to be customized in a “perfect” but personally way… but it often only bites you in time. the longer I work with computers the more I appreciate resisting unnecessary connivance tweets, and learn to live with the defaults :)
I find the idea of optimising for being able to work on a brand new computer with default settings ludicrous, because it's completely at odds with the reality that I use the same computers for years on end and hence that's the mode I should optimise for.
As an analogy, if I only leave my home town every once in a while, I'm not going to live out of a suitcase 365 days a year, just to cultivate a sense of virtuous minimalism.
I totally agree with this point. I didn’t mean to advocate for no personalization, I think making a personal setup is crucial for having a usable work station, I don’t believe in one size fits all. it’s just that I have wasted an insane amount of time overdoing my customization, re doing it, and undoing it, and think that the article made some good points about how to prioritize what is worth customizing :)
> I find the idea of optimising for being able to work on a brand new computer with default settings ludicrous, because it's completely at odds with the reality that I use the same computers for years on end and hence that's the mode I should optimise for.
While I mostly agree with you, there are legitimate reasons to not "over-customize" things as well:
- The more you configure your environment, the more custom code you commit to maintaining over time. That maintenance typically requires some time and effort per year, especially after major software updates. In that sense, customization really is an "investment", and it can be either a good or bad investment.
- Some people work on servers where you can't just install or configure everything you want. For me, this made me switch back from e.g. Fish to Zsh: Some servers require me to use Bash, and switching back and forth between Zsh locally and Bash remotely is painless since their syntax is mostly similar, whereas switching between Fish and Bash on a daily basis was quite painful. (I tend to write a lot of for-loops etc. interactively when I'm using a shell.)
- Some people work frequently on other people's laptops. For instance, teachers, IT support, etc. I can imagine that for these people switching to say a Moonlander Dvorak keyboard would make their day job quite annoying, even though that might be a very good investment for e.g. a software developer.
> As an analogy, if I only leave my home town every once in a while, I'm not going to live out of a suitcase 365 days a year, just to cultivate a sense of virtuous minimalism.
On the other hand, other people do work as flight attendants, and probably do want to keep their bag packed and ready to go...
Likewise, probably the people that mention they want to work efficiently on "unconfigured" systems say this because it is a legitimate pain point for them.
Indeed. I was talking entirely about the idea of doing it by choice, not by practical necessity.
The server angle is quite often mentioned one level up from configuration files to advocate choosing e.g. vi, period, since it's guaranteed by POSIX to be available. But I think that angle is actually becoming less convincing over time, because poking around on servers in interactive sessions is becoming less common now that ops has had a lot of time to evolve.
To be fair to slugbyte_, I was not entirely responding to them and in part was just having a general rant against asinine forms of minimalism (which I think are somewhat common in dev circles and have on occasion fallen into myself).
I have to use different computers for work and hobbies, so I like that I can get some of my configs to match and therefore can allow muscle memory to handle a lot of my daily driving. if I had to use different editors, for example, it would be really irritating.
Any adjustment, customization, etc should save you more time than it consumes.
Some customizations are a no-brainer because you know and constantly use them, and they are simple. The farther from often-used functions, the less customization pays off. The more complex is your custom layer, the more expensive its upkeep is, so its benefit should be proportionally huge to be worth the time.
Tweaking something because it's sort of neat to have is just a way to play, to bring a bit of joy into your day. Recreational activity is important, but it should not be mistaken for productivity improvement. It also should not burden you with recurring maintenance costs.
> Any adjustment, customization, etc should save you more time than it consumes.
That's not the metric I use universally. Sometimes I commit to maintaining a customization that takes more time than it saves me if it affords me convenience or comfort. For example, I update key binds to be more comfortable, even if they take time to maintain over releases and take longer to type, just to save myself muscle aches. I do the same with getting my color scheme just right, as my astigmatism makes using many default color schemes painful.
So, I spend quite a lot of time customizing my config not for saving time or speed, but for comfort due to uncomfortable defaults.
I don't know how long you use another keyboard layout, but I would urge you to try qwerty for a week or two and you may be surprised how quick you can switch. I don't mean at full speed. It may be bad advice as I base it on my experience with using German layout and azerty at times (I use Polish programmer's layout which is just US with AltGr). The odd pair swap (z/y) is not really big, but all the special characters were a bigger thing for me.
Aside from what the article focuses on (being selective about which packages to install in the first place), I feel that making extensive use of the
(use-package ...)
macro keeps a large Emacs config manageable. It gives things a very standardised structure, as opposed to the config being pages and pages of arbitrary Lisp code of different vintages.
It helps me keep the config consistent regardless of if something comes from MELPA, or bitbucket/github/gitlab etc.
- I also keep my config in README.org an github which shows the preview by default
- Org mode also helps me keep the commentary alongside. I can even just mark stuff as TODO, COMMENT with keyboard shortcuts. Infact if you read the source instead you'll find parts with COMMENT that don't render in the default preview on browser on Github.
- The git + github bits ofcourse help me use branches/PRs where i can test out stuff. Eg. most recently i was trying out lsp-bridge over eglot.
I switched to using org-babel to manage my emacs config and it’s been helpful to keep things organized (and half-documented when I come back to it months later).
This is the best method I've found for managing emacs config complexity. I have thousands of lines of configuration in a single file, but the whole structure feels "not that big" because it is all organized into a logical hierarchy, with the gritty details hidden a few layers down, yet easily navigable with ordinary search features.
This idea rhymes with an approach I term PC hygiene. I'm amazed by the sheer crunk and mud that the average Windows user has on their PC and I'm convinced that this is the reason why so many people have a miserable experience on it. (And to be fair, Windows does its damnednest to contribute to the rot.)
Starting with a clean install, removing as much as possible that isnt actively used, using only clean installers via something like chocolatey, and above all being extremely cautious about installing any new program, all contributes to hygiene. For example I know that Adobe Reader will spray junk all over my PC and generally be aggressive about processes, reg keys, etc, whereas SumatraPDF wont. So Sumatra gets installed.
I really like this article's suggestion to leverage plugins instead of custom code, and to look carefully at what _modern versions_ of your software (editor, shell, etc) have feature parity with.
This mirrors something I noticed recently when snooping on a friend's dotfiles repo. I have this unholy collection of things that make sure bash saves my history, my prompt Doesn't Suck, with helps git/etc/etc -- and it's a nightmare because I have yet to untangle it enough to post on github. In contrast, my coworker uses zshell, and uses a plugin for it that basically adds _nearly everything I might want_ out of the box, and as sensible defaults, so their config is much simpler and easier to get started.
I use Doom[1], which is put together by people who know a heck of a lot more about Emacs than I do. Almost all my configuration is just turning on the features I want. Maybe once every year or two I check that my configuration is using stuff that has be superseded. This is super easy to use, gives me a great Emacs experience, and takes almost no work to maintain.
I built a starter kit [1] with this in mind: how can I leverage built-in functionality to the max? The stock setup installs only one package (`which-key`—now going to be included with Emacs 30!) and all other packages are opt-in. There's no framework: you just clone the starter kit once and tweak to your liking. I use this setup on most of my machines and I find it works pretty well.
On my personal machine, I have +2,600-line `init.el`. Fortunately I understand everything in there and I routinely modify it. It's been a long time since I declared bankruptcy. The built-in `use-package` macro really helps keep config tidy.
> Recommendation: Use the built-in (vertical-fido-mode). If you want something more, look into Vertico.
I dunno about fido-mode, if I were to recommend a built-in completion package I'd rather say icomplete is better (using icomplete-vertical-mode). It has the neat lazy-completion feature that Emacs and Zsh have where I can type '~/.c/r' and it shows me all possible completions (so both '~/.cache/rofi.druncache' and '~/.config/rofi/config'), rather than eagerly completing on the '.c/' and leaving me stuck in '~/.cache/'.
That being said, I don't see the problem with declaring config bankruptcy, it gives me the chance to avoid making old mistakes in exchange for making exciting new mistakes, which I can learn from.
This used to be the case until Emacs 24.1, in 2012.
Passing a nil argument to a minor mode function call now ENABLES
the minor mode unconditionally. This is so that you can write e.g.
(add-hook 'text-mode-hook #'foo-mode)
to enable foo-mode in Text mode buffers, removing the need for
'turn-on-foo-mode' style functions. This affects all mode commands
defined by 'define-minor-mode'. If called interactively, the mode
command still toggles the minor mode.
Three years ago I realized I had hit the same point. My .emacs file was about 500 lines long and many of the options dated back to 1997 when documentation of why you’d want to do something was sparse.
I rewrote it all using org-babel and use-package. It’s even longer now, but each package has documentation of why I’m using it and how. It makes life much easier.
I recently rewrote my 15 year old and very long/unmaintainable config. The main thing I did was break up my config into separate files per major mode. All package installation is in one file though, because minor mode packages are shared between multiple major modes.
That just solved the maintenance and editing problem. Each major mode only takes 5-100 lines of config. Lots of major mode specific custom code, but now I know where to look if something is off. Reasonably simple to evolve.
IMO, the real headache is installing the supporting binaries ripgrep, fzf, lsp, tree-sitter, native-compilation, etc. I agree that emacs config should hew as close as possible to the defaults, and my init.el is pretty small. For the binaries, I build a docker container and run emacs in it. https://hub.docker.com/r/wwarner/emacs-gopy
I love the Docker option. Some alternatives worth mentioning:
- `use-package-ensure-system-package` can be used to autoinstall such binaries via the relevant `use-package` block.
- If you use a literate config, you can have executable shell blocks to install dependencies.
- If you use a package manager like Nix or HomeBrew (Brewfile), you can sync the package list. Bonus points for tangling those lists from a literate config.
- Some of those dependencies, including Emacs itself, are also available in `conda-forge`, and Conda is often available on servers. So you can also setup a Conda `environment.yml` to take care of your Emacs installation.
>packages interacting poorly in hard to diagnose ways
That's a problem of uncontrolled mutability and lack of type signatures. It's a common problem in python, ryby, javascript, emacs lisp and many others.
Emacs can run Rust, and it could be solved in the future, but i don't know what's going on with the GPL license. Can one make a dynamic module and use for example the tokio library in emacs when tokio is not GPL?
I had this problem a few times with Vim — installed too many plugins and custom scripts, things breaking at random times, slowdowns that are hard to diagnose.
That's why I now just use VSCode with nvim emulation instead.
I comment every line of my neovim configuration no matter how obvious it seems to be at the time. I assume when documenting that I won't remember what that config name does. Would that work for emacs?
Many people do that: “Literate configuration” is quite popular in the Emacs world, where you basically write your config as a “document with code blocks” instead of a “code file with comment blocks”. For a well-crafted example, see e.g. [tecosaur’s config](https://tecosaur.github.io/emacs-config/).
Part of the problem is that Emacs configs have traditionally grown much larger than the typical Vim/Neovim config :)
One of the most painful tweaks I have made is switching to a non qwerty keyboard layout… this basically forced me to reconfigure loads of software, which all just feels like a mess of unnecessary work and maintenance. Especially since I use vi like bindings wherever possible and all vi mode defaults are qwerty based. I often consider scraping it all and going back to qwerty, but I’m not sure if I’m ready to relearn basically all my muscle memory for all software again. So for now I try to keep things the way they are, and resist adding complexity when possible.