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]: 3fc830aa09
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.
By being a bit less greedy with consuming whitespace in the date/time
parsers, we can make the `prop_{encode,decode}Preservation` properties
well-defined again.
Switch the underlying UnicodeData data type from the current ByteString
implementation to String. This is in order to facilitate descriptions
Unicode descriptions of the Unicode characters themselves. We chose
String instead of Text because it does not incur an extra dependency.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/733
Instead of providing these as default values, as originally planned,
just add a note for users who wish to customise that part of the prompt.
We simply get the user config in mkPassPrompt and so overriding that
with a custom searchPredicate and sorter seems unwise.
Closes: https://github.com/xmonad/xmonad-contrib/issues/746
