* split into buildenv deps and stack build
* make the deps list more git-friendly
* use stack from github environment (I've seen the curl fail intermittently)
* indent consistency
So far, when `alwaysHighlight' was enabled and the user selected an item
while not having completely written it out in the prompt, the input
string and not the eventual completion string would be entered into the
prompt history, which is obviously not the desired behaviour. This can
cause the history to clutter up with all these abbreviations, making
subsequent invocations of the prompt tedious to work with.
For example, an input of "xm" would narrow to both "xmonad" and
"xmobar", but thanks to `alwaysHighlight' "xmobar" was selected. If the
user now pressed enter, the prompt would correctly return "xmobar" as
the string to act upon, but "xm" would be entered into the prompt
history!
This is needed because the cache directory is now a part of XConf, which
is calculated once on startup and hence any recalculation would be
fragile.
Some internal functions that are not exposed (like writeHistory) were
also changed to accept that directory as an argument.
Fixes#164.
It's not clear to me why these functions take in XPState as a param only
to then produce some XP () values. It seems like they could just as well
call `get`.
In order to effectively restart status bars without relying
on pipes, spawnStatusBarAndRemember saves the PID of status
bars to kill them with cleanupStatusBars.
Removed checking for docks
Cleaned imports
Use signalProcesGroup instead of inverting the PID
Updated the documentation
Updated the documentation
Stop recommending pipes as the best/first thing to do and instead
recommend property based logging for all bars that support it. Also
strongly recommend users to use the already pre-made functions that do
all of the plumbing.
Add comments for the arguments of the most important user-facing
functions.
In an effort to modernize XMonad.Hooks.DynamicLog (and thus to stop
recommending pipes as the best way to interface with xmobar), implement
property log based solutions for the most important functions. Sadly
dzen does not seem to support this kind of interfacing with xmonad.
The descriptions of xmobar, statusBar, and statusBar' have been updated
to reflect that they should be seen as secondary choices.
This turns off the warnings about unused imports _unless_ one is using
the oldest supported version of GHC (right now that's 8.4.4 or older);
then it turns them into errors! This prevents xmonad from emitting
warnings about imports that have to be there due to backwards
compatibility, but are obsolete in newer versions (think MFP), while at
the same time preventing bitrot.
Starting with 5240116f3c we only support
GHC versions 8.4.4 and up (more precisely, the GHC version associated
with stackage lts-12 and up). The imports in question are now in
Prelude and need not be imported explicitly.
