The documentation for this module was lacking, making it significantly
harder to use than the functionality wise very similar
X.A.CycleRecentWS—change that.
This changes how the "is*Of" infix operators are hoisted into the
ManageHook context. Instead of `q ~? x` being a lifted version of
`isPrefixOf q x` we instead let it be a lift of `isPrefixOf x q`.
While this obviously does not matter for symmetric operators like `(==)`
and `(/=)`, for `isInfixOf` it is rather essential. The reason for that
is that the given `q` on the left side is an atom that can't (shouldn't)
be changed (by the user) and we only have control over the right hand
side. Otherwise, things like
title ~? "foo"
would read "only match if `title` is an infix of `foo`" instead of the
much more useful "only match if `foo` is an infix of `title`".
Fixes: 8b6f17ba66
This file was obviously copied from `DwmStyle`, and the author missed changing that
out to `simpleDeco` in one place. Just patching in place since it's a one-word change.
Instead of telling the user how to add custom keybindings to
xmonad—something which is already done in the tutorial—instead explain
instead how one would go about writing a version of
X.U.EZConfig.additionalKeys. This mostly involves looking at the type
signatures and sticking some standard functions together, so it's quite
a decent way to learn about some of xmonad's internals.
During the release of xmonad 0.17.0, I realized that we need to be able
to upload candidates before tagging the release on GitHub, because there
might be issues with the tarball and Hackage may reject it. When that
happened, I had to remove the release, delete the tag, upload the
candidate manually to see what's wrong with it, try to fix it, upload it
manually again, and so on.
This commit swaps the logic: when the workflow is invoked manually, it
uploads the candidate. This can be done multiple times, and once
everything is fine, the release can finally be tagged and it's released
to Hackage proper. The only disadvantage is that we need to remember to
try uploading the candidate. Not sure if there's a perfect solution…
It no longer does what it was intended to do, and in fact, now does the
opposite.
When X.A.Search came to be in ~2007, Google's default of showing 10 or
so search hits was radically inadequate for poweruser needs. The 'num'
argument was used to force display of more hits (i.e., n meant 'display
at least n hits per page').
However, at some point, 'num' was inverted to mean something
catastrophically different: now it apparently means 'display no more
than n hits, total'. If you use that parameter, you will get 1 or 2
pages of hits at most reading 'About 98 results' or 'About 99
results' (no matter how many millions are available), and a blurb at the
bottom of the final page saying 'In order to show you the most relevant
results, we have omitted some entries very similar to the 99 already
displayed.' Removing the 'num' parameter then shows you all the hits
that were suppressed.
This is bad, and should be removed.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/642
Co-authored-by: Gwern Branwen <gwern@gwern.net>
ConfigureEvents may occur after a window has been deleted, an UnmapEvent
has already been sent (and thus xmonad already unmanaged the window),
but before a DestroyWindowEvent is caught by the eventHook. For
example, this is the case when one uses smartBorders with a single
window (such that smartBorders is "active"). The ConfigureEvents
sensibly already have an empty stack (because the UnmapEvent has already
been received), which we then copy to the history.
Whenever a parent window has been found, the sensible thing to do is to
always restore it. The fact that oldStack is Nothing simply encodes an
empty workspace and is thus something we definitely need to handle as
well.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/638
In [1] we changed the return type to not be an IO action and hence this
example can't work, even with an otherwise correct configuration.
[1]: 168cb6a6c3 (Removed unnecessary IO)
Since the tutorial is really the better place to start learning how to
use xmonad, X.D.Extending can be the place for more "advanced" usage
examples. These would be things like writing small functions to scratch
an itch (rather than entire modules). Rewrite the introduction
accordingly.
On the way, remove some small inconsistencies/dead links/remarks about
how things are different from version 0.5 onwards—these times are long
gone now.
The configurations on the wiki are quite old and mostly non-functional
at this point. Instead, we have a shiny new tutorial we can refer to.
It contains links to actual maintainers configurations (complex they may
be, at least they compile).
This was temporarily disabled in 229d52ff07 and 086db3123b because we
couldn't keep xmonad-contrib backwards compatible with xmonad 0.15 any
more, but xmonad 0.17.0 is out now and we can try to stay compatible for
a while.
Using `ppPrinters` with `WorkspacePredicate` and `WorkspaceFormatter`
allows users to define custom workspace types, beyond the ones
integrated in PP (i.e. urgent, current, visible, visible with no
windows, hidden, and hidden with no windows). `WorkspacePredicate`s are
added for these predicates (`isType`) with unsafe versions that assume
that predicates with a higher precedence already faield `isType'`.
`WorkspacePredicate`s can also be combined and modified with `notWP`,
`andWP`, and `orWP`.
Related: https://github.com/xmonad/xmonad-contrib/issues/557
Co-authored-by: Tomáš Janoušek <tomi@nomi.cz>
The CONTRIBUTING.md file for xmonad now has style guidelines [1]. Since
X.D.Developing does not add anything new here and we direct new
contributors to CONTRIBUTING.md anyways, simply refer to the relevant
section.
[1]: bc8f7ff133
* The Haddock documentation is a very good resource for the general
markup syntax.
* Since we are very biased in favour of stack, document how to build
Haddock docks with it.
Deprecation warnings are now shown to users via xmessage when xmonad
recompiles, and this may include warnings in xmonad(-contrib) itself if
people have a build script that invokes stack/cabal without --silent,
and they then may get confused. The deprecation warning in that case
won't be shown every recompile but only once whenever xmonad(-contrib)
needs to be rebuilt, but it's still annoying.
This silences the warning. We intend to refactor this part of the code
so this is a temporary measure.
Fixes: f666cf4e4e ("X.H.EwmhDesktops: Deprecate standalone hooks")
