It is not ideal placement, but because of the current CLI design there is no ideal placement at all, except to place implications of every key in its own headline, which would mean to duplicate most of `--help` in README.
#663 already shows that `--help` is not understandable, because currently everything is intermingled.
Further rehashing of README is of course possible, but I see no way to lay-out needed info cleanly (there is a lot of if/else cases) without the redesign of the CLI.
Switching Nix dev env and its CI to GHC 8.10.
To avoid contribution loop problems, since we pin Nixpkgs in default.nix - it is logical by default CI to follow the supported way of building.
The downsides are:
* Maintainer would need to solve Nix issues by himself, when wants to update the Nixpkgs revision, or play a wait and pick rev game with Nixpkgs.
* On the rev update, the `Nix-shell & Hoogle` CI build needs to rebuild the whole Haskell stack from the bottom up, so the rev update process takes a lot of wait time (hours), and also should be done from the repo internal branch to save the already built parts of the stack during rev testing.
Also one CI build was not terminating, so switched to the new rev.
Further the switch to 8.10.1 arrives.
Under 8.10.1 HNix currently can not be built strictly.
This build is strict, so it is bounded to 8.8 currently. Which is a Nixpkgs default.
To avoid contribution loop problems, since we pin Nixpkgs in default.nix - it is
logical by default CI to follow the supported way of building.
The downside is - the maintainer would need to solve Nix issus when one tries to
update the Nixpkgs revision.
When README changes in master, this workflow runs and autochecks, autogenerates the idempotent TOC and autocommits it, so project TOC persistently stays current.