 So, it's a problem that a lot of us start having after a while. If you're one of those people that tinkers a lot with tiling window managers or with extensible text editors like Vim or Emacs, you know, eventually your config files start growing to the point where they become too large and unwieldy really to do anything with. You know, once they start creeping into several hundred lines long or in some cases several thousand lines long, you really need to take a different approach with your config because at that point maybe you have trouble following it yourself but especially when you start sharing your configs with other people like I put my configs out there publicly on my GitLab for people to try out and my configs are starting to get massively long and as an educational tool it's kind of hard for people to follow my configs now that they've gotten so big and I was starting to run into this problem and I really started running into the size problem here with my Xmonad config. I also was starting to run into some issues with my Emacs config because it was getting to the point where I really didn't know what was going on in some of that Emacs config file, you know, I was trying to comment everything so I knew, you know, when I added this line, this line did this and that line does that. So today I wanted to discuss some ways of cleaning up some of these config files especially once they get too large and they become unwieldy and one of the ones I really spent some time, I spent several hours this week working on my Xmonad configs and what I ended up doing was I went with a more modular approach with my Xmonad configs. So if you actually go over to my GitLab page and if you go to my dot files repository and you scroll down to the dot Xmonad directory and that is my Xmonad config right there, xmonad.hs. Now that thing had creeped up to over 1,000 lines in length the other day and that's when I decided I can't have that. So I took a lot of the sections out of that Xmonad config so if I click on it, this is now only 292 lines instead of 1,000 lines, it's because I took some of the rather large sections that were part of this config out. There was a huge section of key bindings right because I have you know probably more than a hundred lines of nothing but key binding so I took that out of the config, my tree select menu was also a huge portion of this config, I took that out, I took several things out. So if I go back into my dot Xmonad folder, you have the Xmonad.hs but now you have this new folder that I created lib slash custom and I could have named it slash lib slash anything. These are the names of modules that I create just to import into my Xmonad.hs and how you do this is very simple all you need to do is in your dot Xmonad folder create the directory lib and then within lib you can create sub directories name them whatever you want obviously if you're creating modules they should be something more descriptive for me you know I'm just putting all my modules into one directory I called it custom as in my custom modules. So how do you go about splitting up your Xmonad config into these modules? Well let's take the key bindings for example I created this document I called it mykeys.hs and all I did was this section starting right here that is exactly what I copied from my Xmonad.hs I just ripped out all the key bindings from my Xmonad.hs and put them in this other file now you can't just put the key bindings by themselves you do also have to import the various libraries that these key bindings use and in this mykeys module I created needed a number of modules imported to work the first thing you need to do when you create your own custom module let me zoom in here in the browser the very first line is the important one you need to type module space name of the module you created in my case custom dot mykeys and then where and then once you do that then import the stuff that is needed for the key bindings to work basically so I need especially a bunch of Xmonad actions you know things like kill for killing windows the key bindings to kill windows move to shift to next screen previous screen you know all the commands that your key bindings run on your tiling window manager you know you have to import all of that stuff and that's that's probably the most complicated module that I had to create there because there's some stuff in the key bindings but most of these are simple for example I did a my grid menu dot HS where I ripped out everything that had to do with grid select menus from my Xmonad dot HS and that only required me to do these top five lines here which included the module custom dot my grid menu where and then I only needed to import three things here Xmonad you have to always import Xmonad and it needed one Xmonad actions module the grid select of course because that's what we're doing in this particular document I also imported custom dot my variables because one of the new things I created was a my variables module here so this is where I stick all the variables for things like defining my font my mod key my alt key my web browser my terminal my text editor the border width you know the border around the windows so this really cleaned up my config now my config is really seven configs it's the Xmonad dot HS and plus these six new config files I created but it's a lot easier to read now because before all seven of these configs were just all in one file and they weren't necessarily all in the same place like you know you had key binding stuff maybe in multiple places in my Xmonad HS or you know tree menu stuff in multiple places in my Xmonad dot HS now I've split it all into their own separate modules and anybody that's coming behind me and trying to use my configs will be much better served here because they will actually be able to read and follow along exactly what's going on instead of having to read one single file that's more than a thousand lines long of Haskell so that's what I did with Xmonad now I also spent some time working on my emacs config because I said it was starting to get unwieldy it wasn't getting unwieldy because of the fact that it was getting too large it was really getting unwieldy for the fact that I couldn't really tell what was going on in the source code and I was trying to comment leave a bunch of comments all over that particular document and what I finally decided to do people had been telling me to do this for a while is to go ahead and convert my doom emacs config over to a org document and I don't know why I didn't do this before let me show you what my config looked like so before this is what my config looked like here in doom emacs it's just a standard elisp document there's no comments in it right now but before it was commented like every line basically every line told me exactly what this line of elisp does and that was all good and everything but then I discovered you know this org mode config so instead of config.el I created this new document config.org and it's great because now it's an actual org mode document where I can you know fold the tree here in org mode or unfold it by hitting tab and these are actually comments you see the uh this is a single asterisk so this is a header here and it's basically a markdown document org mode is kind of a form of markdown but the actual source code is in these block statements these source block statements you see where it says begin source emacs lisp and then end source everything inside that is actual elisp and that is code that will be evaluated anything that is not in a source code block is not code it will not be evaluated therefore it's essentially a comment I don't actually have to put anything in front of lines for them to be comments as long as they're not in a source code block they are comments and if you want to see what this looks like uh over on github or actually gitlab you guys know I'm on on gitlab let me go back to my dot files repository this is the home directory of my dot files repository go to my doom.d directory and now I have config.el the elisp version of the config but now I have config.org and if you click on it and this is what that document looks like gitlab is really nice because it renders org mode documents it actually renders them you know kind of like it renders mark down it renders org mode and it's very clean this is actual my actual config file right here that we're looking at and it's very easy to read because you know you have the headings you have the comments and then the source code is actually in source code blocks so that's the way it looks rendered if you wanted to see it of course not rendered in the actual source code you could always display it like this and gitlab but it's much cleaner to actually read it in the proper rendered format so I am really happy that I went to the trouble of doing that and that was so easy to do it is so easy to convert your config over to an org document really all you need to do is create your new config name it something.org you know config.org init.org whatever it is you want to name it you know and then convert it over with the source blocks here and then the only other thing I had to do other than create this document for me anyway here in do me max let me go and find my adnit.el in the adnit.el for do me max there is a line somewhere that says literate right here the very last thing in the config it says config literate this is commented out by default it's going to look something like that uncomment that uncomment that create your new org config and you should be good to go so that's just a little bit of what I spent many many hours this week working on the the x-monad splitting that up into multiple config files really took a lot of time but converting my emacs config over to a org document didn't take that long I probably spent a couple of hours doing that and it was kind of fun but the x-monad stuff was a was a little challenging but now that I got that worked out I'm really glad I may end up doing that with more config files other than just these because like you guys know I love the qtile window manager as well and I use qtile for many years my qtile config is starting to get a little bit long in length so at some point I may split that up into multiple files I may end up doing this with more than just x-monad as far as my window managers because so many of you guys are using these as documentation like you guys are going to my configs and almost treating them as like official documentation for these window managers especially so I want to clean them up you know because I want them to be a valuable educational tool for you guys now before I go I need to think a few special people I need to think michael gave heplo nate corbinian mitchell entropy UK arch 5530 chris chuck dj donnie dylan george louis omri paul shon to bias and willie these guys they are my highest tiered patrons over on patreon without these guys this episode about my rather bloated configs it wouldn't have been possible the show is also brought to you by each and every one of these ladies and gentlemen all these names you're seeing on the screen this is all my supporters over on patreon because this show is sponsored by you guys the community if you'd like to support my work you'll find distro tube over on patreon all right guys peace