Enable codespell pre-commit (#90)

This catches some common spelling errors, but is *not* an exhaustive spell-checker. The only false positive is "rouge" in Gemfile.lock, which is why I'm excluding that file.

True positives are in the change, and it does catch the "langauge" typo I keep making, which zygoloid fixed for me in a few spots. False negatives are:

- virmc
- Announcemented
- propsal

For comparison:

- cspell (https://www.npmjs.com/package/cspell) is too aggressive and has a small dictionary
  - Caught the false negatives, but many false positives, including 'LLVM', 'roadmap', 'Carruth'
- https://github.com/lorenzwalthert/precommit has a spellcheck, but config looks ruby-specific

.pre-commit-config.yaml

@@ -15,6 +15,11 @@ repos:
       - id: mixed-line-ending
         args: ['--fix=lf']
       - id: trailing-whitespace
+  - repo: https://github.com/codespell-project/codespell
+    rev: v1.17.1
+    hooks:
+      - id: codespell
+        exclude: '^src/jekyll/Gemfile.lock$'
   - repo: local
     hooks:
       - id: markdown-toc

docs/project/contribution_tools.md

@@ -14,6 +14,7 @@ contributions.
 <!-- toc -->
 
 - [pre-commit](#pre-commit)
+- [codespell](#codespell)
 - [markdown-toc](#markdown-toc)
 - [Prettier](#prettier)
   - [vim-prettier](#vim-prettier)
@@ -41,6 +42,15 @@ To set up pre-commit:
 When modifying or adding pre-commit hooks, please run
 `pre-commit run --all-files` to see what changes.
 
+## codespell
+
+> **pre-commit enabled**: If you're using pre-commit, it will run this.
+> Installing and running manually is optional, but may be helpful.
+
+We use [codespell](https://github.com/codespell-project/codespell) to spellcheck
+common errors. This won't catch every error; we're trying to balance true and
+false positives.
+
 ## markdown-toc
 
 > **pre-commit enabled**: If you're using pre-commit, it will run this.
@@ -63,7 +73,7 @@ We use [Prettier](https://prettier.io/) for formatting. There is an
 ### vim-prettier
 
 If you use [vim-prettier](https://github.com/prettier/vim-prettier), it may help
-to add to your `.virmc`:
+to add to your `.vimrc`:
 
 ```
 let g:prettier#config#print_width = '80'

docs/project/evolution.md

@@ -68,7 +68,7 @@ The process is:
 We use several tools to coordinate changes to Carbon:
 
 - **GitHub pull requests** contain the proposals and related discussion.
-  Resolved proposals wil be committed with the associated decision. The pull
+  Resolved proposals will be committed with the associated decision. The pull
   request's description should link all related Discourse Forum topics and other
   references for easy browsing.
 - **Discourse Forum** topics will be used for the early idea discussion, any
@@ -271,7 +271,7 @@ Where the proposal makes a decision between multiple options, move them to the
 You may optionally use the
 [Google Docs template](https://docs.google.com/document/d/1sqEnIWWZKTrtMz2XgD7_RqvogwbI0tBQjAZIvOabQsw/template/preview)
 for early proposal versions, which can be transferred to Markdown later. Using
-Google Docs can especially help iterate on a propsal with multiple authors.
+Google Docs can especially help iterate on a proposal with multiple authors.
 
 This template includes things like license headers and standard formatting. If
 you already have a non-templated Doc, please create a new Doc using the template

docs/project/principles/README.md

@@ -10,13 +10,13 @@ Some language [goals](../goals.md) will have widely-applicable, high-impact, and
 sometimes non-obvious corollaries. We collect concrete language design
 principles in this directory as a way to document and clarify these. Principles
 clarify, but do not supersede, goals and priorities. Principles should be used
-as a tool in making decisions, and to clarify to contributors how descisions are
+as a tool in making decisions, and to clarify to contributors how decisions are
 expected to be made.
 
 A key difference between a principle and the design of a language feature is
 that a principle should inform multiple designs, whereas a feature's design is
 typically more focused on achieving a specific goal or set of goals. The
-principle can help acheive consistency across those multiple designs.
+principle can help achieve consistency across those multiple designs.
 
 Note that these principles seek to establish both the approaches the project
 wants to pursue, as well as those we want to exclude.

docs/project/review_managers.md

@@ -87,7 +87,7 @@ declined/deferred proposals should have the same template used as a comment on
 the proposal, with no separate pull request.
 
 Announce the decision on a new topic in
-[Evolution > Announcemented](https://forums.carbon-lang.dev/c/evolution/announcements/8),
+[Evolution > Announcements](https://forums.carbon-lang.dev/c/evolution/announcements/8),
 titled "[DECISION] PROPOSAL":
 
 ```markdown

proposals/p0044-decision.md

@@ -85,7 +85,7 @@ etc. In general, the PR-centric model was favored.
 ### Rationale for not requiring tracking issues
 
 There were several members who had no strong preference on this issue. The
-concensus was that until there is a compelling reason to require tracking
+consensus was that until there is a compelling reason to require tracking
 issues, the process is more light-weight without them.
 
 ### Rationale for not committing proposals that are declined or deferred