ndwarshuis
/
emacs-config
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

REF add blurb about the CI pipeline I just added

This commit is contained in:
Nathan Dwarshuis 2021-03-14 16:12:45 -04:00
parent 01e4b78f52
commit 37a1baecaf
1 changed files with 5 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
etc/conf.org
View File

@ -5,6 +5,7 @@ This is my personal emacs config. It is quite massive. Please use the table of c
- [[#features-and-use-cases][features and use cases]]
- [[#for-new-users][for new users]]
- [[#config-structure][config structure]]
- [[#continuous-integration][continuous integration]]
- [[#library][library]]
- [[#system-dependencies][system dependencies]]
- [[#external][external]]
@ -77,6 +78,10 @@ The "root" is =init.el= which is the file explicitly loaded by emacs. Most users
Once loaded, the =init.el= pulls in another file called =conf.el= with the function =org-babel-load-file=. =conf.el= is actually sourced from an [[https://en.wikipedia.org/wiki/Org-mode][org]] file called =conf.org=.
Using an org file like this offers several advantages. First, org files are foldable in emacs which makes navigation easy. Second, they allow code snippets (the bit that actually go into =conf.el=) which allows for explanatory prose to be written around them, making documentation easy and clear. Third, =org-mode= has an automatic table of contents through the =toc-org= package, which makes naviagation even easier. Fourth, github itself is awesome enough to recognize org files as valid markdown and will render all the text, code snippets, headers, and table of contents in the nice html that you are reading now if on github. The result is a nearly self-documenting, self-organizing configuration that is easy to maintain and also easy to view for other users. Using the =init.el= itself would just have plain eLisp, which gets cluttered quickly. Some people break the =init.el= down into multiple files to keep everything sane, but I personally think it is easier to use one giant file that itself can be folded and abstracted to reduce the clutter.
** continuous integration
In the root of this directory is a =.github= folder with some simple tests to ensure this config is 'valid'. I'm experimenting with this and it may not turn out to be worth it, but the main reason these exist is that I would like to ensure I can transfer my emacs config to another system and have it work with no problems.
The danger with only having emacs on my daily driver is that I could silently introduce a dependency on some system library, and this may or may not be present when I unpack this config on a different machine. For now, the CI pipeline simply tests whether or not this config will initialize and build correctly on a "bare" system, and also tests if I can pull a list of dependencies using my somewhat hacky [[#system-dependencies][API]] so they can be installed via the package manager.
* library
This is code that is used generally throughout the emacs config
** system dependencies