Oh My Fish compatibility caveats

[soraxas]

Sorry about the push and force-push to the PR's branch. I did not meant to add extra commits to the PR but merely forgot to switch to a different feature branch when I created the PR (which causes new commits shows up in the PR automatically). I was just modifying my fork to fix some of the breakages from the new fisher version (and didn't notice those affected the PR), and I did not mean to create any annoyance. I apologise for that.

One thing that I want to point out is that previously I've been using fisher to install omf plugins but with the new depreciation they no longer works (a lot of omf plugins and themes uses init.fish and top-level functions). So I think with your new depreciation, you should update your README.md fle

• ...
• Oh My Fish! plugin support.

of stating fisher is no longer compatible with oh my fish plugins. But overall thanks for the great work. Cheers.

[jorgebucaran]

Not all Oh My Fish plugins use init.fish, uninstall.fish, or top-level .fish files, but many do, so stating "Oh My Fish! plugin support (with caveats)" might be more accurate. 👍

The issue with .fish files in the directory root is that they are ambiguous. Should we assume that they are functions? Fish solves this elegantly: functions to functions/, configuration snippets to conf.d/, and completions to completions/.

Different directories for different types of Fish. The idea behind #651 was not to make Oh My Fish support worse but to make Fisher fishier. As the adage goes: there should be one and only one obvious way to do it. 😉

Oh My Fish plugin authors need just put their functions inside a functions directory, and rename any init.fish to conf.d/$plugin_name.fish. I realize that might not be happening any time soon (oh-my-fish#788), but we've really
gone out of our way to support Oh My Fish too much and it's time to move on.