Single-commit pull requests are discouraged by the core team now, so
drop that section and just refer to cbeams a kernel docs instead.
Related: https://github.com/xmonad/xmonad/issues/341
On IRC an issue came up where a user couldn't press M-] since they were
using a German keyboard layout and ] is put behind some AltGr
combination. The correct way to specify that would be something along
the lines of M-M5-9, but we don't really want to go into that in the
tutorial. Thus, only use the obvious modifiers, as well as letters,
which should work on every layout.
So far, some functions like focus{Up,Down} and swap{Up,Down} had
combined Haddock comments, since giving each their own would result in
some duplication of information. This is nicer when reading the source,
but Haddock can't really handle this when generating the HTML page,
which will come out a bit garbled in that case. Since a lot of users
may be only reading the Haddocks, we should prefer this to a source with
as few redundancies as possible.
Closes: https://github.com/xmonad/xmonad/issues/387
+ Prefer GHC 8.10.7 to 8.10.4, as versions seem to have stabilised now.
+ Add support for Stackage LTS 19; this ships with GHC 9.0.2.
+ Since a new version of 9.2 has been released, prefer 9.2.2 over 9.2.1.
Related: https://github.com/xmonad/xmonad-contrib/pull/694
Factour out the code used to detect whether a window should be floating
in Operations.hs in a new function named isFixedSizeOrTransient
Modify willFloat to use the factored out code from Opeartions.hs
When dragging and resizing windows, users may expect the cursor to
change to indicate the respective behaviour. In particular, many other
window managers already do this [1] [2].
Thus, introduce a new (non-exported) `mouseDragCursor` function that
takes a cursor shape and change the generic resize and move functions to
use that. The reason that we don't change `mouseDrag` itself (for now)
is that this is exported and quite a few contrib modules use it—breaking
compatibility with xmonad-0.17.0 so soon after the release seems unwise.
Fixes: https://github.com/xmonad/xmonad/issues/348
[1]: https://git.suckless.org/dwm/file/dwm.c.html#l1567
[2]: 7a8fa9d27a/lib/awful/mouse/resize.lua (L23)
We have had this situation happen a few times now: users update
xmonad (say, to 0.17.0) but forget that they still have an older version
installed via the distributions repositories. Features that depend on
the "bootstrap" xmonad executable to be updated (like the improved XDG
support) then fail badly.
Thus, remind users to check whether the right executable is present.
At least on Arch, none of the listed packages necessarily require that
the user has a working Xorg setup—this has already caused some confusion
for people. In particular, xmessage is very much needed in order to
show warnings and compilation errors.
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…
Many of these are legitimate, like the one in rescreen where it really
can be empty and xmonad might crash. Or the one in Main, where using an
irrefutable pattern means a pattern-match failure isn't reported using
the MonadFail instance of IO, but is left to crash later when the thunk
is evaluated.
Others are just GHC not knowing it won't crash, and we can use
Data.List.NonEmpty to tell it.
While we catch the exception that `getWindowAttributes` can throw in
`setWindowBorderWithFallback`, we immediately turn around and print the
error to stderr. Since this exception is raised every time a window is
closed[1] , it clutters stderr and may even confuse users as to why
xmonad is throwing these exceptions.
[1]: Depending on how the window is closed, we either have no way of
running `windows` on our own (say, the window is closed by a keybinding
of the program itself), or the focus change (and thus the call to
`windows`) runs before we can handle the DestroyWindowEvent.
