Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

"Plugin architecture" demistified



Hello,
after working around various plugins I recognized the whole topic and
want to share.

1. "Plugin architecture" is empty

Here I added code that allows to directly source a plugin file:

https://github.com/psprint/zsh-navigation-tools/blob/04c9e968faa6f77499155e04734a0f3470738b0b/zsh-navigation-tools.plugin.zsh#L10-L21

It does exactly what plugin managers do: add to fpath, then follow to
execute the file. So, no plugin manager is needed for this. Just
source the file and that's it.

2. There is no big demand for plugins

I've tested 50 plugins from awesome-zsh-plugins site. 98% of them are
ABS code of poor quality and do not provide robustly covered use
cases. It's that fresh Zsh users write something for themselves, use
it with success, share, and don't cover edge cases and wider use
cases. This way it is hard to rely on the software. It's an actual
work to cover edge cases, from practice I know it requires months of
various activity. Writing a nice script requires hours.

This might change in the future, maybe a developer base will arise
from awesome-zsh-plugins and other associated things, and the code
will get better.

3. Epilogue

Seeing the mailing lists being quiet about the changes in Zsh world
made by plugin managers I was slightly puzzled. I wrote about users
"demanding" plugins. Explained the plugin architecture. Now I see it
was all correct that mlas were quiet, as there are no actual changes.
But it wasn't easy to become aware of that. The 1st conclusion, how
easy it is, however, it took me 9 months to establish it.

Best regards,
Sebastian Gniazdowski



Messages sorted by: Reverse Date, Date, Thread, Author