I spend a lot of time writing and editing. I use a text editor for this. I’ve written before on why I think text editors are the best means for writing and editing one can have. But part of why a text editor can be so important is that they tend to be extensible or configurable (or both)—you can fit the editor to your needs. I use emacs, which is perhaps the most configurable and extensible text editor there is.
But the configurability and extensibility can also cause frustration. Many people don’t want to think about configuring emacs. For such folks I strongly recommend the configurations of purcell and batsov (prelude) and many others. I come originally from using vim. If you prefer vim’s modal editing style you should try spacemacs or doom-emacs as a way of managing your configuration. Whatever you choose you should look at some sensible defaults for configuring emacs.
I started using emacs via spacemacs about three years ago and fairly quickly migrated
to developing my own config. There tend to be three styles of config: a single
init.el file with all the elisp necessary to run emacs as you like it; a “literate”
config using org-mode to organize and then “tangle” the file using org-babel (you can
find another helpful discussion of this method here); or a “modular” file in which
the init.el file loads separate “libraries” of code.
For configurations of any reasonable level of complexity I think the single file approach is ill-conceived.
The literate config using org is great for two reasons. First, it is extremely simple to organize one’s config and comment significantly on every part. This is especially helpful when one is just starting out with elisp so that one can verbosely comment on how the various elisp code one uses works to achieve the desired results. Second, literate configs can be great learning sources for others. If you use a code repository like Github then you can display the org file natively. This makes browsing someone’s emacs config very easy (especially when they include a table of contents).
But a literate config can have its down sides. In addition to the issues discussed in that link, some of which may be resolvable, I found a few key problems. First, if you like to run the latest org-mode then you have to work around emacs’ built-in org version, which can be a pain in the neck.
Second, you need to load org mode when you generate, or want to edit, your config file. This can lead to slower load times in general, and if you have a large config, it can take several seconds before you can start editing (some people might not mind this but it tends to annoy me). I also think that, beyond the issue with start-up times, the fact that someone new to emacs would have to add a further layer of abstraction (i.e. org-mode and babel) to generate their init.file might be confusing.
Third, I find it a bit easier to keep modular files (e.g. separate files for keybindings, for configuring specific packages, or for a theme, etc.) under version control than to keep a single monolithic configuration file under vc.
Fourth, I often accidentally deleted or moved parts of my org config unintentionally, due to editing when at least some headlines were collapsed. There are ways to avoid this, but it leads to some unnecessary problems.
Fifth, and perhaps more subjectively than the above, I find it much easier to wrap my head around separate modules when it comes to thinking about what I want to tweak or change, or looking at a git log of what I have tweaked or changed.
Sixth, dealing with problems (debugging) is harder. Often you’ll need to use the tangled source for debugging and then go back and make changes in the org mode file. Also, the links from Help and Debugger will jump to the tangled source rather than the org file, which is what you actually need to edit. Also, if there are problems you might need to bisect your org file (essentially commenting out parts of it until you figure out what is wrong). I find it much easier to simply load or not load specific modules from the init file.
Seventh, it is also easier to edit files in lisp mode than edit an org mode containing lisp syntax.
Now, a modular config is perhaps not as immediately readable as a literate one,
but it is easy to comment as necessary on one’s code, and you can use packages
like the built-in outline library, with (outline-minor-mode) and (outline-cycle)
to allow for easy folding and cycling through levels of visibility just as with
org. I also use a few custom functions for navigating my setup files, which
makes things at least as easy to find as they were in my old literate config (in
some ways I find my current modular config even easier to search through). You
can see the setup of outline mode here and the search functions here.
EDITED: Friday, November 18 2022 to update description of outline and search functions.