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.
This combinator forces XMonad to *not* set _NET_DESKTOP_VIEWPORT.
This information is picked up by polybar's xworkspaces module and used
to re-group the workspaces by monitor. I (and others) find this super
confusing, but polybar doesn't not seem open to addressing it.
https://github.com/polybar/polybar/issues/2603
Opting in to the old behavior of not managing this property is one way
to work around it instead.
...by introducing yet another special case. Unsurprisingly, this is
just a bandaid—the logic in this module is just wrong. It
purposefully (not introduced with this change) computes the wrong
positions for certain extreme points such that splitVertically (which
simply goes down the list of stack windows _in order_) still works.
What we should do instead is to either
- keep track of windows that want to change their size and compute a
rectangle for them first, or
- immediately when handling the resize message, compute *all* of the
new sizes immediately (instead of only for the window getting
resized).
The latter would force us to keep track of the size of the current stack
we operate in, but since 'handleMessage' lives in X this should not pose
a big problem. I reckon this is the better approach.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/788
I have no idea what I was thinking when I wrote that code.
While at it, just reused the code for ICCCM title which already
assumes the client may have broken the rules (I think we have
seen a case of `WM_NAME` being `UTF8_STRING`).
When XMonad was recently restarted, it can happen that the workspace
history is empty, hence the last focused window could actually be the
currently focused one. In that case, we don't want to go through the
machinery of looking to hide any NSPs, as there is only one window in
the current workspace (the focused one). This may or may not be a
scratchpad, we don't care.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/779
Starting with time-1.10, the iso8601DateFormat function was deprecated
in favour of more sophisticated methods for showing ISO 8601 date
formats—as such, follow the libraries lead.
Sadly, the new functionality was only introduced in time-1.9, meaning
GHC 8.8 and up. Since we still support 8.6, the introduction of some
CPP is necessary.
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.
This is (i) much simpler to use and (ii) helps us with refiling. Emacs
will ignore todo keywords _that it knows_ when refiling, but when
started in batch-mode it doesn't know a whole lot. One would need to
thread the `todoKeywords' through to `refile' and then set
`org-todo-keywords' or a similar variable, which does not sound like a
good experience. Hence, falling back to showing the todo keyword to the
user when deciding upon a headline sounds acceptable.
This ensures that we always immediately expand the file path upon
constructing an `OrgMode' record. We thus do not have to do this in
`mkOrgPrompt' anymore.
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.
Users may not see the warning that insertPosition definitely needs to be
inserted at the leftmost position, which can cause undesired behaviour.
Having a combinator that handles this automatically seems like a sane
idea.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/709
(Note that `docs` wasn't changed since it already inserts itself
rightmost.)
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.
Most of these definitions are probably small enough to be inlined on
their own, but tell GHC to try really hard regardless. This is commonly
done by other parser libraries as well; e.g., [1], so it shouldn't cause
any issues either way.
[1]: https://hackage.haskell.org/package/parsers-0.12.11
