How Can I Start the Daunting Task of Making my Own Config?

I've been using Doom for a few months and it really helped me fall in love with Emacs but it breaks constantly, unfortunately. I am a programmer and that's what I use Emacs for. React Web development, Python, and C++. Any tips on getting started on my own config? It seems about impossible to get something as complex as Doom anytime soon

I don't know what the best way is, but I just started with some basics and fixed anything I didn't like and added things I needed, often borrowing from other people's published configs. I found that understanding and using use-package from the start was helpful. I'm not sure I would recommend this approach, the process took years before I had things working mostly the way I wanted, although I had something that I could use at work within a couple weeks. Another way which might work is to take a well documented config from someone else, and modifying it as you find issues with it. This would be less time consuming I think, depending on what you start with. Putting everything under source control and committing often is essential no matter how you go about it.

I thought about taking doom and I thought I'd fix things that break but that seems very confusing right now. Especially because I don't control the doom updates I am just looking for maybe a guide that gives me some steps and teaches some things.

I would recommend you to check out the Emacs videos from System Crafter. “Emacs from scratch” goes through building a custom config. One of the videos covers using LSP to make Emacs into more of an IDE. https://youtube.com/playlist?list=PLEoMzSkcN8oPH1au7H6B7bBJ4ZO7BXjSZ

This is awesome and exactly what I do need.

Start with a blank config file, use emacs and change things that bother you or that you miss from doom. Rince, repeat. After some time you might be satisfied with what you have or totally trash your config and start over.

Taking the time to really explore what vanilla emacs is capable of for your needs is probably the most important step to ensure you know exactly what you're changing and why it doesn't work for you. This is especially relevant if the concern is breakage/incompatibilities; reducing the reliance on external packages helps, and a better understanding of what those packages are changing and why also helps. Beyond that having a clear idea of what you want your usage of emacs to look like on a day-to-day, and sticking to it can prevent getting lost in the weeds on hypotheticals, potentials, and the kitchen sink in the config. Aggressively use the inbuilt documentation and save yourself a lot of Google searches, and learning even the basics of elisp goes a very long way. It is nice being able to think of an editing function you may want, hop over to the scratch file, write one up, and have it in your workflow in 30 minutes without ever leaving emacs.

Something that helped me over the long run was to segment my config into a few different files: I have init.el, which is where the basics all happen (set up basic keys the way I like them, set my theme, and loop through a versioned packages list to make sure they're all installed on this particular machine, invoke the server). I keep a separate config file for org, helm, and "misc". If I run into a problem, it makes it possible to do a sort of bisection from within init.el by just commenting out the lines where I load my package-specific and tweaks file. If that clears up the issue, I let them back in one by one until one of them makes something break. Then I can bisect inside that file until I find the issue. YMMV, but it helps me feel a little more organized if I have to troubleshoot.

https://www.youtube.com/playlist?list=PLVtKhBrRV_ZkPnBtt_TD1Cs9PJlU0IIdE (OrgMode tutorial: Rainer König)

Hardest thing of any problem is to.. just get started. So just make an empty .emacs and start adding .. "oh yeah, I need \_\_\_" so add "\_\_\_" to it. You'll get 80% of the way there in a couple hours, and tweak for the next 10 years.

Just start, it'll take a lot of reading and testing. I'm two months in (without any programming experience) and I've gone through various re-writes (from a literate .org init to a modular setup akin to Emacs Prelude or Siren configurations. (See: [https://github.com/jimeh/.emacs.d](https://github.com/jimeh/.emacs.d)) Starting out, System Crafter's guide is really helpful if everything's confusing at start. Eventually, I moved away from his literate config to a modular setup. For packages, Checking what people in the community commonly use, such as in [https://github.com/emacs-tw/awesome-emacs/](https://github.com/emacs-tw/awesome-emacs/) or checking packages for review in Doom Emacs helps a lot in selection. There are also great guides, such as Kristoffer Balintona's [https://kristofferbalintona.me/categories/guides/](https://kristofferbalintona.me/categories/guides/). Personally, my bias in selecting packagges is towards the ones that integrate well with built-in Emacs functionalities. I could provide you a list if you want. Also, Emacs' built in documentation is a godsend. Saves a lot of googling (unless the package has its own usage guide in its repository)

How do you eat an elephant? One bite at a time. In my case, my config started long ago in the vanilla Emacs days with some elisp code to fix things that annoyed me. Pretty soon I started setting a bunch of config variables in it, rebinding keys with dwim versions that work more to my liking, borrowing ideas from other peoples configs, and vendoring files not included, adding utility functions, and writing some custom modes. If I run into something that annoys me about my current config during a project, I'll make note of it and then try to address it during my next downtime between projects. I see my Emacs config as being like a pebble in a river, with all the sharp edges worn smooth bit by bit over the passage of time.

I based my config on some popular third party config (Steve Purcell's emacs.d). You could use my config (https://github.com/redguardtoo/emacs.d/) or whatever 3rd party config as the base to build your own config.

Just curious: how you make Doom break constantly? I've been using it for some years (in several computers) and it doesn't really break for me. Just to learn, I've also built a personal config from scratch. It is fairly functional, although I still use Doom for real stuff. I used 'use-package' extensively. It is a very good way of structuring one's config, IMO. I'd recommend it.

Yes, I have essentially the same question: what does "Doom breaks constantly" mean? What is the manifestation of breakage?

Every time I uncomment a module in init.el I have to basically reinstall doom. Just throws errors here and there and I'm not yet equipped to take care of it on my own.

I have a fairly minimal set up. Using eglot and company for code completion. It some times bugs out but closing and opening it seems to do the trick.

I see. It's true that sometimes the upgrade is a bit confusing, but I found that doing "doom sync" until nothing is updated (sometimes running it once doesn't work) gets the job done. When nothing seems to work (or more commonly, when a lot of time has passed since updating doom) I just start from scratch. I backup my .emacs.d and .doom.d, I download doom from git, do a "doom install" and when it finishes (and I tested it works) I overwrite .doom.d with my old .doom.d and do a "doom sync" (or two). This always gets the job done for me. I can't overstate the importance of backing up .emacs.d before doing anything. This ensures you can always go back to a version which works. I keep the last couple of tgz os .emacs.d around to have this reassurance I won't have a problem with a deadline because "my editor doesn't work anymore". In fact, I used to compile emacs locally and keep a couple of versions of compiled emacsen around so change of versions don't break my old configurations. One of the advantages of doom is that the versions of the packages are fixed, so there is less likelihood of real breakage than with personal configurations than just download whatever is the most recent version of each package. In my (modest) experience, that is a much worse situation because there it's easier that something breaks every time. Not the whole thing, but some functionality breaks because of mismatch between versions. That's tougher to solve. The creator of doom spends quite a oot of time solving these issues, so I don't have to. I find it convenient ¯\_(ツ)_/¯

I know. I've talked to Henrik a few times on discord Currently I'm just trying to get python to work on my doom and it just doesn't for whatever reason I want to learn emacs anyway, maybe this is the universe telling me to just get the fuck with it already.

(edit: now with the correct link) Hmmm, that's strange. Python works basically out of the box in doom. I started doing some Python a couple of weeks ago and I posted a few days back on how I got it to work: [https://www.reddit.com/r/DoomEmacs/comments/ydvsks/comment/itvux0g/?utm\_source=share&utm\_medium=web2x&context=3](https://www.reddit.com/r/DoomEmacs/comments/ydvsks/comment/itvux0g/?utm_source=share&utm_medium=web2x&context=3) BTW: I got an issue on a couple of machines with these steps. In Linux, I had to do the "pip install 'python-lsp-server\[all\]'" as root for the server to be visible. I'm sure there is a way to avoid that, but well, it worked. Good luck!

Does it have to be a python project? I've been trying to open individual files.

Once you open it, Emacs will ask you what to do with the file (set a project dir for it or ignore, etc.). Try it. It just works out of the box.