As #115 migrated list functions, after updating Oh My Fish code
the omf.list_installed_packages gets removed, but is still being
used by the update code.
This commit fixes it by providing a wrapper function.
- 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
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.
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"`.
Stash is a shell script that does not support `--git-dir`, not even on
latest versions. We need to use `git -C` which was only added on recent
versions of `git`.
`omf update` will fail in case omf need needs to run `git stash` and
git is not compatible.
* On clean install, configure and download `default` theme.
* Do not allow `default` theme to be removed.
* When the current theme is removed, fallback to `default`.
Instead of clobbering the actions with both version and help, use
options instead. They are also going to be used for subcommands (e.g.
omf list --help) once they support options.
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.
The first time I saw `use`, I thought I could use the command for
everything, including packages, but it's only used for themes. So, it's
better to have a clearer name.
Derek Stavis
Bruno Pinto
nwykes
Derek Stavis
jeremiejig
Pablo Santiago Blum de Aguiar
Sheldon Els
Gabriel Marquez
Jorge Bucaran
Wes Morgan
Justin Hileman