The stack CI already tests against 9.2.7 instead of 9.2.5 (as the cabal
file said), since we just specify the major version of the LTS resolver,
and lts-20 is up to 9.2.7 by now. Not much has changed since 9.2.5, but
update the haskell-ci workflow regardless. Likewise, 9.4 can be bumped
one minor version, so do that as well.
X.L.StateFull's `FocusTracking` and the eponymous `TrackFloating` were
redundant, hence the former was slated for deprecation. However,
the latter and its host module are somewhat poorly named; the layout
modifier has little relation to floats. As such, it's renamed and
rehosted, becoming the eponymous `FocusTracking`.
The redundant offerings in the original modules are redefined in terms
of the new module where possible, and deprecated.
See: #418; comments on #253, #783.
These modules were duplicating a substantial amount of low-level code.
`X.A.CycleWorkspaceByScreen` had already separated most of the
implementation details from the logic with `repeatableAction`; all that
was left was to generalise it a little further, put it in a suitable
place and express the other modules through it.
New module that allows for having a configurable border position around
windows. Originally found in a comment by L. S. Leary in [1]. Enough
people have requested this on IRC in recent memory to warrant a proper
module.
[1]: https://github.com/xmonad/xmonad/issues/152#issuecomment-362716434
Co-authored-by: L. S. Leary <LSLeary@users.noreply.github.com>
With [1] merged, the XMonad module from core now exports mkGrabs and
setNumlockMask (now cacheNumlockMask). However, since we want
xmonad-contrib 0.17.1 to compile against xmonad 0.17.0 still, hide the
function for now and continue to use the vendored copies we have in
X.U.Grab currently. We have to ignore the dodgy-imports warning when
-fpedantic is on, but that seems like a small price to pay.
A breaking change for this is planned for 0.18.0.
[1]: https://github.com/xmonad/xmonad/pull/405
Last year I thought a bit about making this an actual `executable` in
xmonad-contrib.cabal, but decided against it. Unfortunately I can't
remember why. So let's do the bare minimum to at least ship it now, and
if I remember or if anyone has any ideas, we can do the next step or
document why not.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/734
This fixes several issues related to parsing of parent PIDs:
* A process with lines or spaces or parentheses in its process name
would confuse the code in X.A.SpawnOn and possibly lead to a
`Prelude.read: no parse` exception.
* `X.H.WindowSwallowing.isChildOf` looked for the parent PID anywhere in
the output of pstree, so single-digit parent PIDs would be considered
as parents of any process with that digit anywhere in its chain of
parent PIDs. (Note that apps in PID namespaces like in Flatpak often
have single-digit PIDs.)
* `pstree` is no longer required in `$PATH`.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/726
+ Prefer GHC 8.10.7 to 8.10.4, as versions seem to have stabilised now.
+ Add support for Stackage LTS 19, which ships with GHC 9.0.2.
+ Since a new version of 9.2 has been released, prefer 9.2.2 over 9.2.1.
Also, explicitly pass -XCPP to hlint; see [1].
[1]: https://github.com/ndmitchell/hlint/issues/1360
We do not ship the nix flake in the release tarball, so it does not make
sense to include NIX.md in there either; at least for now.
Fixes: 4ca46c24148062064d266f85acac973de07aae24 (Add NIX.md)
There are multiple ways one could use XMonad with nix, so a separate
file for documenting all of this seems appropriate. E.g., when it
contains the respective installation instructions (e.g, "normally" as
instructed in the NixOS wiki, via stack, via flake, ...) we could link
to it from INSTALL.md.
For now it's a good place to document the new `develop.nix`
functionality.
Co-authored-by: Ivan Malison <IvanMalison@gmail.com>
In a multi-head setup, it might be useful to have screen information of the
visible workspaces combined with the workspace name, for example in a status
bar. This module provides utility functions to do just that.
Add very basic unit tests for EZConfig to see if it can parse all of the
keys (and key combinations) that it promises to parse.
The long-term goal here should be to write a pretty-printer for EZConfig
and to check whether that's a proper inverse (either in the normal sense
or in the inverse semigroup sense), as the tests for X.P.OrgMode do.
This module provides a parser combinator library based on base's ReadP,
which aims to function more like other popular combinator libraries like
attoparsec and megaparsec.
In particular, the Alternative and Monoid instances are left-biased now,
so combinators like `many` and `optional` from Control.Applicative work
in a more intuitive manner. Further, some functions (like `endBy1`)
only return the "most successful" parse, instead of returning all of
them. We can now get away with providing a single parsing result
instead of ReadP's list of results (as such, parsers need to be
disambiguated earlier instead of trimming the list down after parsing).
updateHistory leaks unfiltered windows from previous states as it is never
forced. The consumer of such data structure is not visible to ghc, so the
demand analysis has to fallback on pure laziness.
We fix this inserting evaluation points on the `historyHook` function. We do
this for two reasons, this is the only function calling `updateHistory`.
Plus we cannot do it clearly at the `updateHistory` function as we operate
inside a continuation on withWindowSet. In respect to the `put`, everything
would be a big thunk.
I've tested these manually by adding them to extra-deps. Hopefully
they'll soon be available in a release of GHC or Stackage, so I'm not
adding an extra stack.yaml to test this.
* "community-maintained" is more accurate and sounds better than "third-party"
* refresh description
* add logo and badges to make it prettier
* update doc links
