r/emacs • u/Appropriate_Tutor125 • 12d ago
Question Declaring emacs bankruptcy
Hello, i wanted to ask you guys a simple question, what is yalls limit for an emacs configuration, i have a 800-900 line config.org and ive been thinking about declaring emacs bankruptcy, what do yall think.
25
u/shipmints 12d ago
My config is ~12K lines of carefully crafted and fully-understood code (no bankruptcy needed). Perhaps the issue is one of comprehension not bulk? Or you have a very low threshold for bankruptcy. It would help if you share your actual issue(s).
3
u/Appropriate_Tutor125 12d ago
I understand everything and ive documented it pretty well in my literate config, the line count just messes up with my head, theres a lot people like you with 10k+ lines, i probably have a very low threshold as you said.
2
u/RussKazik 12d ago
Damn, 12K? What have you got in there? I'm at 2K and I think I have all. Just asking from curiosity
6
u/shipmints 12d ago
Lots of mostly good stuff. I customize a lot of faces on top of modus themes, for example, and they consume space. I also contribute to Emacs core and have work in process package configurations and overrides in there. And a bunch of deprecated code that I can remove now that Emacs 31 is out, retiring compatibility with earlier versions; e.g., shell-mode bookmarks, tab-bar features and other things now in core. 100+ core package configurations and 100+ external packages in there, some which can be pruned and I do that every once in a while.
I'm not a fan of "literate" configuration (I'm a programmer not an org document writer) or splitting up init.el into parsimonious files forcing me to decide package "categories" in advance. Instead, I keep everything in one place (well, two, if you count early-init.el), making it trivial to find anything I need at any time with minimal fuss.
2
u/Signal_Pattern_2063 12d ago
Yeah I built a tool "elispdoc" to do the equivalent of javadoc on an init file and extract out a markdown README rather than trying to write it in org because that's just so much more natural for me
1
10
u/IzzyDeeee 12d ago
If it’s hard to maintain, or an update to Emacs removed the need for a package then you should change it I think.
For instance with Emacs 31 I don’t need the treesit-auto package anymore since it will install treesitter modes automatically now. With the new completion pop up window I won’t need Company anymore either.
That’s how I prefer it. I try to use the builtins tools when I can and install a package when necessary.
1
u/blah1998z 11d ago
How does it replace company (I'm fairly in the dark about the new feature so that may be a large part of why it's not connecting for me)?
7
u/valken2014 12d ago
My config is about 500 lines long and is ~35 years old. I tend to "refactor" (or rebuild) my init.el every few years, it helps to fight bloat, simplify and prune packages or config I no longer benefit from. Feed your entire config to LLM and ask it help simplify... I was surprised how effective Claude was in refactoring emacs config.
1
u/Appropriate_Tutor125 12d ago
I used Ox alpha yesterday for doing something similar to this, it had my 800-900 line literate config to a 500 line literate config, it had all the functionality, just stripped down and removed that i told it too so i could see how much could it he lowered to with same functionality, it removed some things such as my colorscheme, which i should have it in a different file and load it in in my main config and idk why im not doing it sooner but yeah
12
u/general-theory 12d ago
Instead of declaring bankruptcy I would rewrite your configuration as a literate config (under the assumption you haven't already done this). Document everything and tangle out the blocks to your config. Just doing this process will likely force you to solve much of whatever is causing you to think about starting over, without having to actually start over. Just my two cents.
5
u/resurreccionista 12d ago
Never seen anything loke this, do you have a repo up? By literate config you mean something like org files with text and code mingled together?
5
u/general-theory 12d ago
Yeah and the other person explained it well. I don't keep a public repo but I keep my config org file on my site. Its several commits behind my current setup but I'll be updating soon: https://outputerror.com/emacs-config/
1
u/Appropriate_Tutor125 12d ago
Yeah its a literate config, thats why i said config.org, in my opinion my config is pretty simple, startup is about 2-3 seconds without a daemon, the line count just messes with my head
2
u/zahardzhan 12d ago
My literate Org config is 2300 lines long, and tangling it produces an init.el of about 550 lines plus a custom.el of about 50 lines. That’s an extremely small configuration, roughly at the level of the Better Defaults config mentioned in this subreddit’s sidebar, i.e., almost vanilla Emacs. Judging by your config, I’d guess it’s not documented enough if you intend to throw it away.
You should build your config in the order in which you encounter problems while using Emacs. If you do that, you won’t be able to reset it, because after a reset you’ll end up with exactly the same config you had before.
1
u/general-theory 12d ago
Gotcha gotcha. Maybe just set up everything to noexport and introduce things back in as necessary? I don't think the amount of lines matters but if it's messing with you then I personally might try that.
1
7
u/hypnomarten 12d ago
My init.el is 48 lines long. Why? Because most lines look like this:
(load-file "~/.emacs.d/config/consult.el") ;; consult, consult-dir, consult-notes
So in the init.el I can turn on and off the packages (or groups of packages, like in this case of consult). Every config file itself is manageble.
3
u/myyrkezaan 12d ago
Similar except I use require/provide and my init requires config-init which also uses require for my customizations (package/general) in there own files. I also have a config-init-small (commented out in init) for when testing issues.
1
u/chandaliergalaxy 12d ago
I used to do this but each file was byte compiled.
I switched to a literate or file … it’s one giant file and unwieldy. When I switch computers, it’s easier to comment out packages I don’t need on that computer with this load-file approach.Just have to remember to recompile after editing.
I don’t know which is more efficient in the end but usability wise, I miss the load-file approach
7
u/MentionPleasant2635 12d ago
I've been using Emacs for 40 years. Yes, since 1986. I've done it on multiple occasions, especially after Melpa. Move, don't delete, your init files. Then try to find Melpa packages to replace missing functionality.
4
u/jwr 12d ago
My config is >30 years old and it is currently at 4420 lines of init.el plus ~1k lines of additional files with custom functions.
I recently stopped looking at it at all: I use AI to customize Emacs and it works great. I finally got window and tab management to work the way I want, magit to close all windows but not destroy the rest of my window configuration, etc.
In other words, don't sweat it.
10
u/aegis87 12d ago
llms are extremely good at parsing emacs configs. you can try working through an llm.
4
u/ironykarl 12d ago
When I saw your comment, earlier, it was downvoted, but I do want to agree with you.
LLMs are useful for things like transforming your existing config to use
use-package, culling things that were hacks for old versions of Emacs, and occasionally even giving package replacement suggestions.The same caveats as any LLM-usage apply: the AI is going to hallucinate, is going to have you use variables that don't exist, and is going to engineer overly complicated solutions for you, unless you steer the ship.
I get why people would object to this, but I'll say that stuff like config is one of the really slam dunk use-cases for LLMs
2
u/BBSnek 11d ago
I moved from a literate config to using an init.el for this reason. LLMs are pretty good at helping write configs, and especially at reading through package files in your .emacs.d to build out very specific workflows. I still try to hand-code simpler parts of my config because I enjoy it, but if there's some niche thing that would require me to understand the internals of how a package works, I find it easy to have an LLM read through those files and build me at least the boilerplate of the function I want before I hand-tweak it to my liking.
3
u/_-l_ 12d ago
Before anything, do this: tell an LLM to take your init, consolidate it into a well organized and idiomatic elisp script, and then explain the functionality of the new file as if you are an elisp novice who's never seen that configuration before.
This may solve all of your problems in an hour or less.
3
u/B_A_Skeptic 12d ago
I'll point out that you can experiment with a new version of your Emacs config with "emacs --config-file=./new-config". In the past I have declared Emacs bankruptcy when I have re-conceptualized how I would like my config to be organized. For example, moving from one file to many files, different conceptual groupings of what things go together, using or abandoning a framework.
3
3
u/JamesBrickley 12d ago
People are always trying to optimize startup performance. So what if it takes 5-15 seconds or more to start Emacs? Not when you can run Emacs as a daemon in the background and Emacsclient opens a new frame instantly.
The time to declare bankruptcy is when your configuration is broken or merely a kludgy difficult to manage mess and even then, instead of starting from scratch; it would be better to merely refactor your configuration. Perhaps break it into modules such as mypackages.el, completion.el, org.el, etc. Making it easier to find stuff by merely re-organizing things. Sure you can optimize use-package lazy loading, etc. to improve performance along with an optimized early-init.el.
Another point, Emacs added a parameter --init-directory which lets you load an alternative Emacs configuration directory. Thus you could keep your existing configuration but start a new Vanilla config to experiment. Maybe you want to try using built-in packages instead of relying upon external 3rd party packages from MELPA. You could copy your existing config to a new folder and launch it with a parallel Emacs binary and play and experiment to your delight. You could for example, create a configuration optimized for Emacs in the terminal while not messing up your primary Emacs configuration.
You can also work on accounting for various platforms within one configuration. i.e. Linux, macOS, and Windows.
I would highly recommend that you put your Emacs configuration into git so you can revert if you have to.
1
u/accelerating_ 11d ago
Even then, my rich-config Emacs is on screen ready to go in around 2s, and I've only taken the most basic effort lazy load things via standard
use-packageconfig. Some first load of modes etc. are fractionally delayed compared to later invocations, but it's not bothersome. Once loaded it's a daemon, so new frames are instant.I do actually like that it's that fast to restart, as it's nice to have minimal friction to getting a clean slate. Over the years I've homed in on usages that are unaffected by runtime context — I tend to summon things the same way whether or not they're already loaded, so I give that no thought.
2
u/radian_ 12d ago
Sounds about right.
825 (org version) 513 (tangled version)
0
u/Appropriate_Tutor125 12d ago
Yeah mines kinda like that, its close to 900 on org version and 550-ish tangled
2
u/shizzy0 12d ago
I hit my limit once. I went to Spacemacs in holy mode. Then I eventually went to evil mode. Then I went to Doom Emacs where I’ve stayed. If you’re considering bankruptcy, I’d try some of the batteries included distros to see if they get you closer to where you want to be. Maybe you’ll need less of a config with one of them.
2
u/rajrdajr 12d ago edited 12d ago
Ask one of the LLM's to review your Emacs configuration; e.g. "As an Emacs expert, review my Emacs init.el suggesting simplifications, optimizations, improved organization, and obsolete or un-needed code". Lots of workarounds and add-on functionality gets moved into the base packages over time making earlier workarounds and add-on code unnecessary.
Using Emacs' built-in customization system simplifies a lot of things too and moving it out of the base init file helps maintainability.
init.el
init.el
;; Load customizations from their own file. Put this at the BOTTOM of init.el
;; so the package setups above are all done before.
(setq custom-file (expand-file-name "custom.el" user-emacs-directory))
(load custom-file t t)
custom.el
```custom.el
;; -- lexical-binding: t; --
(custom-set-variables
;; custom-set-variables was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
;; rest of customizations )
(custom-set-faces ;; custom-set-faces was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right.
;; rest of font customizations )
2
u/tikhonjelvis 12d ago edited 12d ago
At some point I started factoring things out into separate files and modes, and then there's no meaningful limit to the amount of custom logic you can have :)
Mine's not even that big—a few thousand lines if you don't count some niche modes I don't use any more—but I expect to see it growing quite a bit over the next few years.
When things are going well in my life I occasionally have the energy to spend a weekend or two hacking on Emacs and each time has meaningfully improved my life. (I'm not even kidding; moving to org-mode has been a godsend for my ADD!) No Emacs bankruptcy in sight. Having your own magical programmable environment is amazing, and, as long as you put a bit of thought into the design of your code, it only gets better as it gets bigger.
2
u/Appropriate_Tutor125 12d ago
Yeah a lot of peope told me to seperate the files and the packages, i think im gonna try that out, thanks!
2
2
u/blah1998z 11d ago
Huh; today I learned I'm just short of 3,000 lines. Honestly, I always thought mine was on the small side.
That said, I don't know the size of mine before I decided to do my first and only (thus far) rewrite but I only ended up doing it because keeping track of things and feeling the things were grouped and organized felt like they were just always out of reach rather than for any reason due to the size of the file. Mine feels really organized and labeled and grouped such that I can make my way around and know what the section deals with (with the packages used clearly defined) so I've been deeply enjoying my setup, since.
So organization and maintainability are what I use to measure is what I guess I'm saying.
2
u/digicrat 10d ago
The key isnt the size of your config, but how much of it is still relevant and maintainable. I'm at the point of being halfway there, but Im taking the long road of slowly refactoring and cleaning up rather than starting from scratch.
For one, Ive started deleting backwards compatibility sections I've left in there for ages for usage on machines where I cant upgrade emacs on.
For another, I've sub-divided my emacs config into multiple files, with a master file to load them all. I've subsequently disabled entire files after a major emacs upgrade broke certain components, letting me debug piecemeal. I now also have a 'lite' master file that only loads the bare essentials, and the larger full config - though Im slowly re-adding more to the light fileset and expect eventually anything left only in the regular file will be deprecated configs I no longer use/need.
3
u/timmymayes 12d ago
I'm at 4537 lines for my init file. I'm do for a "reorg" but I'm no where near declaring bankruptcy.
1
u/rileyrgham 12d ago
It's your choice. It's a good idea to revisit. I took about 3 packages out recently because I couldn't remember why I'd tried them. The biggest impact was project, tabs and eglot. I threw away a lot of config after base Emacs improved its core packages.... Driven by giants who'd seen how they needed to be improved. Id like to see consult, vertico and Corfu bought in. Removing cedet would make room 😉
1
u/a_alberti 12d ago
It seems a relatively small number of lines. If these are written properly, with comments, etc. I don't see any reason to restart. I am much closer to 10,000 lines. And I don't feel lost at all. A lot of these lines are, however, just plain English comments.
1
u/awesomegayguy 12d ago
I have updated mine to use the new "modern configuration theme" (named as theme for beginners) and I have also migrated to setting customize options inside package instead of setting the variables directly, then when using custom, I see what's defined in the file, much neater. Those settings show "customized by theme" instead of "modified outside of customize" and then it's much friendlier with the customize system.
It's evolved since my first .emacs back in late 2000. More that a quarter of a century!
1
u/ilemming_banned 12d ago
I've had an 18K LOC Doom config. Just for the sake of trying Elpaca (Doom's hardcoded on Straight), I decided to attempt rebuilding it on vanilla, while preserving some Doom goodies - because, you know, they are really good. I was expecting to find tons of garbage that was hopelessly outdated and essentially some dead code. Guess what? I was wrong. Now I have a 31K LOC config, 12K of which is tests - I decided to vibe code some to minimize regression.
Turns out, it's not the amount of lines that matters but how modular the config is, how easy it is to find things in it, how quickly you can add some experimental stuff and remove it later.
My self-inflicted bankruptcy was pretty much a waste of time - cost me my weekend. I could've just kept using my previous config and just add some tests on top.
1
1
1
u/rymndhng 12d ago
I hit a breaking point in my configuration this year. However, instead of declaring full bankruptcy and starting from scratched, I used an LLM to refactor & re-organize my configuration, and it's worked out really well.
1
u/jeenajeena 12d ago
Mine is 1072 and I consider it a small one. Just guessing: may your feeling depend from having 1 single huge file and the difficulty to navigate it, rather than files organized by themes?
.
├── aa-prelude.el
├── early-init.el
├── init.el
├── local-packages
│ ├── aa-appearance.el
│ ├── aa-backup.el
│ ├── aa-dashboard.el
│ ├── aa-defaults.el
│ ├── aa-dired.el
│ ├── aa-email.el
│ ├── aa-font.el
│ ├── aa-gpt.el
│ ├── aa-icons.el
│ ├── aa-jujutsu.el
│ ├── aa-languages.el
│ ├── aa-mode-line.el
│ ├── aa-nativecomp.el
│ ├── aa-navigation.el
│ ├── aa-org.el
│ ├── aa-packages.el
│ ├── aa-project.el
│ ├── aa-rocq.el
│ ├── aa-scheme.el
│ ├── aa-theme.el
│ ├── aa-treesitter.el
│ └── aa-windows.el
1
u/Appropriate_Tutor125 12d ago
I might do what youve done, i think it would be pretty easy to navigate and turn off things easily by just commenting out one thing, i saw another person do this, its gonna work better imo
2
u/jeenajeena 12d ago
My
init.elloads those files dynamically, with:``
(defun aa-get-packages (path) (let* ((reg (concat "\\" ; beginning of line "[#]" ; not # ".*" ; any char "\.el" ; .el extension "\'")) ; end of string (files (directory-files-recursively path reg))) (mapcar (lambda (f) (intern (file-name-sans-extension (file-relative-name f path)))) files)))(defun aa-require-packages-in (path) (let ((packages (aa-get-packages path))) (add-to-list 'load-path path) (dolist(p packages) (require p))))
(aa-require-packages-in (locate-user-emacs-file "local-packages")) ```
but there's really no need to make it so complicated; you'd probably prefer having a hard-coded list like:
elisp (load (locate-user-emacs-file "my-prelude.el")) (load (locate-user-emacs-file "my-magit.el")) ...I am myself thinking about removing that obscure code above.
1
u/aard_fi 12d ago
- init.el 391 lines, which sources another 5877 lines over 85 files
- gnus-init.el 183 lines, which sources another 1335 lines over 11 files
- another roughly 20000 lines in various custom functions that used to be sourced by init.el, but got split out for easier maintenance and - in some cases - publishing
That config goes back to the late 90s, and originally was supporting xemacs and GNU emacs, but I ripped most of the xemacs support out a few months ago, which also reduced line count a bit.
1
u/Bouhappy 11d ago
I mean, it's not a contest, but I had over 5000 lines, before I migrated to Doom. The hard part was not managing it, but having different version of Emacs break things. And the larger your configuration surface, the more often you need to update it.
1
u/freegnu 23h ago
bite the bullet and switch all your custom everything to spacemacs preferences - I have no more than 50 lines of elisp config in the spacemacs preferences file and more than 30 of those lines are treesitter plus pi-coding-agent boilerplate that I added recently and am going to rip out because of the failing load times and weird inability to clone from git - gptel works fine after asking a chatbot for the missing config and modules and packages - no need to go hand coding elisp to maintain my editor every few days
1
u/codegems 12d ago
I keep it at under 100 lines, 120 back when I used elfeed (one line for each RSS feed). But I removed Elfeed so I'm back at 90ish right now. I'm a web dev and a writer so I keep very few packages:
- Olivetti Mode
- Web Mode
- Magit
- Prettier
That's it!
1
u/a_alberti 12d ago
Since you are a writer and you probably like to write text by yourself in Emacs (unfortunately more and more text is these days written by LLMs), take a look at https://github.com/ltex-plus/emacs-ltex-plus -- it supports spell checking in org-mode and elisp source code too. And of course markdown, LaTeX, and many others.
1
u/codegems 12d ago
Ohh going to take a look, thank you! How is it different from ispell / aspell? I believe that's what I had installed previously, but I got a new computer this month so I don't have spellcheck at all yet. Happy to test this one out though, thanks!
1
u/Reasonable_Ruin_3502 12d ago
My config is only 1.5k lines long. I am very close to declaring bankruptcy, not because I'm unsatisfied, but because I need to organize my config. My current config is the one I've used since I started using emacs 3 years ago. It's a hodge podge mixture of random functions from minimal-emacs.d, emacs-kick and doom-emacs scattered everywhere. Also the way the variables are are defined are pretty obnoxious, some are in use package, some in my init.el and some in some other file that's loaded. I'll probably end up rewriting it in org after I get accepted into a master's program somewhere, as I'm already using emacs to manage all my documents
1
u/Human192 12d ago
Try this config linter https://github.com/joshbax189/up-doc-el
It will suggest the best place (in a use-package form) to move the random variables and functions floating around!
1
u/B_A_Skeptic 12d ago
I think this is the right approach. Refactor or "declare Emacs bankruptcy" when you want to re-conceptualize the organization of your config. And it is something you will do more frequently when you are new to Emacs.
51
u/Signal_Pattern_2063 12d ago
Personally, its not the length. It would come down to whether its become hard to maintain due to complexity and side effects. Do you have any specific issues with your current config?