Add the trivial Arbitrary instance for Priority, extend the Arbitrary
instance of OrgMsg, as well as some plumbing. Also work in some unit
tests for regression testing.
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>
When the -XOverloadedStrings language extension is on, treat a string s
as the parser 'string' s, when appropriate. This allows one to write
things like "a" *> otherParser instead of 'string' "a" *> otherParser.
The `lisp` and `elpa` lists will simply be the (unqualified) file names.
Thus, if we use isInfixOf and try to require a library with a very short
name (like s.el), other things may be chosen over it. isPrefixOf,
together with the additional `-`, prevents this from happening.
Data.Default deprecations were removed in
5140f5b5d06790e055eb7fb0cf3eccc4997aa736, yet some comments still refer
to defaultTConf—fix that.
Related: 6b4675e3fa85f95f808a95f8cad790e798cf6ad5
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
We haven't used this for a while, and since we dropped descriptions in
X.D.Extending in favor of the haddock-generated index in
839302533bed6c6ece709a9d8508cc9b773b3975, it's useless.
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
X11 only handles alpha channels in a restricted set of APIs (such as
setting `border_color`); most others throw undocumented errors and/or
produce black pixels. Document this, and mask out alpha where it
matters.
Fixesxmonad/xmonad#395, xmonad/xmonad#398.
As the XMonad config is commonly customized by saying
def { startupHook = ...
, manageHook = ...
, ...
}
It seems consistent to allow the same for an individual hook config:
let urgencyHook = def { suppressWhen = ...
, remindWhen = ...
}
Since 3fc830aa09368dca04df24bf7ec4ac817f2de479, scratchpads are now
added in namedScratchpadManageHook. This, however, means that we need
some kind of MapRequestEvent to happen before processing scratchpads,
otherwise the manageHook didn't run yet and our extensible state is
being left empty. When trying to open a scratchpad right after starting
xmonad—i.e., before having opened a window—this may not be the case.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/728
Add support for EZConfig-style bindings while also maintaining some
guarantees as to which type of representation we will store in the
extensible state. This means that parsing of the keys will happen no
later than the call to `modal`.
Users can choose to use `mkKeysEz` or `mkKeysFun` to create a new
collection of keys to bind for a mode. This is deemed more ergonomic
than exporting the respective constructors directly.
Mostly small things, like making imports line up with the provided
comments. Also:
+ Rename mode' -> modeWithExit. This seems like a better name for
discoverability reasons.
+ Make the fields of Mode strict, because they have no reason not to,
really.
While monitors are, more often than not, wider than they are high,
specifying a ratio in the vertical direction can also make sense; e.g.,
when flipping a monitor by 90 degrees. Thus, we should definitely
support both.
This adds documentation for the new EDSL, as well as small fixes to
existing docs.
Importantly, I've added myself as a maintainer of the file (even though
we don't really care about this at this point) and updated the
copyright; the changes seem large enough to warrant this.
