I saw an amusing Reddit post recently with an Emacs user thinking about declaring “Emacs bankruptcy” with a config file falling in the 800-900 line range.
Many users in the replies were happy to point out that even 10-12K lines is nothing if you understand what’s going on, and it’s well-documented.
This reminded me of something I’ve been experimenting with lately. Instead of updating my config, I’m trying out directory-local variables per project.
Having local configurations in a project avoids the extra cogitation of worrying about conflicts with other file types or projects down the line. I like this. Also makes settings easier to transfer to a similar project in the future.
Table of Contents
Keeping it local
The bedrock of my init file has not changed much over the years. I don’t even use a theme for very long before succumbing to the default colors. Most of the time the editing I do in the config involves tweaking wrap and fill settings or adjusting export functions for different writing projects.
I’ve made use of various hooks that trigger slightly different settings for writing and programming modes. But now I’m keeping it local.
Creating a dir-locals.el file right in your project’s working directory lets you set local variables and custom functions that will apply to all files in that directory tree but nowhere else in Emacs.
I’ve found this incredibly helpful for managing compilation settings for different writing projects with slightly different deliverable formats. Instead of configuring multiple export options as needed, I can just edit that build file once per project.
Evaluate on entry – juggle settings with ease
The “dir-locals” file evaluates when you open that project directory. So if you don’t visit that directory today, none of those settings will take effect.
I like to keep to keep my init file pretty lean anyway. I have a habit of throwing things in as a trial and then letting them linger past usefulness.
The nice thing about having these directory-local functions is that they stay with the project forever, and I can tweak and adjust without having to touch my minimalist config.
Over the years I’ve had to oscillate needlessly between hard vs soft line wrapping. In some cases I needed soft wrapping in org documents used for my blog, but preferred hard wrapping in plain .txt files. Likewise, I might prefer to have Olivetti mode ON for a fiction project, but OFF for a technical writing project.
These minor problems no longer vex me. With directory local, I can easily have one project with auto-fill-mode set at 60 characters per line and jump right to a project with visual-line-mode soft-wrapping with no sweat.
Put the right stuff where it needs to go
In most cases the big, unmovable landmasses of your editor configuration will go in your init file. But directory-local is there for settings that should only apply to that particular project.
The separation might look something like this:
| Init file | Directory local |
|---|---|
| Theme, font, style | Compilation/build settings |
| Modeline | Linters |
| Editor defaults (auto save, backups) | Fill-column or wrap settings |
| Org agenda stuff | Indentation styles |
I like having this directory-local option in the back pocket so I can focus on one project at a time. Also, I think it’s nice to have a quick and dirty way to try a certain variable on before blasting it out globally.
Update on the hacker novel beta reading call: big BIG THANK YOU to everyone who reached out and offered their time and talent. I have received some great feedback and still waiting on some more. Then it’s off to a final draft run.
Here are some other nice items for you to check out:
- Check out my eBooks: Emacs For Writers and Git For Writers.
- Subscribe to the newsletter for occasional updates on similar topics.
As always, thanks for reading, see you next time.
Leave a Reply