adjust to Windows better

[bbkane]

Now that I'm on windows more, I'm finding that I can't really assume the same folder locations and maybe other things.

Ideas:

• analyze apps in dotfiles for what symlinks I'd like on which platforms/hostnames/etc
• research whether anything like this exists in other dotfile managers
• try to turn that into a config file format I can use- maybe prototype the whole thing with a hardcoded python script so I can evolve relevant data structures
• add subsection to use this new format
• move current link/unlink functionality to subsection (breaking change)

Ideas:

Make a group of symlinks the basic unit of work and identity it by tags (name == nvim and auto filled in properties (hostname/os/???)

Have the user retrieve the units of work (symlimk groups) via boolean search query and then execute them

The issue is going to be setting defaults per platform per unit of work and how to structure that

[bbkane]

Ok, what if I:

• used https://github.com/google/starlark-go as the config format
• make each app have a directory (like now) and a starlark config at the top level
• that config gets sent variables like what platform we're running on and evaluated to a list of dirs to create and links to create
• that list gets checked against the filesystem for errors like pre-existing files at that path
• list gets printed, and, on confirm, links get made

[bbkane]

Then the subsections could be:

fling starlark link/unlink
fling tree link/unlink

[bbkane]

I could use something like what drone does:

https://docs.drone.io/pipeline/scripting/starlark/

My ctx object coul have fields like platform, hostname, user, tags that my starlark config could branch on

[bbkane]

Could also have one dimensional labels and a help(ctx) function that returns a string to be printed by fling

[bbkane]

I could also switch to https://github.com/SuperCuber/dotter . It uses TOML overwriting that doesn't look too crazy.