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
Make it clearer that we in fact do not require implementations for a
minimal complete definition, but that the default implementations have a
certain kind of dependency structure.
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.
migrateState is only necessary when _live_ upgrading from xmonad 0.12,
so I believe we can drop it now.
This fixes a compilation warning that we'd otherwise have to suppress.
Since 8863761d660a70984595d9162319801e648b69ec (early 2014), the test
suite is a proper cabal test-suite and needs the "xmonad" library to be
built, and thus the flag serve no purpose.
Related: https://github.com/xmonad/xmonad/issues/283
* rename workflow to Stack
* test all branches (provides feedback before opening a PR)
* split into buildenv deps and stack build
* make the deps list more git-friendly; tweak the deps
* use stack from github environment (I've seen the curl fail intermittently)
* use `*.cabal` to minimize diff between our repos
Related: https://github.com/xmonad/X11/pull/75
Related: https://github.com/xmonad/xmonad/issues/283
Since 4565e2c90ef5, not only do we raise the floating window to top when
starting dragging, we also restack all other managed windows directly
below it (mouse{Move,Resize}Window now call `float` while dragging,
which invoke `windows` and that restacks all windows). This means that
as soon as we start dragging, all xmonad-managed windows are raised to
the top, obscuring any unmanaged (override-redirect) windows that were
at the top before.
The good thing about 4565e2c90ef5 is that since we refloat and refresh
on every mouse move while dragging, we no longer need the `raiseWindow`.
It was probably only there so that it stays visible when dragging
between Xinerama screens (3cb64d74617), and that's taken care of by
refloating the window on every move. As the refresh restacks everything
anyway, the only function of the `raiseWindow` is to stack windows above
unmanaged ones, which is likely undesirable.
There is still one known issue related to obscuring notifications:
https://github.com/xmonad/xmonad/issues/89
That one is caused by X opening new windows at the top of stacking order
and xmonad then restacking all other windows directly beneath them if
the new window is in the master position of the stack. Some notification
daemons like dunst work around this by raising themselves whenever a new
window is opened
(77bfbc4f7f/src/x11/x.c (L348)).
Fixing this one is considerably more complicated as we'd need to keep
track of (unmanaged) windows that wish to be stacked above new windows,
therefore this won't be addressed here, and probably won't be addressed
in xmonad core ever.
Fixes: https://github.com/xmonad/xmonad/issues/208
Fixes: 4565e2c90ef5 ("fix #63: window jumping to origin position when dragging")
Unfortunately, our CI builds have a hard-coded assumption that all kinds of
LTS-X builds can be performed with the same stack.yaml file, which is not true.
We need to use specialized build instructions for each version of the
environment we're building in, e.g. stack-lts-16.yaml, stack-nightly.yaml, and
so on. Making that change is not super hard, but it's not completely trivial
either because the hooks use a hash of the stack file to determine whether the
cash is still valid, etc., and I'm not entirely sure about the best way to
adapt that code to support multiple YAML files.
For the time being, the most important build IMHO is Stackage Nightly,
because (a) we really want to support the nightly snapshot since (b) it can
compile the genmanpage executable relatively easily.
Let's use a moderately recent compiler like ghc-8.10.3
instead of the old 8.8.x branch for development. Same goes
for our dependencies; development should take place with
recent versions of our dependencies.
Improve handling of the whole XDG situation. This now looks as follows
1. If all three of xmonad's environment variables (XMONAD_DATA_DIR,
XMONAD_CONFIG_DIR, and XMONAD_CACHE_DIR) are set, use them.
2. If there is a build script `build' or configuration `xmonad.hs' in
`~/.xmonad', set all three directories to `~/.xmonad'.
3. Otherwise, use XDG_DATA_HOME, XDG_CONFIG_HOME, and
XDG_CACHE_HOME (or their respective fallbacks).
If none of the above exist, we default to using the XDG_* variables,
creating the necessary directories if needed.
