These modules were duplicating a substantial amount of low-level code.
`X.A.CycleWorkspaceByScreen` had already separated most of the
implementation details from the logic with `repeatableAction`; all that
was left was to generalise it a little further, put it in a suitable
place and express the other modules through it.
Libraries like Control.Monad are no longer exported from
Control.Monad.Reader et.al.
Related: https://github.com/xmonad/xmonad/pull/427
xmonad/xmonad#d170e99bc5e97db96be9a02b72149103e8d419af
The links were broken due to:
1. Incorrect quotes (' instead of " for module links and occasionally
vice-versa).
2. Changes in the name of the "target" module not reflected in the
"source" docs.
3. Typos to begin with.
4. Use of `<foo>` in the docs is rendered as just `foo` with a link to
`/foo`.
5. Similarly for `"Foo"` if it starts with a capital letter (and hence
could be a module).
6. Markup inside `@` code blocks still being applied.
e.g. `@M-<arrow-keys>@` is rendered as `M-arrow-keys` with a spurious
hyperlink from arrow-keys to `/arrow-keys`, which is confusing.
Three links from XMonad.Util.Run have been removed outright, since
they're no longer examples of the usage of 'runProcessWithInput'.
WmiiActions has been gone since 2008, while XMonad.Prompt.Directory
and XMonad.Layout.WorkspaceDir haven't been using
'runProcessWithInput' since 2020 and 2012, respectively.
In some cases the `<foo>` were surrounded with @, especially in the
case of key definitions, for consistency. (This wasn't done
everywhere, because it looks ugly in the source.)
MoreManageHelpers has never been in xmonad-contrib. ManageHelpers
seems to fill the expected role.
In the case of the module description for X.H.ManageDebug the quotes
were simply removed because none of the likely options to make the
link work were successful.
Add sideNavigation as a fallback if needed. This should not have any
user-facing behaviour change when not using gaps or spacing, as line
navigation is preferred. However, users who do use spacing or gaps
should now potentially not have to change the default strategy in order
to have a usable module.
Essentially, whenever the tutorial actually has decent material on the
subject matter. The replacement is roughly done as follows:
- logHook → tutorial
- keybindings → tutorial, as this is thoroughly covered
- manageHook → tutorial + X.D.Extending, as the manageHook stuff the
tutorial talks about is a little bit of an afterthought.
- X.D.Extending (on its own) → tutorial + X.D.Extending
- layoutHook → tutorial + X.D.Extending, as the tutorial, while
talking about layouts, doesn't necessarily have a huge focus there.
- mouse bindings → leave this alone, as the tutorial does not at all
talk about them.
This may seem a bit self-indulgent, but both of these features are
either quite new or so old that no one remembers them anymore, so not a
lot of up-to-date content exists for them.
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
`WindowScreen` is a type synonym for the specialized `Screen` type, that
results from the `WindowSet` definition in XMonad.Core. Having this type
defined and exported in a central module saves extension developers from
trying to reconstruct it, whenever the general `Screen i l a sid sd` is
not suitable.
Note: this should be moved to `XMonad.Core` in the next core release.
This changes KeyPress handling in these modules to behave much closer to
how xmonad core itself handles keypresses. The primary difference lies
in that xmonad reads raw KeyCode and then converts it to unmodified
KeySym, while these modules used `lookupString` to find the actual
keysyms. As a consequence, key definitions like `(shiftMap, xK_Tab)`
didn't work on many layouts because an actual KeySym for `Shift-Tab` is
commonly `ISO_LEFT_TAB`, and not `Tab`.
Closes: https://github.com/xmonad/xmonad-contrib/pull/590
Co-authored-by: Tomas Janousek <tomi@nomi.cz>
This replaces the custom `cleanMask` extension in these modules—which
only filtered out XKB group bits and Button5Mask¹—with the new
`cleanKeyMask` which additionally filters out all mouse buttons, as
these aren't relevant for key bindings.
¹) Filtering out Button5Mask was probably an off-by-one mistake.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/290
Related: https://github.com/xmonad/xmonad-contrib/pull/590
We didn't clean XKB group bits out of the KeyPress events' state so key
bindings only worked in the primary keyboard layout (first XKB group).
To fix this, this adds a `cleanKeyMask` function to X.Prelude which is
analogous to `cleanMask` but aimed at cleaning regular KeyPress states
(as opposed to just KeyPresses from passive key grabs), and this is then
used instead of `cleanMask`.
Related: https://github.com/xmonad/xmonad-contrib/issues/290
Related: https://github.com/xmonad/xmonad-contrib/pull/590
Add a `visualSubmap` function, which works much like the regular
`submap` one, except that it visualises the available choices in a
pop-up window.
Related: https://github.com/xmonad/xmonad-contrib/issues/472
If the user's prompt configuration has a custom `searchPredicate` (e.g.,
`X.P.FuzzyMatch.fuzzyMatch`) the `withWorkspace` prompt should make use
of it (instead of defaulting to an `isPrefixOf`-style matching). For
details see
https://mail.haskell.org/pipermail/xmonad/2021-December/015491.html
This adds basic font-fallback support for X.U.Font, as well as modules
using it, like X.Prompt and X.A.TreeSelect.
In the new system, multiple fonts may be specified with the syntax
"xft:iosevka-11,FontAwesome-9"
Fixes: https://github.com/xmonad/xmonad-contrib/issues/208
updateHistory leaks unfiltered windows from previous states as it is never
forced. The consumer of such data structure is not visible to ghc, so the
demand analysis has to fallback on pure laziness.
We fix this inserting evaluation points on the `historyHook` function. We do
this for two reasons, this is the only function calling `updateHistory`.
Plus we cannot do it clearly at the `updateHistory` function as we operate
inside a continuation on withWindowSet. In respect to the `put`, everything
would be a big thunk.
Update left and right navigation to behave correctly even if the
currently saved position is directly on the edge of the focused window.
This makes the L/R behavior consistent with U/D navigation.
How to reproduce the issue on a 16:9 resolution like 1920x1080:
- configure Grid layout;
- open 4 terminals;
- navigate to the top-right terminal;
- open another terminal;
- immediately close it;
- try navigating left from the currently focused top-right terminal;
- observe navigation being "stuck".
The documentation for this module was lacking, making it significantly
harder to use than the functionality wise very similar
X.A.CycleRecentWS—change that.
Whenever possible, prefer the safe wrappers withWindowAttributes or
safeGetWindowAttributes to getWindowAttributes.
Places where these are not applicable are limited to layouts, where
there is not good "default value" to give back in case these calls fail.
In these cases, we let the exception handling of the layout mechanism
handle it and fall back to the Full layout.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/146
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>
