The current doc is wildly out of touch with reality. A regex search shows
the following stats.
```
Style example Frequency Regex used
nix-2-5: 8 [a-zA-Z]-[0-9]+(-[0-9]+)+ =
nix-2_5: 17 [a-zA-Z]-[0-9]+(_[0-9]+)+ =
nix_2_5: 689 [a-zA-Z]_[0-9]+(_[0-9]+)+ =
nix_2-5: 1 [a-zA-Z]_[0-9]+(-[0-9]+)+ =
```
3s is too small a margin for a loaded slow system to start a bloated
program.
This leads to problems when tests are written on decent dev hardware
but later run on build farms of potentially slower hardware,
particularly in the case of non x86.
The chance of needing the timeout is actually very small, so those
rare 57s are a reasonable price to pay for fewer timeouts on build
farms, each of which should be investigated and usually fixed by
increasing the timeout.
We are still using Pandoc’s Markdown parser, which differs from CommonMark spec slightly.
Notably:
- Line breaks in lists behave differently.
- Admonitions do not support the simpler syntax https://github.com/jgm/commonmark-hs/issues/75
- The auto_identifiers uses a different algorithm – I made the previous ones explicit.
- Languages (classes) of code blocks cannot contain whitespace so we have to use “pycon” alias instead of Python “console” as GitHub’s linguist
While at it, I also fixed the following issues:
- ShellSesssion was used
- Removed some pointless docbook tags.
The patch utility does not understand git formatted patches.
For text files, there is no problem, but binary files use the
git format.
The -a param makes git diff put binary files into the patch in
raw format that can be understood by the patch tool.
To me, as a native English speaker, this doesn't change the meaning of
the sentence at all. But to a non-native speaker, this can read like
the staging-next rules are only recommendations. Let's make this
clearer.
Specify that the merges from master to staging-next to staging are
performed by GitHub actions. This helps the reader understand the
relationship between the branches.
* doc: add function argument order convention
Ordering by usage is the de facto ordering given to arguments. It's
logical, and makes finding argument usage easier. Putting lib first is
common in NixOS modules, so it's reasonable to mirror this in nixpkgs
proper. Additionally, it's not a package as such, has zero dependencies,
and can be found used anywhere in a derivation.
* doc: clean up usage of lib
`PANDOC_LUA_FILTERS_DIR` is set in `makeFlags` in `doc/default.nix`,
and needs to be explicitely passed to `make` when called manually.
Signed-off-by: Pamplemousse <xav.maso@gmail.com>
I think we should have something in the manual people can point to
about this, to avoid rehashing it over and over in PRs. "stdenv.lib"
makes it look like lib is part of stdenv, which it isn't, and makes it
even more confusing as a newcomer to figure out what stdenv is (and
isn't).
