Merge pull request #2113 from EricFromCanada/master

Fix spelling, grammar, URLs in docs

docs/Acceptable-Formulae.md

@@ -38,7 +38,7 @@ There are exceptions:
 | emacs, vim         | [Too popular to move to dupes](https://github.com/Homebrew/homebrew/pull/21594#issuecomment-21968819) |
 | subversion         | Originally added for 10.5, but people want the latest version                                         |
 | libcurl            | Some formulae require a newer version than macOS provides                                             |
-| openssl            | macOS's openssl is deprecated & outdated.                                                             |
+| openssl            | macOS's openssl is deprecated & outdated                                                              |
 | libxml2            | Historically, macOS's libxml2 has been buggy                                                          |
 
 We also maintain [a tap](https://github.com/Homebrew/homebrew-dupes) that
@@ -74,7 +74,7 @@ due to upstream changes and we can’t provide [bottles](Bottles.md) for them.
 ### Bindings
 First check that there is not already a binding available via
 [`gem`](https://rubygems.org/) or [`pip`](http://www.pip-installer.org/)
-etc..
+etc.
 
 If not, then put bindings in the formula they bind to. This is more
 useful to people. Just install the stuff! Having to faff around with

docs/Brew-Test-Bot-For-Core-Contributors.md

@@ -4,13 +4,13 @@ If a build has run and passed on `brew test-bot` then it can be used to quickly
 
 There are two types of Jenkins jobs you will interact with:
 
-## [Homebrew Pull Requests](https://bot.brew.sh/job/Homebrew%20Core%20Pull%20Requests/)
+## [Homebrew Core Pull Requests](https://bot.brew.sh/job/Homebrew%20Core/)
 This job automatically builds any pull requests submitted to Homebrew/homebrew-core. On success or failure it updates the pull request status (see more details on the [main Brew Test Bot documentation page](Brew-Test-Bot.md)). On a successful build it automatically uploads bottles.
 
 ## [Homebrew Testing](https://bot.brew.sh/job/Homebrew%20Testing/)
-This job is manually triggered to run [`brew test-bot`](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/dev-cmd/test-bot.rb) with user-specified parameters. On a successful build it automatically uploads bottles.
+This job is manually triggered to run [`brew test-bot`](https://github.com/Homebrew/homebrew-test-bot/blob/master/cmd/brew-test-bot.rb) with user-specified parameters. On a successful build it automatically uploads bottles.
 
-You can manually start this job with parameters to run [`brew test-bot`](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/dev-cmd/test-bot.rb) with the same parameters. It's often useful to pass a pull request URL, a commit URL, a commit SHA-1 and/or formula names to have `brew-test-bot` test them, report the results and produce bottles.
+You can manually start this job with parameters to run [`brew test-bot`](https://github.com/Homebrew/homebrew-test-bot/blob/master/cmd/brew-test-bot.rb) with the same parameters. It's often useful to pass a pull request URL, a commit URL, a commit SHA-1 and/or formula names to have `brew-test-bot` test them, report the results and produce bottles.
 
 ## Bottling
 To pull and bottle a pull request with `brew pull`:

docs/Brew-Test-Bot.md

@@ -3,9 +3,9 @@
 `brew test-bot` is the name for the automated review and testing system funded
 by [our Kickstarter in 2013](https://www.kickstarter.com/projects/homebrew/brew-test-bot).
 
-It comprises of four Mac Minis running in a data centre in England which host
+It comprises four Mac Minis running in a data centre in England which host
 [a Jenkins instance at https://bot.brew.sh](https://bot.brew.sh) and run the
-[`brew test-bot.rb`](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/dev-cmd/test-bot.rb)
+[`brew test-bot.rb`](https://github.com/Homebrew/homebrew-test-bot/blob/master/cmd/brew-test-bot.rb)
 Ruby script to perform automated testing of commits to the master branch, pull
 requests and custom builds requested by maintainers.
 
@@ -15,7 +15,7 @@ The bot automatically builds pull requests and updates their status depending
 on the result of the job.
 
 For example, a job which has been queued but not yet started will have a
-section in the pull-request that looks like this:
+section in the pull request that looks like this:
 
 
 ![Triggered Pull Request](images/brew-test-bot-triggered-pr.png)

docs/Common-Issues.md

@@ -7,8 +7,7 @@ You need to have the Xcode Command Line Utilities installed (and updated): run `
 (In OS X prior to 10.9, the "Command Line Tools" package can alternatively be installed from within Xcode. `⌘,` will get you to preferences. Visit the "Downloads" tab and hit the install button next to "Command Line Tools".)
 
 ### Ruby `bad interpreter: /usr/bin/ruby^M: no such file or directory`
-You cloned with git, and your git configuration is set to use Windows line endings. See this page: https://help.github.com/articles/dealing-with-line-endings
-
+You cloned with git, and your git configuration is set to use Windows line endings. See this page: <https://help.github.com/articles/dealing-with-line-endings>
 
 ### Ruby `bad interpreter: /usr/bin/ruby`
 You don't have a `/usr/bin/ruby` or it is not executable. It's not recommended to let this persist, you'd be surprised how many .apps, tools and scripts expect your macOS provided files and directories to be *unmodified* since macOS was installed.

docs/External-Commands.md

@@ -47,15 +47,15 @@ brew tap youtux/livecheck
 ```
 
 ### brew-gem
-Install any gem package into a self-contained Homebrew cellar location: [https://github.com/sportngin/brew-gem](https://github.com/sportngin/brew-gem).
+Install any gem package into a self-contained Homebrew cellar location: <https://github.com/sportngin/brew-gem>
 
 Note this can also be installed with `brew install brew-gem`.
 
 ### brew-growl
-Get Growl notifications for Homebrew https://github.com/secondplanet/brew-growl
+Get Growl notifications for Homebrew: <https://github.com/secondplanet/homebrew-growl>
 
 ### brew-services
-Simple support to start formulae using launchctl, has out of the box support for any formula which defines `startup_plist` (e.g. mysql, postgres, redis u.v.m.): [https://github.com/Homebrew/homebrew-services](https://github.com/Homebrew/homebrew-services)
+Simple support to start formulae using launchctl, has out of the box support for any formula which defines `startup_plist` (e.g. mysql, postgres, redis u.v.m.): <https://github.com/Homebrew/homebrew-services>
 
 Install using:
 ```sh

docs/FAQ.md

@@ -81,13 +81,12 @@ including how to set this across reboots. If you’re pre-Mountain Lion,
 alternative](https://developer.apple.com/legacy/library/qa/qa1067/_index.html).
 
 ## How do I contribute to Homebrew?
-Read [CONTRIBUTING.md](/CONTRIBUTING.md).
+Read [CONTRIBUTING.md](https://github.com/Homebrew/brew/blob/master/CONTRIBUTING.md).
 
 ## Why do you compile everything?
 Homebrew provides pre-compiled versions for many formulae. These
 pre-compiled versions are referred to as **bottles** and are available
-at:
-[https://bintray.com/homebrew/bottles](https://bintray.com/homebrew/bottles).
+at <https://bintray.com/homebrew/bottles>.
 
 If available, bottled binaries will be used by default except under the
 following conditions:

docs/Formula-Cookbook.md

@@ -288,13 +288,13 @@ Name the formula like the project markets the product. So it’s `pkg-config`, n
 
 The only exception is stuff like “Apache Ant”. Apache sticks “Apache” in front of everything, but we use the formula name `ant`. We only include the prefix in cases like *GNUplot* (because it’s part of the name) and *GNU Go* (because everyone calls it “GNU go”—nobody just calls it “Go”). The word “Go” is too common and there are too many implementations of it.
 
-If you’re not sure about the name check the homepage, and check the Wikipedia page and [what Debian call it](https://www.debian.org/distrib/packages).
+If you’re not sure about the name check the homepage, and check the Wikipedia page and [what Debian calls it](https://www.debian.org/distrib/packages).
 
-Where Homebrew already has a formula called `foo` we typically do not accept requests to replace that formula with something else also named `foo`. This is to avoid both confusing and surprising users’ expectation.
+Where Homebrew already has a formula called `foo` we typically do not accept requests to replace that formula with something else also named `foo`. This is to avoid both confusing and surprising users’ expectations.
 
 When two formulae share an upstream name, e.g. [`AESCrypt`](https://github.com/Homebrew/homebrew-core/blob/master/Formula/aescrypt.rb) and [`AESCrypt`](https://github.com/Homebrew/homebrew-core/blob/master/Formula/aescrypt-packetizer.rb) the newer formula must typically adapt the name to avoid conflict with the current formula.
 
-If you’re *still* not sure, just commit. We’ll apply some arbitrary rule and make a decision :wink:.
+If you’re *still* not sure, just commit. We’ll apply some arbitrary rule and make a decision 😉.
 
 When importing classes, Homebrew will require the formula and then create an instance of the class. It does this by assuming the formula name can be directly converted to the class name using a `regexp`. The rules are simple:
 

docs/Gems,-Eggs-and-Perl-Modules.md

@@ -81,7 +81,7 @@ or use this:
 
 **However all versions of RubyGems before 1.3.6 are buggy** and ignore
 the above setting. Sadly a fresh install of Snow Leopard comes with
-1.3.5. Currently the only known way to get round this is to upgrade
+1.3.5. Currently the only known way to get around this is to upgrade
 rubygems as root:
 
 `sudo gem update --system`

docs/Homebrew-and-Python.md

@@ -58,7 +58,7 @@ Homebrew builds bindings against the first `python` (and `python-config`) in you
 **Warning!** Python may crash (see [Common Issues](Common-Issues.md)) if you `import <module>` from a brewed Python if you ran `brew install <formula_with_python_bindings>` against the system Python. If you decide to switch to the brewed Python, then reinstall all formulae with python bindings (e.g. `pyside`, `wxwidgets`, `pygtk`, `pygobject`, `opencv`, `vtk` and `boost-python`).
 
 ## Policy for non-brewed Python bindings
-These should be installed via `pip install <x>`. To discover, you can use `pip search` or <https://pypi.python.org/pypi>. (**Note:** System Python does not provide `pip`. Follow the instructions at https://pip.readthedocs.org/en/stable/installing/#install-pip to install it for your system Python if you would like it.)
+These should be installed via `pip install <x>`. To discover, you can use `pip search` or <https://pypi.python.org/pypi>. (**Note:** System Python does not provide `pip`. Follow the instructions at <https://pip.readthedocs.io/en/stable/installing/#install-pip> to install it for your system Python if you would like it.)
 
 
 ## Brewed Python modules

docs/How-To-Open-a-Homebrew-Pull-Request.md

@@ -25,7 +25,7 @@ Depending on the change you want to make, you need to send the pull request to t
 3. Add your pushable forked repository with `git remote add <YOUR_USERNAME> https://github.com/<YOUR_USERNAME>/homebrew-core.git`
  * `<YOUR_USERNAME>` is your GitHub username, not your local machine username.
 
-For formulae in central taps other than `homebrew/core`, such as `homebrew/science` or `homebrew/games`, substitute that tap's name for `homebrew/core` in each step, and alter the GitHub repository URLs as necessary.
+For formulae in central taps other than `homebrew/core`, such as `homebrew/science` or `homebrew/nginx`, substitute that tap's name for `homebrew/core` in each step, and alter the GitHub repository URLs as necessary.
 
 ## Create your pull request from a new branch
 
@@ -43,7 +43,7 @@ To make a new branch and submit it for review, create a GitHub pull request with
  4. `brew audit --strict <CHANGED_FORMULA>`
 6. Make a separate commit for each changed formula with `git add` and `git commit`.
 7. Upload your new commits to the branch on your fork with `git push --set-upstream <YOUR_USERNAME> <YOUR_BRANCH_NAME>`.
-8. Go to the relevant repository (e.g. https://github.com/Homebrew/brew, https://github.com/Homebrew/homebrew-core, etc.) and create a pull request to request review and merging of the commits in your pushed branch. Explain why the change is needed and, if fixing a bug, how to reproduce the bug. Make sure you have done each step in the checklist that appears in your new PR.
+8. Go to the relevant repository (e.g. <https://github.com/Homebrew/brew>, <https://github.com/Homebrew/homebrew-core>, etc.) and create a pull request to request review and merging of the commits in your pushed branch. Explain why the change is needed and, if fixing a bug, how to reproduce the bug. Make sure you have done each step in the checklist that appears in your new PR.
  * Please note that our preferred commit message format for simple version updates is "`<FORMULA_NAME> <NEW_VERSION>`", e.g. "`source-highlight 3.1.8`". `devel` version updates should have the commit message suffixed with `(devel)`, e.g. "`nginx 1.9.1 (devel)`". If updating both stable and `devel`, the format should be a concatenation of these two forms, e.g. "`x264 r2699, r2705 (devel)`".
 9. Await feedback or a merge from Homebrew's maintainers. We typically respond to all PRs within a couple days, but it may take up to a week, depending on the maintainers' workload.
 10. Thank you!

docs/Interesting-Taps-&-Forks.md

 # Interesting Taps & Forks
 
 A Tap is homebrew-speak for a git repository containing extra formulae.
-Homebrew has the capability to add (and remove) multiple taps to your local installation with the `brew tap` and `brew untap` command. Type `man brew` in your Terminal. The main repository https://github.com/Homebrew/homebrew-core, often called `homebrew/core`, is always built-in.
+Homebrew has the capability to add (and remove) multiple taps to your local installation with the `brew tap` and `brew untap` command. Type `man brew` in your Terminal. The main repository <https://github.com/Homebrew/homebrew-core>, often called `homebrew/core`, is always built-in.
 
 ## Main Taps
 

docs/Node-for-Formula-Authors.md

@@ -14,9 +14,9 @@ where `libexec` is the destination prefix (usually the `libexec` variable).
 
 # Download URL
 
-If the Node module is also available on the npm registry, we prefer npm hosted release tarballs over GitHub (or elsewhere) hosted source tarballs. The advantages of these tarballs are that they doesn't include the files from the `.npmignore` (such as tests) resulting in a smaller download size and that a possibly transpilation step is already done (e.g. no need to compile CoffeeScript files as a build step).
+If the Node module is also available on the npm registry, we prefer npm hosted release tarballs over GitHub (or elsewhere) hosted source tarballs. The advantages of these tarballs are that they don't include the files from the `.npmignore` (such as tests) resulting in a smaller download size and that any possible transpilation step is already done (e.g. no need to compile CoffeeScript files as a build step).
 
-The npm registry URLs have usually the format of:
+The npm registry URLs usually have the format of:
 
 ```
 https://registry.npmjs.org/<name>/-/<name>-<version>.tgz
@@ -26,33 +26,33 @@ Alternatively you could curl the JSON at `https://registry.npmjs.org/<name>` and
 
 # Dependencies
 
-Node modules, which are compatible with the latest Node version should declare a dependencies on the `node` formula.
+Node modules which are compatible with the latest Node version should declare a dependency on the `node` formula.
 
 ```ruby
 depends_on "node"
 ```
 
-If your formula requires to be executed with an older Node version you must vendor this older Node version as done in the [`kibana` formula](https://github.com/Homebrew/homebrew-core/blob/c6202f91a129e2f994d904f299a308cc6fbd58e5/Formula/kibana.rb).
+If your formula requires being executed with an older Node version you must vendor this older Node version as done in the [`kibana` formula](https://github.com/Homebrew/homebrew-core/blob/c6202f91a129e2f994d904f299a308cc6fbd58e5/Formula/kibana.rb).
 
 ### Special requirements for native addons
 
-If your node module is a native addon or has a native addon somewhere in it's dependency tree you have to declare an additional dependency. Since the compilation of the native addon results in a invocation of `node-gyp` we need an additional build time dependency on `:python` (because gyp depends on Python 2.7).
+If your node module is a native addon or has a native addon somewhere in its dependency tree you have to declare an additional dependency. Since the compilation of the native addon results in a invocation of `node-gyp` we need an additional build time dependency on `:python` (because gyp depends on Python 2.7).
 
 ```ruby
 depends_on :python => :build
 ```
 
-Please also note, that such a formula would only be compatible with the same Node major version it originally was compiled with. This means that we need to revision every formula with a Node native addon with every major version bump of the `node` formula. To make sure we don't overlook your formula on a Node major version bump, write a meaningful test which would fail in such a case (invoked with an ABI incompatible Node version).
+Please also note that such a formula would only be compatible with the same Node major version it originally was compiled with. This means that we need to revision every formula with a Node native addon with every major version bump of the `node` formula. To make sure we don't overlook your formula on a Node major version bump, write a meaningful test which would fail in such a case (invoked with an ABI incompatible Node version).
 
 # Installation
 
 Node modules should be installed to `libexec`. This prevents the Node modules from contaminating the global `node_modules`, which is important so that npm doesn't try to manage Homebrew-installed Node modules.
 
-In the following we distinguish between 2 type of Node module using formulae:
+In the following we distinguish between two types of Node modules using formulae:
 * formulae for standard Node modules compatible with npm's global module format which should use [`std_npm_install_args`](#installing-global-style-modules-with-std_npm_install_args-to-libexec) (like [`azure-cli`](https://github.com/Homebrew/homebrew-core/blob/d93fe9ba3bcc9071b699c8da4e7d733518d3337e/Formula/azure-cli.rb) or [`autocode`](https://github.com/Homebrew/homebrew-core/blob/1a670a6269e1e07f86683c2d164977c9bd8a3fb6/Formula/autocode.rb)) and
-* formulae were the `npm install` step is only one of multiple not exclusively Node related install steps (not compatible with npm's global module format) which have to use [`local_npm_install_args`](#installing-module-dependencies-locally-with-local_npm_install_args) (like [`elixirscript`](https://github.com/Homebrew/homebrew-core/blob/ec1e40d37e81af63122a354f0101c377f6a4e66d/Formula/elixirscript.rb) or [`kibana`](https://github.com/Homebrew/homebrew-core/blob/c6202f91a129e2f994d904f299a308cc6fbd58e5/Formula/kibana.rb))
+* formulae where the `npm install` step is only one of multiple not exclusively Node related install steps (not compatible with npm's global module format) which have to use [`local_npm_install_args`](#installing-module-dependencies-locally-with-local_npm_install_args) (like [`elixirscript`](https://github.com/Homebrew/homebrew-core/blob/ec1e40d37e81af63122a354f0101c377f6a4e66d/Formula/elixirscript.rb) or [`kibana`](https://github.com/Homebrew/homebrew-core/blob/c6202f91a129e2f994d904f299a308cc6fbd58e5/Formula/kibana.rb))
 
-Both methods have in common, that they are setting the correct environment for using npm inside Homebrew up and returning the arguments for invoking `npm install` for their specific use cases. This includes fixing an important edge case with the npm cache (Caused by Homebrew's redirection of `$HOME` during the build and test process) by using our own custom `npm_cache` inside `HOMEBREW_CACHE`, which would otherwise result in very long build times and high disk space usage.
+Both methods have in common that they are setting the correct environment for using npm inside Homebrew and are returning the arguments for invoking `npm install` for their specific use cases. This includes fixing an important edge case with the npm cache (caused by Homebrew's redirection of `$HOME` during the build and test process) by using our own custom `npm_cache` inside `HOMEBREW_CACHE`, which would otherwise result in very long build times and high disk space usage.
 
 To use them you have to require the Node language module at the beginning of your formula file with:
 
@@ -62,13 +62,13 @@ require "language/node"
 
 ### Installing global style modules with `std_npm_install_args` to libexec
 
-In your formula's `install` method, simply cd to the top level of your Node module if necessary and than use `system` to invoke `npm install` with `Language::Node.std_npm_install_args` like:
+In your formula's `install` method, simply cd to the top level of your Node module if necessary and then use `system` to invoke `npm install` with `Language::Node.std_npm_install_args` like:
 
 ```ruby
 system "npm", "install", *Language::Node.std_npm_install_args(libexec)
 ```
 
-This will install your Node module in npm's global module style with a custom prefix to `libexec`. All your modules executable will be automatically resolved by npm into `libexec/"bin"` for you, which is not symlinked into Homebrew's prefix. We need to make sure these are installed. Do this with we need to symlink all executables to `bin` with:
+This will install your Node module in npm's global module style with a custom prefix to `libexec`. All your modules' executables will be automatically resolved by npm into `libexec/"bin"` for you, which is not symlinked into Homebrew's prefix. We need to make sure these are installed. To do this we need to symlink all executables to `bin` with:
 
 ```ruby
 bin.install_symlink Dir["#{libexec}/bin/*"]
@@ -76,13 +76,13 @@ bin.install_symlink Dir["#{libexec}/bin/*"]
 
 ### Installing module dependencies locally with `local_npm_install_args`
 
-In your formula's `install` method, do any installation steps which need to be done before the `npm install` step and than cd to the top level of the included Node module. Then, use `system` with `Language::Node.local_npm_install_args` to invoke `npm install` like:
+In your formula's `install` method, do any installation steps which need to be done before the `npm install` step and then cd to the top level of the included Node module. Then, use `system` with `Language::Node.local_npm_install_args` to invoke `npm install` like:
 
 ```ruby
 system "npm", "install", *Language::Node.local_npm_install_args
 ```
 
-This will install all of your Node modules dependencies to your local build path. You can now continue with your build steps and take care of the installation into the Homebrew `prefix` by your own, following the [general Homebrew formula instructions](https://github.com/Homebrew/brew/blob/master/docs/Formula-Cookbook.md).
+This will install all of your Node modules dependencies to your local build path. You can now continue with your build steps and take care of the installation into the Homebrew `prefix` on your own, following the [general Homebrew formula instructions](https://github.com/Homebrew/brew/blob/master/docs/Formula-Cookbook.md).
 
 # Example
 

docs/Prose-Style-Guidelines.md

@@ -44,8 +44,8 @@ We prefer:
 * More generally, parallel list item structure
 * Capitalize all list items if you want, even if they're not complete sentences; just be consistent within each list, and preferably, throughout the whole page
 * Use a subordinate list item instead of dropping a multi-sentence paragraph-long item into a list of sentence fragments
-* Prefer Markdown over other markup formats unless their specific features are needed.
-* GitHub flavored Markdown. GitHub's implementation is the standard, period.
+* Prefer Markdown over other markup formats unless their specific features are needed
+ * GitHub Flavored Markdown. GitHub's implementation is the standard, period.
 
 ### Typographical conventions
 

docs/Python-for-Formula-Authors.md

@@ -4,7 +4,7 @@ This document explains how to successfully use Python in a Homebrew formula.
 
 Homebrew draws a distinction between Python **applications** and Python **libraries**. The difference is that users generally do not care that applications are written in Python; it is unusual that a user would expect to be able to `import foo` after installing an application. Examples of applications are `ansible` and `jrnl`.
 
-Python libraries exist to be imported from other Python modules; they are often dependencies of Python applications. They are usually no more than incidentally useful from a Terminal.app command line. Examples of libraries are `py2cairo` and the bindings that are installed by `protobuf --with-python`.
+Python libraries exist to be imported by other Python modules; they are often dependencies of Python applications. They are usually no more than incidentally useful from a Terminal.app command line. Examples of libraries are `py2cairo` and the bindings that are installed by `protobuf --with-python`.
 
 Bindings are a special case of libraries that allow Python code to interact with a library or application implemented in another language.
 
@@ -22,7 +22,7 @@ where `prefix` is the destination prefix (usually `libexec` or `prefix`).
 
 # Python module dependencies
 
-In general, applications should unconditionally bundle all of their dependencies and libraries should install any unsatisfied dependencies; these strategies are discussed in depth in the following sections.
+In general, applications should unconditionally bundle all of their dependencies and libraries and should install any unsatisfied dependencies; these strategies are discussed in depth in the following sections.
 
 In the rare instance that this proves impractical, you can specify a Python module as an external dependency using the syntax:
 
@@ -49,9 +49,9 @@ Applications that are compatible with Python 2 **should** use the Apple-provided
 ```ruby
 depends_on :python if MacOS.version <= :snow_leopard
 ```
-No explicit Python dependency is needed on recent OS versions since /usr/bin is always in `PATH` for Homebrew formulæ; on Leopard and older, the python in `PATH` is used if it's at least version 2.7, or else Homebrew's python is installed.
+No explicit Python dependency is needed on recent OS versions since /usr/bin is always in `PATH` for Homebrew formulae; on Leopard and older, the python in `PATH` is used if it's at least version 2.7, or else Homebrew's python is installed.
 
-Formulæ for apps that require Python 3 **should** declare an unconditional dependency on `:python3`, which will cause the formula to use the first python3 discovered in `PATH` at install time (or install Homebrew's if there isn't one). These apps **must** work with the current Homebrew python3 formula.
+Formulae for apps that require Python 3 **should** declare an unconditional dependency on `:python3`, which will cause the formula to use the first python3 discovered in `PATH` at install time (or install Homebrew's if there isn't one). These apps **must** work with the current Homebrew python3 formula.
 
 ## Installing
 
@@ -183,7 +183,7 @@ Sometimes we have to `inreplace` a `Makefile` to use our prefix for the python b
 
 Libraries **should** declare a dependency on `:python` or `:python3` as appropriate, which will respectively cause the formula to use the first python or python3 discovered in `PATH` at install time. If a library supports both Python 2.x and Python 3.x, the `:python` dependency **should** be `:recommended` (i.e. built by default) and the :python3 dependency should be `:optional`. Python 2.x libraries **must** function when they are installed against either the system Python or Homebrew Python.
 
-Formulæ that declare a dependency on `:python` will always be bottled against Homebrew's python, since we cannot in general build binary packages that can be imported from both Pythons. Users can add `--build-from-source` after `brew install` to compile against whichever python is in `PATH`.
+Formulae that declare a dependency on `:python` will always be bottled against Homebrew's python, since we cannot in general build binary packages that can be imported from both Pythons. Users can add `--build-from-source` after `brew install` to compile against whichever python is in `PATH`.
 
 ## Installing
 
@@ -213,7 +213,7 @@ Distribute (not to be confused with distutils) is an obsolete fork of setuptools
 
 ## What is `--single-version-externally-managed`?
 
-`--single-version-externally-managed` ("SVEM") is a setuptools-only [argument to setup.py install](https://pythonhosted.org/setuptools/setuptools.html#install-run-easy-install-or-old-style-installation). The primary effect of SVEM is to use distutils to perform the install instead of using setuptools' `easy_install`.
+`--single-version-externally-managed` ("SVEM") is a setuptools-only [argument to setup.py install](http://setuptools.readthedocs.io/en/latest/setuptools.html?#install-run-easy-install-or-old-style-installation). The primary effect of SVEM is to use distutils to perform the install instead of using setuptools' `easy_install`.
 
 `easy_install` does a few things that we need to avoid:
 

docs/Querying-Brew.md

@@ -31,9 +31,9 @@ The schema itself is not currently documented outside of the code that generates
 
 ## Examples
 
-_The top-level element of the JSON is always an array, so the `map` operator is used to act on the data._
+_The top-level element of the JSON output is always an array, so the `map` operator is used to act on the data._
 
-### Prety-print a single formula's info
+### Pretty-print a single formula's info
 
 `brew info --json=v1 tig | jq .`
 
@@ -63,6 +63,6 @@ To find the names of normal (not keg-only) formulae that are installed, but not
 
 ## Concluding remarks
 
-Using the JSON output, queries can be made against Homebrew with less risk of being broken due to Homebrew code changes, and without needing to understand Homebrew's ruby internals.
+Using the JSON output, queries can be made against Homebrew with less risk of being broken due to Homebrew code changes, and without needing to understand Homebrew's Ruby internals.
 
-If the JSON does not provide some information that it ought to, please submit request, preferably with a patch to add the desired information.
+If the JSON output does not provide some information that it ought to, please submit a request, preferably with a patch to add the desired information.

docs/Tips-N'-Tricks.md

@@ -5,7 +5,7 @@
 The supported method of installing specific versions of
 some formulae is to see if there is a versions formula like e.g. `gcc@6` available. If the version you’re looking for isn’t available, consider [opening a pull request](How-To-Open-a-Homebrew-Pull-Request.md)!
 
-### Installing directly from pull-requests
+### Installing directly from pull requests
 You can [browse pull requests](https://github.com/Homebrew/homebrew-core/pulls)
 and install through the direct link. For example Python 3.3.0 pull request [Homebrew/homebrew#15199](https://github.com/Homebrew/homebrew/pull/15199)
 

docs/Versions.md

 # Versions
 
-Now that [Homebrew/versions](https://github.com/homebrew/homebrew-versions) has been deprecated [Homebrew/core](https://github.com/homebrew/homebrew-core) supports multiple versions of formulae with a new naming format.
+Now that [Homebrew/versions](https://github.com/homebrew/homebrew-versions) has been deprecated, [Homebrew/core](https://github.com/homebrew/homebrew-core) supports multiple versions of formulae with a new naming format.
 
 In [Homebrew/versions](https://github.com/homebrew/homebrew-versions) the formula for GCC 6 was named `gcc6.rb` and began `class Gcc6 < Formula`. In [Homebrew/core](https://github.com/homebrew/homebrew-core) this same formula is named `gcc@6.rb` and begins `class GccAT6 < Formula`.
 

docs/brew-tap.md

@@ -73,7 +73,7 @@ If you need a formula to be installed from a particular tap, you can use fully
 qualified names to refer to them.
 
 For example, you can create a tap for an alternative `vim` formula. Without
-pinning it, the behavior will be
+pinning it, the behaviour will be
 
 ```bash
 brew install vim                     # installs from homebrew/core