Fisher: Add enable/disable commands and drop uninstall in favor of remove

[orangecms]

Some people do not expect fisher uninstall to actually just disable a plugin, and as a side-effect, they not only have their cache directory full of old / unwanted plugins, but they also see them in fisher l, which might be confusing. Actual deletion, i.e. fisher uninstall -f (--force), isn't well-documented.

I'd rather propose two new commands / one replacement:

• enable (e) to actually enable a plugin, like install currently does as well
• disable (d) as its counterpart instead of uninstall
• remove (r) instead of uninstall --force

As the latter two cover the current functionality of uninstall, it can be removed (plus we gain a shortcut for removal :) ).

Implementing this might as well clean up the code a bit as there is less branching involved.

[ghost]

No design can be perfect™. Your proposal liberates uninstall and splits it into two commands whose behavior may be more obvious to some users, but it also forces other users to remember new commands as well as us to document those commands.

Having said that, users are free to extend Fisherman in any way they like and creating these commands is easy.

function __fisher_remove -d "This description is shown in the fisherman cli help menu..."
    if contains -- -h $argv
         printf "fisher: fisher remove <plugin> ...\n\n"
         printf "....\n"
         return 1
    end

    fisher_uninstall $argv -- --force 
end

For a fuller template, use new:

fisher i new
fisher new command
❯ What's your plugin name? remove
❯ What's your plugin about? Bla bla blah
❯ What's your GitHub username? lemoncms
    ✓ Creating peach from plugin template
    .editorconfig
    .gitignore
    ....
    ....

When you are done, just submit it to the index :smile:

You can also add it to the Fishery if you like. I'll send you an invite.

[jethrokuan]

On the same note, perhaps the merits of keeping it in the cache should be discussed.

Pros:

1. Faster reinstalls

Cons:

1. Reinstalls installs from the cache, and does not install an updated copy of the plugin
2. Potentially confusing options

A different approach would be to list only "active" plugins during fisher list.

Looking at it from the bigger picture, I think the fact that plugins are cached should be hidden from the user, i.e. people shouldn't have to understand how Fisherman works to use Fisherman.

[orangecms]

A big plus on that. A fisher cache command or something like fisher purge could be used for cache maintenance.

[orangecms]

About remembering commands @bucaran: People are used to such commands from other tools, so it would just be intuitive/convenient imho. AAMOF, I was looking for such commands because I read that Fisherman supports enabling/diasabling plugins and I couldn't find them. Maybe they could be added for convenience nevertheless, while still keeping uninstall.

[jethrokuan]

It's unlikely that the CLI will undergo any major changes like this at this point in time. It was decided at 1.0 that the core API is decided and will not change. Changes may benefit new users, but this will also affect current users.

The user should technically not need to touch the cache at all. If a fisher cache or fisher purge command is needed, we're not doing something right.

fisher list already shows which plugins are active and which are not, but perhaps to the new user it is unclear what * and > refer to. Is there a better way to present this information?

[orangecms]

We just had that question in Slack, and I was also wondering about it first, that when you uninstall and then list, you still see what you thought was uninstalled. The disabled plugins could just be hidden then and * becomes unnecessary.

[orangecms]

The confusion is, after all, that uninstall only disables things, which you wouldn't expect. If you say that a list commands shows which plugins are enabled and which are not but there is no enable/disable commands, you have more cognitive load here actually where you wanted to reduce it.

[jethrokuan]

I agree that uninstall implies complete removal, and that disable may
be more appropriate here. How do we make the transition, if any, to the
new commands smooth?

This does not account for the fact that enable would not be appropriate
when things need to be downloaded, and I'm against having two separate
commands for installation.
On 27 Mar 2016 10:59 pm, "Daniel Maslowski" [email protected]
wrote:

The confusion is, after all, that uninstall only disables things, which
you wouldn't expect. If you say that a list commands shows which plugins
are enabled and which are not but there is no enable/disable commands, you
have more cognitive load here actually where you wanted to reduce it.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/fisherman/fisherman/issues/172#issuecomment-202081182

[ghost]

@orangecms What about simply _not_ displaying plugins that are disabled, but exist in the cache when doing fisher l?

[orangecms]

Yup, that's one idea we had in common.

[ghost]

@orangecms Currently fisher l shows you disabled plugins by simply _not_ adding a legend, and as you know, * is for enabled, > is for prompt and @ for link.

But fisher l supports --disabled anyway.

@jethrokuan What do you think?

[jethrokuan]

:+1: on hiding stuff in the cache during fisher list. And during installation, if installed from cache, it should show, just so they know it might need updating.

[ghost]

if installed from cache, it should show, just so they know it might need updating

This would be cumbersome as the use might be throw off by having that message constantly showing up, (like if you switch themes prompts a lot).

Instead, we need to consider adding an update-notifier feature, basically a simple check inside fisher.fish that should occur every n million of seconds or something.

[jethrokuan]

yeah the update notifier feature works as well.

[ylor]

To be honest, if the notifier works like oh-my-zsh's, I would uninstall Fisherman (and I _really_ like Fisherman) just as I did omz when it first occurred to me using that framework. Interrupting a user with what I think of as a 'pop-up' in the middle of whatever work they're doing. Especially since I've already done the work of staying updated by running a script that repeats every 24 hours.

Maybe only notify on shell login, and even then only if not updated in the last x period of time?

[herrbischoff]

Please don't add any kind of interrupting notification. I usually know what I am doing in the shell and don't need handholding by any tool except for possibly extremely destructive tasks.

Another example for annoying default settings is Prezto's rm alias that resolves to rm -i. This was driving me nuts. Users should update when they decide to update and should not be pushed. It should not be seen as the responsibility of any framework to notify its users of anything they did not explicitly enable. This is all stuff that gets _in_ the way instead of _out_ of it. Also, making this a configurable option would run contrary to fish's philosophy:

Every configuration option in a program is a place where the program is too stupid to figure out for itself what the user really wants, and should be considered a failure of both the program and the programmer who implemented it.

[ghost]

Thank you all for your input folks. I agree that people should decide when they want to update Fisherman, as opposed to get a notification that a new update is available.

Perhaps an update-notifier plugin could be created to get these sort of notifications.

Closing this in favor of #176.

[herrbischoff]

Perhaps an update-notifier plugin could be created to get these sort of notifications.

Sounds like the most sensible approach. This equals explicitly enabling said function.