* 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.
Benedict Lee
Pablo Santiago Blum de Aguiar
Itzik Ephraim
Stephen M. Coakley
Derek Stavis
Denis Koltsov
Bruno Pinto
Derek Stavis
Jorge Bucaran
Harrison Heck
Justin Hileman