* init: rewrite init process
Now use pure globbing to generate 100% valid function and
completion paths, effectively splitting the init process in two
steps, one which paths are added, and other when initialization
is done (sourcing init).
This initialization code introduces a new interface for
`init.fish` hook, which deprecates the previously used event
model. The new interface injects three variables into `init.fish`:
path, package and bundle. This variables can be used by the
package to autoload paths, use bundled files, etc.
Also supports key bindings by sourcing
$OMF_CONFIG/key_bindings.fish and also key_bindings.fish in
packages (plugins and themes) root directories. This is done
when fish_user_key_bindings is called.
* omf: migrate to new init hook
* omf/templates: migrate to new init and uninstall hooks
* docs: document new init and uninstall hooks interface
* README: update new hook interface spec
Fixes#186 by removing the PATH save/restore code from init.fish.
There isn't a single occurence where Oh My Fish code changes the
value of PATH variable.
Plugin code which changes the PATH variable should be aware of
the side-effects and manage PATHs correctly, avoiding duplication.
This PR sets the default value of `OMF_CONFIG` variable in
framework init.fish file. The variable can still be overridden by
the user by setting it on `~/.config/fish/config.fish file`.
This is in preparation to rewriting install script in plain fish,
which will ditch config template and stop replacing `config.fish`
contents in favor of just appending Oh My Fish startup.
This variable records the value of $PATH environment variable before
oh-my-fish is sourced. When we "reload" the framework, we reset $PATH
with this recorded value so that we boot from a clean state.
Per conversation with @bpinto in Gitter.
There's no need for two separate directories. You don't have a `.git` and `.git-custom` folder, you just put your config in `.git` :)
The most straightforward interpretation of XDG basedir spec is that user configuration for omf would go in `~/.config/omf`, so let's put it there. The only question is whether omf-generated config (i.e. the `theme` file) should go there as well. By analogy with git, programmatically generated config should probably be merged in with user config. This also makes it so when a user clones their dotfiles to a new machine, both kinds of settings come with it.
