Emacs bankruptcy – fix your Emacs and your life

Hi everyone, Jake here from Straightforward Emacs. Today I'll be discussing Emacs bankruptcy. We'll talk about what it is, why you might do it, if it's for you, and then I'll give you a little example of how I've done it and walk you through a little bit of my organization and obviously some tips and tricks. First, we need to discuss what is Emacs bankruptcy. Now, Emacs bankruptcy is when your innit file gets so large that you really need to start over. then you have declared Emacs bankruptcy and that's taken from the Emacs wiki and this is basically a term we use to describe starting over configuring Emacs often from scratch due to the fact that your Emacs configuration has become too long too confusing too bloated too messy and so on. So that begs the question is Emacs bankruptcy for you? Now bankruptcy is a complex thing um but luckily Emacs bankruptcy is free and can be reverted at any time given you're using some version control like git. So in this sense then um I suggest everyone declare Emacs bankruptcy at least once. You may be surprised what a fresh slate allows you to realize. How do we declare EMAC bankruptcy? I suggest that uh Emacs bankruptcy be taken as a chance to start over from a clean slate uh rather than trying to work with the pieces you have. Now what does that mean? That includes deleting your entire emacs.d folder. Okay, so mine happens to be inconfig. Everything in here, delete it. Just delete the whole folder because otherwise you're going to be left with cache files. you're going to be left with all these packages, all that sort of stuff. Okay, just wipe it. Boot up Emacs then to a clean slate so that you can remember where we're starting from. And if you want to do that while you still have Emacs, you can use Emacs-Q and you will get the clean slate Emacs. All right, this is our starting pallet. Now, let's talk about my Emacs bankruptcy. Where did where did my journey come from? I had a literate configuration. You can find it on my GitHub here that when Tangled, which is when we compile all of the org into uh Emacs lisp was over 2,000 lines. Um I realized when I started a new job a few months ago, I started with VS Code so I could hit the ground running and I told myself I didn't want to have to deal with configuring Emacs for my for my new tech stack. And that's when I realized that there was a problem. Uh, so I started over and I built a new configuration, the core of which is less than 300, less than 300 lines, which is incredible. And I swear to you, I used that configuration every day and I was paid for the work I did for it. Um, so this is an investment, right? Uh, declaring bankruptcy paid off. Uh, and it can for you, too. So, let's get started with a little reenactment, a little walk through, um, an example of starting over. So, I'll I'll just open up um over here a little bit bigger my my old configuration. Um and we'll just discuss a few things you want to do first. So, you'll want to discuss your basic priorities. Um will you be using Emacs in the terminal as I suggested in in my previous video or will you be using it as a GUI app? And and that actually is important because when you're using it in the terminal, you'll have certain considerations. In the GUI, you'll also have cons certain considerations. Um, or you could use both, which means you have to do both. Will you be using vanilla regular EMAC bindings, or do you want to use evil mode or maybe something new? From there, you can begin to make the more technical decisions, which will also depend on your skill, your interest, and your knowledge. For example, uh what kind of completion framework interests you? Are you interested in ivy like I used to use in my configuration? You can use all the icons. You can use ivy rich. Um you can use council along with that preient works with ivy ivy preient right do you want to use i do which is built in or do you even want to use vertico uh which is what I'm using now will you be using inbuffer text completion and if so which one so for example would you want to be using company or would you want to try something else would you want to try corfu and some of its extensions number two is to decide on a consistent way to manage your packages and configuration ation. Right now I am using and I'll open up my init.l. Right now I am using straight.el along with use package which I think is an amazing combo and it's so great in fact that it deserves its own video which I will produce soon. Um and I'll have some unique tips that you won't find in a lot of other places. Um so decide how you want to manage your packages and your configuration and stick to that. Okay. If you're using use package actually go ahead use use package for every package. All right. take advantage of the benefits that your package system provides. Now, use package um helps you create a very declarative reproducible Emacs configuration. That'll be in my next video. But remember, Emacs is declarative, right? Like you declare each configuration in Emacs. So, make it make sense, right? Like uh you want to you want to you want to think about how you're grouping configurations and you want to think about um the order of valuation. Just a quick tip, try to have your Emacs configuration be as order agnostic as possible. You don't want to have to um have later code rely on an earlier package. That's just a little tip from my later video that I'll discuss more. Tip number three is get to work adding in what you need and then ruthlessly avoid what you do not need. And I'll show you how I did that um almost right now. And then finally, number four is to prefer built-in functionality. um see where you can get away with not using another package. For example, I used to use projectile uh somewhere in here. Uh and no longer. I don't need projectile because I actually like the I like the built-in project. Worked perfectly fine. You'll be surprised how well that'll work, especially considering how many features are really really up to par these days. All right, so let's look at an example of starting over after my main points. Number one, manage priorities. Number two, consistent config. Number three, avoid slop. And number four, prefer built-in functionality. So, let's take a look at an example. All right, I'll split my screen here. We'll look at my old configuration on the left, and I'll open up my new one on the right. Okay, now let's see. Uh, I had a ton of basic Emacs configuration options all the way at the top here. Uh, and it turns out that I really did not need a lot of them. And how do I know I don't need them? That's because everything works just fine as is, right? If one of these things was life-changing, I think I would have noticed by now. Check out my old basic configuration. This is what I consider sort of the core like how how your tabs and spaces. Um, what is Emacs open to? Um, where's your fill column? Do you want to show line numbers? Those like basic uh core Emacs ideas. Here's my uh here's my previous one, right? And here's my current one. It's it's really just this right here. So, I avoided adding packages that I wasn't sure I needed. So, for example, smart pens. Let's look at my smart PNS configuration. I remember it being nice. I can't really say for sure. I think it was good, but I have it nowhere in my new one. And you know what? It's perfectly fine. I have not noticed a difference. Another one. Super save, right? Super save mode. This will automatically save your buffers. Here's all the configuration I used to have. And you know what? Turns out I don't even need that anymore because we have autosave visited mode, right? Everything works perfectly fine. Okay. Now, people often ask how to organize their innit. Files. Make this a bit bigger so we can see the full file. And I can prove to you we're only at 262 lines. And that's including all of this header information. People often ask how to organize their innit files. So I'll give you a few thoughts on that. Now my old configuration was in one mega org literate file which means like I said the source code and the commentary are mixed together in an ormon file and the elisp gets exported. That's great when I was first learning and it's also great to share because people can see my textual commentary um as well. However, my new configuration actually does the opposite. Um, it is just a pureel file. It's just source code and I have as few comments as possible actually. Now, why do I do that? I have headings, right? Like I I I have the standard code header. I mark package setup. I mark basic options. I mark things like themes, right? But I don't have a comment after every line, right? Why is that? Well, for one, most things are actually quite obvious. For example, does initial major mode right here, let's see, initial major mode text mode. Does this really require a comment? Right, I think we have a pretty clear idea of what's actually happening here. I only add comments where I might be confused as to why I set something a certain way or to remind myself how something works. For example, my scroll conservatively setting. I happen to forget why I set it to this number. So, I remind myself, for example, I recently realized that I can enable all themes is safe by setting t. And I kind of forget that because that's not entirely an obvious setting, so I added a little comment there. And of course, if I need more information, I can always open up the Emacs help control HV and get information on a variable. Second, should you use multiple files or one large file? And if so, is there a directory structure, etc.? I am generally not in favor of splitting configuration across multiple files. Yes, it may feel organized. However, um jumping within one file I find to be much more intuitive than managing many files. Yes, you can grap across multiple files. Yes, it's very quick. However, having one file contain all of your core functionality I find to be more organized. In my case, I have an init.l. This is almost everything, the core functionality. And then I conditionally load a file called programming.el. I'll show you where I load it. I use these three lines to load programming. And I I I build this file name dynamically, right? I've taken a lot of care to carefully build um reproducible declarative Emac setup that will be portable to any uh computer. Um so right now it automatically expands down here uh to where my folder actually is. And if that file exists right we will load it. Now what's in this file? This is my Emacs configuration for packages related to programming modes which are not core to my Emacs functionality. They are not configuring my MIDI buffer. um they are not configuring um my font size or my themes, right? For example, um if I want to have another laptop with a more paired down Emacs experience just for say um writing, I can just avoid installing or avoid loading my programming. Um and then I'll still have everything else as necessary. I do have my org mode configuration in the main file and I would split this but right now it is uh you know it's only like 30 or 40 lines so I'm really not going to bother this way we can have a more lightweight Emac setup if desired um and avoid installing heavier projects or just having a bunch of stuff um into in our system right now just for some concluding thoughts um I hope that this discussion has given you something to think about uh and we'll perhaps encourage you to go ahead and try declaring Emacs bankruptcy yourself. I will be making another video very soon if people are interested in my strategy for the perfect declarative clean reproducible Emacs configuration. I'll give you a little hint. It very much centers around use package and maintaining as much as possible within a given use package binding including keybinds. I'll discuss that more later. Um, so let me know. Um, and go ahead and try declaring Emacs Bankruptcy yourself. I'd love to hear in the comments if you have any ideas, any questions or thoughts. If you disagree with me, let me know. Feel free to share your results as well. Um, I'm curious to see. Also, as always, let me know if you have any future uh video ideas. Um, I'd like to hear those or other comments. I try to reply to all of

In this video I discuss Emacs Bankruptcy, the idea of starting your Emacs configuration from scratch in hopes of coming up with something better. I'll talk about what it is, why you should do it, discuss my own Emacs bankruptcy, give important points to consider, and walk through a little example. 0:00 Introduction 0:17 What is Emacs bankruptcy 0:46 Should you do it 1:10 How to 2:03 My Emacs bankruptcy 3:07 Main considerations 6:28 Example 8:23 Organization 12:13 Conclusion