Instead of providing these as default values, as originally planned,
just add a note for users who wish to customise that part of the prompt.
We simply get the user config in mkPassPrompt and so overriding that
with a custom searchPredicate and sorter seems unwise.
Closes: https://github.com/xmonad/xmonad-contrib/issues/746
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.
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.
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
839302533b, 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 3fc830aa09, 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.
