Separate some plugins from themes

[JanPokorny]

Some plugins (like ssh, z, or aliases) are controlled by the theme file, but have nothing to do with theming. Current state of themes makes no sense in this regard, eg. agnoster enables ssh and z, but agnoster-alternate doesn't. I believe that the on/off switches for these plugins should be in the config, independent of the theme file.

[chawyehsu]

Those bundled themes are for basic usage. If you want to config plugins for a theme, you can make a copy of the theme to ~/.config/pshazz/themes/ then edit it by yourself.

[JanPokorny]

I understand that. I just don't see the logic in including this behavior in the theme file. It took me some time to understand why "z" worked on one theme and didn't on other. In my opinion, behavioral plug-ins (z, ssh etc.) should be configured separately from theme plugins (git, hg...). It is more intuitive, and allows for easier theme changing -- at this point, if I want to use a cool new theme I find on the internet, I would need to copy parts of config from the old one.

[chawyehsu]

Hm, I get your point. You want plugins to be independent of themes, but the problem is some themes depends on some plugins. For instance, one has designed a theme which requires ssh plugin. And if the plugins part is independent, then other users cannot use the theme out of the box. They have to look into the theme and find out which plugin should be enabled, and then enable it manually. Therefore, IMO, it's a matter of choice to separate plugin loading system from themes.

[JanPokorny]

Is that really an issue?

When I look into the plugins, I see some behavioral plugins that I can't see themes depending on, like aliases (they need some config, but it's behavior only), g, ssh, and z. (Can you give an example how would a theme depend on the ssh plugin?)

And some theme-related plugins that make no sense to be enabled separately -- dircolors (ok that one may make sense to be enabled separately, but the color definitions are still logically part of the theme), git, hg, resetcolor, svn, virtualenv -- they just expose new variables for themes or do some theme-related work.

These are two fundamentally different types of "plugins" we are talking about, the first providing functionality to the console user, the second providing functionality to the theme creator.

In my opinion, including the first group in the theme settings is confusing. I think that g, ssh, and z should be by default a part of the pshazz core, enabled by default, and just have an on/off switch in the settings. (Idk what to do with "aliases", I personally don't see the point when there is Set-Alias...)

[JanPokorny]

To add, a thing I really like about pshazz is the fish-like experience of "install, select theme, done". I was so happy to find it after tinkering with Oh-My-Posh, Posh-Git, ssh agent etc. for so long. I believe that this proposed change goes with the philosophy.

[chawyehsu]

Okay, it makes sense to have an independent plugin loading system in some way. But I think that's really not a good idea to integrate plugins into the core and enable them by default. It's no doubt that it will save you time when you want those ssh/g/z plugins.

Thinking about that when someone wants to change to the mircosoft theme for a vanilla environment, on the other side, it will take their time to switch those plugins off. Then if they want to change back to the fancy theme, they have to enable those plugins again. And you see that it does not satisfy "install, select theme, done". That's what I said the matter of choice.

But yeah, perhaps it needs a better way to deal with some high-frequency uses plugins, though actually many users don't face the problem because they often have their own theme with their own plugins, instead of those built-in themes.

[JanPokorny]

Maybe not integrate into core, but differentiate "theme plugins" and "behavior plugins"? You say that many users have their own themes -- for many other tools, "theme" is something user rarely changes, he usually chooses a ready-made theme file and then edits a configuration file to make it personalised. (See eg. the theme bobthefish for fish.) Behavior things aren't usually controlled by the theme engine at all, but I understand why they are here -- to make the full experience work out-of-the-box. I see no reason why would user want to disable those plugins other than freeing the associated command -- the user may not even know they are there. Being enabled by default saves you time if you want to use them and costs you zero time if you ignore them.

…

On Thu, May 23, 2019, 02:12 Chawye Hsu ***@***.***> wrote: Okay, it makes sense to have an independent plugin loading system in some way. But I think that's really not a good idea to integrate plugins into the core and enable them by default. It's no doubt that it will save you time when you want those ssh/g/z plugins. Thinking about that when someone wants to change to the mircosoft theme for a vanilla environment, on the other side, it will take their time to switch those plugins off. And you see that it does not satisfy "install, select theme, done". That's what I said the matter of choice. But yeah, perhaps it needs a better way to deal with some high-frequency uses plugins, though actually many users don't face the problem because they often have their own theme with their own plugins, instead of those built-in themes. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#97?email_source=notifications&email_token=ABC6FYUNMXXHV2ZSZDITHXDPWV5IDA5CNFSM4HOU2RG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV7WU3A#issuecomment-494889580>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABC6FYRHF7HFM556OETKMFLPWV5IDANCNFSM4HOU2RGQ> .