windows-env - Manage Windows environment variables

	Commit message (Collapse)	Author	Age
*	addpath: detect expandable paths	Egor Tensin	2017-06-13
\|
*	addpath: fix a sleep-deprived bug	Egor Tensin	2017-06-12
\| \| \| \| \| \| \| \| \| \| \| \| \| \|	Yeah, so last night I added a Show instance to WindowsEnv.Value (ex-WindowsEnv.VarValue), which would simply call valueString (ex-varValueString). Then I replaced every valueString/varValueString with show. Then I decided that this Show instance was a mistake, and derived an instance instead. It obviously messed up all the show VarValue/Value calls. The lesson to learn is you should remove an instance first, fix all the call sites, and only then derive it. The disgusting part is that a few of the last commits are actually broken, which I hate.
*	WindowsEnv: {VarName,VarValue} -> {Name,Value}	Egor Tensin	2017-06-11
\| \| \| \| \|	Also, fix compiler warnings (I've got too used to building with `--ghc-options -w`).
*	refactoring	Egor Tensin	2017-06-11
\|
*	refactoring	Egor Tensin	2017-06-11
\| \| \| \| \| \| \| \| \| \|	The fact whether the registry value was a regular or an expandable string is now propagated up to the `Environment` module (and even further to the apps). This was done to get rid of these weird `setString*` functions (and the like). I don't feel like I've came up with the right abstractions yet though, so there's more work on this to come.
*	addpath: refactoring	Egor Tensin	2017-06-10
\|
*	addpath: add --prepend option	Egor Tensin	2017-06-10
\|
*	rename directories	Egor Tensin	2017-03-26