- Move theme installation to cli entry point (omf.fish)
- Generalize XDG_CONFIG_HOME code in `omf.xdg.config_home`
- Generalize prompt conflicts check in `omf.checks.fish_prompt`
* Migrate `omf.doctor` to use it
+ Change theme activation steps
- Create user function path if not existent
- Check for conflicts in fish_prompt, aborts if found
- Remove current theme from autoloading paths
- Add target theme to autoloading paths
- Link target theme's fish_prompt to user's
- Persist selected theme to $OMF_CONFIG/theme
This approach brings two major advantages:
- Theme prompt now shows accordingly in fish_config web interface
- Faster theme changes, reducing it from seconds to some milis
- Avoids calling refresh, which makes users much more happy
First works toward generalizing file backup code, applying to both
config.fish file and now fish_prompt.fish too. This avoids clean
installs which start with theme issues.
Instead of having every plugin function inside the same file, which
increases the loading time unnecessarily and is not fishy, source the
`uninstall.fish` file for the plugin before the `uninstall_$plugin_name`
event is emitted.
In order to pro-actively diagnose an issue on someone's computer, a
`omf doctor' command is being added. This command will initially check
errors that could cause a theme to not be loaded, but in the future more
checks are going to be added to prevent issues from being created for
problems that are fixable by the Oh My Fish user alone.
Fixes an issue with history between shell reloads via refresh function call.
As `exec` replaces the current process in a non-gently fashion, the
persistent history could be out of sync with the in-memory history.
Calling `history --save` before `exec` should force the shell to persist the
history before replacing the current process.
When calling `omf destroy`, the `bundle` file is completely erased
because we are calling `remove_package` on each installed package. We
don't want to erase that file, we just want to emit the event and later
on remove the code, which is done with `rm -rf "$OMF_PATH"`.
Travis does not provide the original repository branch name on any
environment variable. We are getting the information from the GitHub
API instead.
The misleading environment variable `TRAVIS_BRANCH` returns `master`
instead:
> TRAVIS_BRANCH: For builds not triggered by a pull request this is the
name of the branch currently being built; whereas for builds triggered
by a pull request this is the name of the branch targeted by the pull
request (in many cases this will be master).
Reference: http://docs.travis-ci.com/user/environment-variables/
Bruno
Pablo Santiago Blum de Aguiar
nwykes
Derek Stavis
Derek Stavis
Michael Ventura