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.
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).
This is a mostly cosmetical commit, in the sense it doesn't change the contents
of any package, but reorganizes the overall Nixpkgs expressions.
Terminal emulators are an ubiquitous tool for any Unix user; even the beginners
are routinely familiarized to it. And, manifestly, there are many
implementations of terminal emulators out there, from those traditionally made
in C and C++ to those written in Haskell and Go.
Terminal emulators deserve more highlight. This commit does that by creating a
category for them.
only very few people followed the strict policy in the last 5 years. the
maintainers accept backports without reason when it's obvious, so i
updated the policy to reflect that
