docs: prose edits

config.org

@@ -67,12 +67,12 @@ The second block above was automatically generated by =org-mode=.
 
 **** Tangle, Weave, Export, Publish
 
-Since Org's ability to execute code and process its output is so robust, it's only natural that one might consider using Org to annotate a codebase, storing the code inside source blocks in the document. This would provide the space for much more thorough commentary than regular comments, but also prevent the file from being interpreted as a program, which is the important part! You could maintain both the Org file and the actual source files separately, but that would require manually duplicating edits in both files, which is not ideal.
+Since Org's ability to execute code and process its output is so robust, it's only natural that one might consider using Org to annotate a codebase, storing the code inside source blocks in the document. This would provide the space for much more thorough commentary than regular comments; however, it would prevent the file from being readable as a program, which is the entire point! You could maintain both the Org file and the actual source files separately, but that would require manually duplicating edits in both files, which is not ideal.
 
-The solution is [[https://en.wikipedia.org/wiki/Literate_programming][literate programming]], the practice of embedding usable code into a markup document. Literate programming can be handled in a few different ways. A handful of languages support directly processing these markup documents, such as Haskell and Julia; however, the way Org implements it is closer to the traditional method, which involves two parallel processes:
+The solution is [[https://en.wikipedia.org/wiki/Literate_programming][literate programming]], the practice of embedding usable code into a markup document. Literate programming can be handled in a few different ways. A handful of languages support directly processing these markup documents, such as Haskell and Julia; however, the way Org implements it is closer to the traditional method, in which a singular file is processed in two different ways:
 
-1. /Tangling/, converting the file into raw source code. Tangling must be performed before the code is used; in Org, code is tangled into a new file, and this can be done to generate many source files from a single Org file.
-2. /Weaving/, formatting the file into a human-readable document. Org conceptually divides this further into "exporting" and "publishing," where the latter is intended specifically for converting into web-ready HTML.
+1. /Tangling/, converting into raw source code. Tangling must be performed before the code is used; in Org, code is tangled into a new file, and this can be done to generate many source files from a single Org file.
+2. /Weaving/, formatting into a human-readable document. Org conceptually divides this further into "exporting" and "publishing," where the latter is intended specifically for converting into web-ready HTML.
 
 You are currently reading the published version of this literate program[fn:1]. If you were to download this repository and use it as your config, Emacs would be running the tangled version. These versions are generated in separate processes, but both are ultimately derived from the content and metadata inside of the Org file.
 
@@ -82,9 +82,9 @@ You are currently reading the published version of this literate program[fn:1].
 
 The simultaneous handling of documentation and code inherent to literate programming is reminiscent of documentation generation (doc comments) in traditional programming. Both systems involve superimposing code and documentation into one file, but the literate style takes the concept one step further; the document isn't embedded in the code, the code is embedded in the document.
 
-Instead of documentation having to be bent around the restrictions of source code, the source code can be written and organized with all the freedoms of prose. If written well, the literate program can be structured in a manner closer to how the human mind understands code, rather than how a computer processes it. This is assisted by features such as literate macros, features intended to break one's code out of the restrictions of standard programming.
+Instead of documentation having to be bent around the restrictions of source code, the source code can be written and organized with all the freedoms of prose. If written well, the literate program can be structured in a manner closer to how the human mind understands code, rather than how a computer processes it. This is assisted by features such as macros, which provide further flexibility in structure.
 
-It's not the right tool for every codebase, but proper use of literate programming can make a program much, much easier to comprehend and maintain. This is especially true for configuration languages like Emacs Lisp, where much of the code is conceptually disconnected and can easily be split into categories.
+It's not the right tool for every codebase, but proper use of literate programming can make a program much, much easier to comprehend and maintain. This is especially true for configuration languages like Emacs Lisp, where much of the code is conceptually disconnected and can easily be split apart.
 
 ** Current Issues
 
@@ -2099,19 +2099,19 @@ Having an IDE-style tooltip pop up is nice, but ~flymake-popon~ is a bit ugly by
 
 #+call: confpkg("Pkg: git")
 
-I use GPG signing for commits, which means that committing often takes longer than the single second timeout. Eight seconds seems like a reasonable amount of time to type in a password.
+I use GPG signing for commits, which means that creating a commit typically takes longer than Emacs's timeout (1 second by default). Having a timeout doesn't really seem all that necessary in the first place, so I'll just set it to a high number.
 
-Let's also increase the maximum length of commit summaries past the default of 50 characters, because that's a somewhat restrictive limit.
+Let's also increase the maximum length of commit summaries from 50 to 60 characters to give ourselves a bit more space.
 
 #+begin_src emacs-lisp
 (after! git-commit
-  (setq git-commit-post-finish-hook-timeout 8
+  (setq git-commit-post-finish-hook-timeout 999
         git-commit-summary-max-length 60))
 #+end_src
 
 *** Forge
 
-Forge is a convenient package for working with remote code forges like GitHub, GitLab, etc. These days, I've mostly switched over to my own [[https://git.tokinanpa.dev/][personal forge]] instead of something public like GitHub, so I'll need to let Forge know about that.
+Forge is a convenient package for working with remote code forges like GitHub, GitLab, etc. These days, I've mostly switched over to my own [[https://git.tokinanpa.dev/][personal forge]] instead of those more public options, so I'll need to let Forge know about that.
 
 #+begin_src emacs-lisp
 (after! forge
@@ -2905,7 +2905,7 @@ It's sometimes nice to be able to click a link in an Org file that takes me to o
 
 *** Modern
 
-Doom Emacs's =+pretty= flag by default uses the package =org-superstar= to prettify Org files. This package is decently nice looking, but it has a much nicer and more comprehensive alternative in the form of =org-modern=.
+Doom Emacs's =org +pretty= flag by default uses the package =org-superstar= to prettify Org files. This package is decently nice looking, but it has a much nicer and more comprehensive alternative in the form of =org-modern=.
 
 #+begin_src emacs-lisp :tangle packages.el
 (package! org-modern)
@@ -3026,7 +3026,7 @@ The default colors for various elements of =org-modern= don't match with our the
 
 *** Appear
 
-Since we've disabled =+pretty=, we need to add the packages we do want from it, namely =org-appear= to automatically handle emphasis markers and other nice things like that.
+Since we've disabled =+pretty=, we need to add the packages we do want from it, namely =org-appear= to automatically prettify emphasis markers and other nice things like that.
 
 #+begin_src emacs-lisp :tangle packages.el
 (package! org-appear)