With [1] and now [2], NSP has a lot more functionality that used to be
confined to other modules. This is indicated in the TOC when viewing
the documentation, but it should perhaps be more prominently mentioned
in the introduction/usage docs.
[1]: https://github.com/xmonad/xmonad-contrib/pull/690
533e17135e953938834551558062566a73e1ae2c
[2]: https://github.com/xmonad/xmonad-contrib/pull/774
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
While not many of these more exotic combinators are used right now, it's
still nice to have feature parity (i.e., everything that one could want
from a basic parser) such that people don't have to add their own
combinators, in case they want to use one that's not already
implemented.
This was only used in three places throughout the module and is sort of
non-standard terminology, hence it might confuse users. Talking about
functions of type
XConfig Layout -> M.Map (ButtonMask, KeySym) (X ())
is relatively standard in other modules as well, so it's probably best
to remove the type alias for it.
The Usage section made reference to a non-existent
`namedScratchpadSpawnAction` function. It has been replaced with
`namedScratchpadAction` in accordance with the documented bindings
below.
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 is i) broken and ii) just the functionality of X.U.NamedScratchpad
rewrapped (and not necessarily improved upon) at this point.
With recent changes to the way named scratchpads work[1], we would have
to export internals of X.U.NamedScratchpad in order to restore
X.U.Scratchpad to its full functionality. This does not seem worth it,
as the latter does not bring anything substantially new to the table.
Closes: https://github.com/xmonad/xmonad-contrib/issues/756
Related: https://github.com/xmonad/xmonad-contrib/issues/591
[1]: 3fc830aa09368dca04df24bf7ec4ac817f2de479
In case a font could not be opened, simply fall back to "xft:monospace"
and open that. The initCoreFont and initUtf8Font functions already have
mechanisms like this, is was just missing from initXMF.
Closes: https://github.com/xmonad/xmonad-contrib/issues/723
+ $keyAddDel can just be a side note in $keyDel, it does not need its
own section.
+ $logHook is covered in more detail in the tutorial and does not serve
a real purpose anymore. One could rewrite it to be more in-depth
about the inner workings of X.H.StatusBar, but for the time removing
it seems like the best option.
Closes: https://github.com/xmonad/xmonad-contrib/issues/645
Nowadays, removing keys is mostly done via removeKeys and removeKeysP,
so the documentation should reflect that fact. This part is less
step-by-step instructive than the section about adding keys, but read in
succession it presents a way to deepen the newly acquired knowledge.
