xmonad-testing isn't really being used, so the wording needs to be
changed in CONTRIBUTING.md and in the PR template. The important thing:
we want an example for new modules/functionality, and appropriate tests.
Related: https://github.com/xmonad/xmonad/issues/341
Instead of manually compiling with `-Wall -Werror` and the like, we have
a `pedantic` flag in xmonad's cabal file with which to run the CI.
Since contributors are very unlikely to not use either stack or cabal to
build xmonad, we should refer them to this flag instead of listing all
of the options they would need to compile xmonad with in order to check
their work.
Fixes: bc8f7ff133
We install GHC using apt, so stack shouldn't install it, but should it
ever end up installing it anyway (version mismatch, version unavailable
in hvr/ghc ppa, …), we don't want it wasting valuable cache space.
Nowadays, the IRC and (since it is linked to it) matrix channels are
much faster ways to get into contact with us than the (very low traffic)
mailing list. CONTRIBUTING should reflect that, since especially new
contributors might not know where to go to get a feeling for the people
working on the project—or worse, think we only communicate via pull
requests and issues!
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.
Create three sections (enhancements, bug fixes, breaking changes) in
order to organise the changes for the v0.17.0 release.
As discussed in [1], the breaking changes really aren't breaking changes
to normal users. The only exception could be the GenerateManpage
change, but even that is only important for distro maintainers. Hence,
move all of these to the very back, such that we can mention exciting
features like the stack integration at the top instead.
Related: https://github.com/xmonad/xmonad/pull/340
[1]: https://github.com/xmonad/xmonad/pull/340#discussion_r734956547
* add logo and badges to make it prettier
* revamp installation sections
* update xmonad-contrib reference and move upwards
* drop other useful programs, this is in download.html
* add new Contributing section
Fixes: https://github.com/xmonad/xmonad/issues/199
While an implementation of `liftM2 (&&)` may seem like a straightforward
lift of `(&&)` into a monadic setting, it actually expands to
(<&&>) :: Monad m => m Bool -> m Bool -> m Bool
mb <&&> mb' = do
a <- mb
b <- mb'
return (a && b)
which runs both monadic effects first and then applies `(&&)`.
This is fixed by introducing a monadic version of `if-then-else` (which
is also exported due to its usefulness) that checks the second result
only if this is explicitly necessary.
Turns out there was another aspect of `broadcastMessage` behaviour that
I missed in my review of the refactor: X.L.Tabbed updates the windowset
during handleMessage (via `X.O.focus`) and expects that change to
persist (by returning `Nothing` and hoping no other layout or layout
modifier returns `Just`). That's quite a hack, but the LayoutClass
interface doesn't allow a cleaner way to do this (well, some extensible
state plus a custom event hook might work, but then the layout isn't
self-contained any more).
And since rereading workspace layouts during `modifyLayouts` would force
this back into O(n²), we might as well revert the whole refactor. :-/
Fixes: https://github.com/xmonad/xmonad/issues/329
We now use this in `broadcastMessage`, so to not change which workspaces
get the message first, we need to change the order here. This wouldn't
normally be safe to do either, but there are no other uses of
`runOnWorkspaces` neither here nor in xmonad-contrib, so it should
actually be fine.
This uses two new functions (not exported):
`workspacesA` traverses the workspaces in a StackSet.
`runOnWorkspaces` runs `workspacesA` with the X state.
The current definition of broadcastMessage seems to be O(n^2) in the number of workspaces because it uses sendMessageWithNoRefresh and sendMessageWithNoRefresh uses updateLayout and updateLayout uses runOnWorkspaces.
This changes broadCastMessage and sendMessageWithNoRefresh to each use a single
call to runOnWorkspaces.
`executeFile` encodes the arguments with the current locale's encoding,
and GHC as invoked during recompilation quite likely also outputs any
errors in the locale encoding, which we then read using `readFile` again
decoding in the locale encoding, so it really makes no sense to force a
specific encoding here. What was I thinking? :-)
Related: https://github.com/xmonad/xmonad/issues/322#issuecomment-900503386
Fixes: https://github.com/xmonad/xmonad/issues/324
Fixes: aa35ea1856 ("Make xmessage handle UTF-8 and export it")
