docs: add heading anchors

Author: Lunarnovaa

docs/manual/CONTRIBUTING.md

@@ -1,4 +1,4 @@
-# Contributing
+# Contributing {#contributing}
 
 [commitizen]: https://github.com/commitizen-tools/commitizen
 [article from GeeksforGeeks]: https://www.geeksforgeeks.org/how-to-create-a-new-branch-in-git/
@@ -21,7 +21,7 @@ If you are familiar with contributing to open source software, you can safely
 skip ahead to [Core Principles]. Otherwise, read the following section to learn
 how to fork a repo and open a PR.
 
-## Getting Started
+## Getting Started {#ch-getting-started}
 
 To begin contributing to HJR, you will first need to create a fork off of the
 main branch in order to make changes. For info on how to do this, we recommend
@@ -33,7 +33,7 @@ from your fork. To do so, you can read this [article from GeeksforGeeks] that
 will also explain branches for you. Don't worry too much about the technical
 details, the most important thing is to make and switch to a branch from HEAD.
 
-### Commit format
+### Commit Format {#sec-commit-format}
 
 > [!TIP]
 > Our dev shell allows for interactive commits, through the means of
@@ -77,7 +77,7 @@ After you have setup a PR, it will be [reviewed] by maintainers and changes may
 be requested. Make the changes requested and eventually it will likely be
 accepted and merged into main.
 
-## Core Principles
+## Core Principles {#ch-core-principles}
 
 In creating HJR, we had a few principles in mind for development:
 
@@ -88,13 +88,13 @@ In creating HJR, we had a few principles in mind for development:
 Please keep these in mind as you read through our general guidelines for
 contributing.
 
-## Guidelines
+## Guidelines {#ch-guidelines}
 
 These guidelines, are, of course, merely guidelines. There are and will continue
 to be exceptions. However, do your best to stick to them, and keep in mind that
 reviewers will hold you to them as much as possible.
 
-### Aliases
+### Aliases {#sec-aliases}
 
 At the top of any module, there should always be a `let ... in` set. Within
 this, functions should have their location aliased, cfg should be aliased, and
@@ -132,7 +132,7 @@ and `type`, so the alias name is just `toml`.
 Always be sure to include `cfg` that links to the point where options are
 configured by the user.
 
-### Writing Options
+### Writing Options {#sec-writing-options}
 
 Writing new options is the core of any new module. It is also the easiest place
 to blunder. As stated above, a core principle of HJR is to minimize the number
@@ -254,7 +254,7 @@ default. This can also be used in `mkOption`, but it is more common to use it in
 If you do not set this, the docs builder will break due to not knowing how to
 resolve the reference to `config`.
 
-### Conditionals in Modules
+### Conditionals in Modules {#sec-conditionals-in-modules}
 
 Always use a `mkIf` before the `config` section. Example:
 
@@ -366,7 +366,7 @@ First, the file is only written if any of the options to write to the file are
 set. `optionalString` is then used to compile each option's results in an
 optimized and clean way.
 
-### Extending RumLib
+### Extending RumLib {#sec-extending-rumlib}
 
 Rather than having functions scattered throughout the module collection, we
 would rather keep our directories organized and purposeful. Therefore, all
@@ -394,7 +394,7 @@ Additionally, please follow how lib is structured in Nixpkgs. For example, the
 custom function `attrsNamesHasPrefix` is under `attrsets` to signify that it
 operates on an attribute set, just like in Nixpkgs.
 
-### Docs
+### Docs {#sec-docs}
 
 If you would like to contribute to our documentation, we ask a few things of
 you:
@@ -430,12 +430,12 @@ Make sure to use {file}`lib.options.mkEnableOption`, like is done in
 If you do not do it like this, the link check on the docs will fail, since our
 docs generator will attempt to make hyperlinks out of those function names.
 
-### Tests
+### Tests {#sec-tests}
 
 Please refer to the [testing documentation] for more information on how tests
 work.
 
-## Reviewing a PR
+## Reviewing a PR {#ch-reviewing-a-pr}
 
 Even if you do not have write-access, you can always leave a review on someone
 else's PR. Again, GitHub has great [documentation on reviewing PRs]. This is

docs/manual/INSTALLATION.md

@@ -1,9 +1,9 @@
-# Installing Hjem Rum
+# Installing Hjem Rum {#installing-hjem-rum}
 
 Welcome to Hjem Rum. Installing and configuring Hjem Rum is as easy as any other
 module.
 
-## Importing the Hjem Rum Flake
+## Importing the Hjem Rum Flake {#ch-importing-the-hjem-rum-flake}
 
 To begin using Hjem Rum, simply add and import Hjem and Hjem Rum into your
 flake:
@@ -44,7 +44,7 @@ outputs = {
 }
 ```
 
-## Important Hjem Settings
+## Important Hjem Settings {#ch-important-hjem-settings}
 
 Be sure to first set the necessary settings for Hjem and import Hjem Rum's Hjem
 module from the input:
@@ -67,7 +67,7 @@ hjem = {
 };
 ```
 
-## Configuring Hjem Rum Modules
+## Configuring Hjem Rum Modules {#ch-configuring-the-hjem-rum-modules}
 
 You can then configure any of the options defined in this flake in any nix
 module:

docs/manual/QUIRKS.md

@@ -1,4 +1,4 @@
-# Quirks, Tips, & Tricks
+# Quirks, Tips, & Tricks {#quirks-tips-tricks}
 
 [#17]: https://github.com/snugnug/hjem-rum/issues/17
 
@@ -10,7 +10,7 @@ serving only as a module collection on top of Hjem.
 To help alleviate this, here are some of those quirks that you may find, as well
 as some tips to help you on your journey with Hjem Rum.
 
-## Environmental Variables
+## Environmental Variables {#ch-environmental-variables}
 
 Hjem provides the option {option}`environment.sessionVariables` allowing the
 user to set environmental variables to be sourced. However, Hjem does not have

docs/manual/REVIEWING.md

@@ -1,4 +1,4 @@
-# Review tips
+# Review Tips {#review-tips}
 
 [Code Review Antipatterns]: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/code-review-antipatterns/
 [nixpkgs]: https://github.com/NixOS/nixpkgs
@@ -18,7 +18,7 @@ tips serve as a reference, not a rule of law.
 <sub>Much of this guide is inspired by [Code Review Antipatterns] by Simon
 Tatham. If you're interested, give it a look! </sub>
 
-## 1. Be nice
+## 1. Be nice {#ch-1-be-nice}
 
 Starting off with an easy one! However, there's actually something meaningful to
 be said here. As a reviewer, it's easy to get frustrated with constantly giving
@@ -34,7 +34,7 @@ This might sound silly at first. But when it feels like a reviewer is _on your
 side_, it makes a huge difference. If this tone feels a little foreign, pretend
 you're writing an email, and that should give you a good barometer.
 
-## 2. Single-trip reviews
+## 2. Single-trip reviews {#ch-2-single-trip-reviews}
 
 As a contributor, it can be frustrating to finish accommodating all the review
 comments, only to immediately be given a bunch of other suggestions, which
@@ -59,7 +59,7 @@ something will require a lot of changes to be mergeable, be up-front about
 it―even if you feel a little guilty. Better to rip the bandaid off now, than to
 leave it on for a few review sessions.
 
-## 3. United front
+## 3. United front {#ch-3-united-front}
 
 Anyone who's contributed to [nixpkgs] knows the cycle―you've accommodated one
 reviewer's comments, only for a different reviewer to come in with MORE things
@@ -70,7 +70,7 @@ When possible, try to coordinate review feedback. The [SNUG Discord server] is a
 great place for working together to ensure feedback is clear and consistent
 between reviewers.
 
-## 4. Bikeshedding
+## 4. Bikeshedding {#ch-4-bikeshedding}
 
 Have you ever made a PR, only for every single line to be criticized for not
 being done exactly how the reviewer wants? It feels like your code is being held

docs/manual/TESTING.md

@@ -1,4 +1,4 @@
-# Testing setup for modules
+# Testing setup for modules {#testing-setup-for-module}
 
 [nushell test module]: https://github.com/snugnug/hjem-rum/blob/main/modules/tests/programs/nushell.nix
 [nix.dev provides a useful guide]: https://nix.dev/tutorials/nixos/integration-testing-using-virtual-machines.html
@@ -11,7 +11,7 @@ from other testing frameworks and stick with `runTest`, from the
 abstractions in regards to writing the tests, so they should be written just
 like any other test that uses the NixOS Test Driver.
 
-## Creating Tests
+## Creating Tests {#ch-creating-tests}
 
 Every file is automatically imported with
 {file}`lib.filesystem.listFilesRecursive`, given that there is a check output
@@ -29,7 +29,7 @@ checks = hjem-rum-services = import ./modules/tests (mkCheckArgs ./modules/tests
   # Just // (import ./modules/tests and pass mkCheckArgs with your brand-new directory to it.
 ```
 
-### Naming
+### Naming {#sec-naming}
 
 To reduce CI run time, we only run checks for which the module or test file has
 changed. For this association to work, the following naming scheme has to be
@@ -47,7 +47,7 @@ start with the aformentioned pattern, such as `programs-foot-test-plugins`.
 > [!IMPORTANT]
 > If you do not follow this rule, your tests will not be run during CI.
 
-## Writing Tests
+## Writing Tests {#ch-writing-tests}
 
 Tests for Hjem Rum are written just like any other test, so it might be worth to
 take a read at how NixOS tests work. [nix.dev provides a useful guide], as does

docs/package.nix

@@ -116,7 +116,6 @@
         --manpage-urls ${./manpage-urls.json} \
         --options-depth 3 \
         --generate-search true \
-        --template-dir ${./templates} \
         --input-dir ${./manual} \
         --output-dir "$out"