Use lowercase hex numbers fixes #1692 (#1775)

[etc/vim.git] / docs / installation_and_usage.md

diff --git a/docs/installation_and_usage.md b/docs/installation_and_usage.md
index 7d37f59264bf82cfdf3a7b1eb305e68339bc0f0f..c91a1c400efca787cc813ebd990e38e97e27eb8a 100644 (file)
--- a/docs/installation_and_usage.md
+++ b/docs/installation_and_usage.md
@@ -41,7 +41,7 @@ Options:
   -l, --line-length INTEGER       How many characters per line to allow.
                                   [default: 88]
 
   -l, --line-length INTEGER       How many characters per line to allow.
                                   [default: 88]
 

-  -t, --target-version [py27|py33|py34|py35|py36|py37|py38]
+  -t, --target-version [py27|py33|py34|py35|py36|py37|py38|py39]

                                   Python versions that should be supported by
                                   Black's output. [default: per-file auto-
                                   detection]
                                   Python versions that should be supported by
                                   Black's output. [default: per-file auto-
                                   detection]


@@ -119,7 +119,7 @@ about _Black_'s changes or will overwrite _Black_'s changes. A good example of t
 should be configured to neither warn about nor overwrite _Black_'s changes.
 
 Actual details on _Black_ compatible configurations for various tools can be found in
 should be configured to neither warn about nor overwrite _Black_'s changes.
 
 Actual details on _Black_ compatible configurations for various tools can be found in

-[compatible_configs](https://github.com/psf/black/blob/master/docs/compatible_configs.md).
+[compatible_configs](https://github.com/psf/black/blob/master/docs/compatible_configs.md#).

 
 ## Migrating your code style without ruining git blame
 
 
 ## Migrating your code style without ruining git blame
 


@@ -167,12 +167,13 @@ know!)
 
 ## NOTE: This is a beta product
 
 
 ## NOTE: This is a beta product
 

-_Black_ is already [successfully used](#used-by) by many projects, small and big. It
-also sports a decent test suite. However, it is still very new. Things will probably be
-wonky for a while. This is made explicit by the "Beta" trove classifier, as well as by
-the "b" in the version number. What this means for you is that **until the formatter
-becomes stable, you should expect some formatting to change in the future**. That being
-said, no drastic stylistic changes are planned, mostly responses to bug reports.
+_Black_ is already [successfully used](https://github.com/psf/black#used-by) by many
+projects, small and big. It also sports a decent test suite. However, it is still very
+new. Things will probably be wonky for a while. This is made explicit by the "Beta"
+trove classifier, as well as by the "b" in the version number. What this means for you
+is that **until the formatter becomes stable, you should expect some formatting to
+change in the future**. That being said, no drastic stylistic changes are planned,
+mostly responses to bug reports.

 
 Also, as a temporary safety measure, _Black_ will check that the reformatted code still
 produces a valid AST that is equivalent to the original. This slows it down. If you're
 
 Also, as a temporary safety measure, _Black_ will check that the reformatted code still
 produces a valid AST that is equivalent to the original. This slows it down. If you're