We only test with GHC 8.6+ and the bounds should reflect that.
Related: a16541b834b5 ("ci: Drop support for GHC 8.4")
Related: 2e89e5ed23b4 ("Bump lower bound for base")
Adding `unGrab` to X.Operations is potentially a user-config breaking
change (Ambiguous occurrence ‘unGrab’ …), so we need xmonad-contrib to
conditionally reexport this (instead of just deprecating the now
duplicated definition). Thus we need a version bump here.
Related: 0156e2963b4d ("X.Operations: Add unGrab")
Debian stable is not on 8.6, which was always our guide as to which GHC
versions we want to support.
In particular, this lets us get rid of all the quickcheck-classes
special treatment.
Related: 400730fe3b
+ Prefer GHC 8.10.7 to 8.10.4, as versions seem to have stabilised now.
+ Add support for Stackage LTS 19; this ships with GHC 9.0.2.
+ Since a new version of 9.2 has been released, prefer 9.2.2 over 9.2.1.
Related: https://github.com/xmonad/xmonad-contrib/pull/694
Style guidelines should be where most people will see them. Since we
already ask people to read CONTIRBUTING.md when they submit a pull
request, putting them in there seems like the best place.
We can also drop the curious "or freer" clause from the licensing point,
much like xmonad-contrib@f39218ddb5ffeddce90f620910d5ef2c14f2b43d
already did.
utf8-string isn't needed since d9e3ebf53194d1cf02bae28f0c885b5c75610cfa
(late 2014).
Most of the executable xmonad deps are unnecessary since
307b82a53d519f5c86c009eb1a54044a616e4a5c (early 2015).
Switch from data-default to data-default-class to avoid bringing in deps
and instances we don't need.
pandoc's API changes often enough that distros like Debian were patching
our GenerateManpage.hs to work with their version of pandoc, and it
doesn't build against any Stackage LTS except the recently released
LTS-17. Also, building pandoc from source takes quite some time and
resources.
But for what benefit? We're not using any special pandoc functionality
whatsoever. It's just that it was all in Haskell and the entire build
was orchestrated by cabal, but is all that complexity and resource
consumption worth it? I think not.
(Frankly, this whole thing was just a massive waste of time as the help
text in Config.hs isn't generated at all, so we still need to do this
manually. And then, the default key-bindings in core are unlikely to
change ever again.)
Let's simplify this:
* drop all dependencies except base and just run it through runhaskell
* add a Makefile and GH Actions workflow that invokes this after push
* only ship the results in release tarball, not the scripts which are
considered our dev infrastructure
Closes: https://github.com/xmonad/xmonad/issues/283
Related: https://github.com/xmonad/xmonad/pull/260
Related: https://github.com/xmonad/xmonad/pull/261
Related: https://github.com/xmonad/xmonad/pull/265
Related: https://github.com/xmonad/xmonad/pull/266
Related: https://github.com/xmonad/xmonad/pull/267
Related: https://github.com/xmonad/xmonad/pull/268
The tests are implemented by using a newtype wrapper `TestStack`. This is to
avoid creating `Eq1` and `Show1` instances for `Stack` itself, which are needed
by quickcheck-classes to run with GHC less than 8.5. Tests are automatically
generated by `traversalLaws` and `foldableLaws` using the `Arbitrary` instance
for `TestStack`.
`Functor` is provided by DeriveFunctor.
`Foldable` uses `integrate` (`Stack`'s `toList`).
`Traversable` uses the `Reverse` Applicative to traverse the `up` list in
reverse order.
