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.
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.
Some panels—such as polybar—require _NET_DESKTOP_VIEWPORT support in
order to know which workspace is on which monitor. They are then able
to only show workspaces defined on the same output as the bar with just
X11 properties.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/708