ZPlugin

ZPlugin

[Sebastian Gniazdowski]

Hello
Decided to change the topic and start a new thread, because I don't
think that ZPlugin will be "mainstream" in any near future. Too long
code, too sophisticated, requiring resistance to KSH_ARRAYS and other
things. After a half year of development who knows, maybe it'll become
a plugin manager of official Zsh choice. Am I not too pessimistic? Or
optimistic.

That said it can be developed for a half year or a year, with
mainstream eyes looking at the code, any objections being taken into
account, to avoid OMZ situation where too much is happening in a black
box of Advanced Bash Scripting Guide shell code.

I just added initial support for reporting of what functions a plugin
creates, written in one hour:

http://asciinema.org/a/bnwoqgs96l1q7s8wjad1o70z8

Would gladly welcome any participation in the development, any
objections and criticism. After some iterations of the function-diff
support, I'll move to recognize any existing advanced plugin
frameworks, like Zplug https://github.com/b4b4r07/zplug

Best regards,
Sebastian Gniazdowski

Re: ZPlugin

[Paul Johnson]

On Mon, Jan 25, 2016 at 09:57:49AM +0100, Sebastian Gniazdowski wrote:
> Hello
> Decided to change the topic and start a new thread, because I don't
> think that ZPlugin will be "mainstream" in any near future. Too long
> code, too sophisticated, requiring resistance to KSH_ARRAYS and other
> things. After a half year of development who knows, maybe it'll become
> a plugin manager of official Zsh choice. Am I not too pessimistic? Or
> optimistic.
> 
> That said it can be developed for a half year or a year, with
> mainstream eyes looking at the code, any objections being taken into
> account, to avoid OMZ situation where too much is happening in a black
> box of Advanced Bash Scripting Guide shell code.
> 
> I just added initial support for reporting of what functions a plugin
> creates, written in one hour:
> 
> http://asciinema.org/a/bnwoqgs96l1q7s8wjad1o70z8
> 
> Would gladly welcome any participation in the development, any
> objections and criticism. After some iterations of the function-diff
> support, I'll move to recognize any existing advanced plugin
> frameworks, like Zplug https://github.com/b4b4r07/zplug

Just an observation from the peanut gallery: as I understand it you have
created a more elegant solution to the core of a plugin system.  Would
it, therefore, make any sense, rather than building your own plugin
system from scratch, to fit your solution into an existing plugin
system, such as Zplug?

Are there sound technical reasons not to do so, or are you enjoying
building your own and want to continue with it?

-- 
Paul Johnson - paul@pjcj.net
http://www.pjcj.net

Re: ZPlugin

[Sebastian Gniazdowski]

On 25 January 2016 at 11:36, Paul Johnson <paul@pjcj.net> wrote:
> Just an observation from the peanut gallery: as I understand it you have
> created a more elegant solution to the core of a plugin system.  Would
> it, therefore, make any sense, rather than building your own plugin
> system from scratch, to fit your solution into an existing plugin
> system, such as Zplug?

I'm using existing "plugin system". Tested 20 plugins and all loaded
correctly. I think there is a problem with perceiving the existing
tools as an sophisticated advanced technology. In reality, it's
fpath+= to the plugin's dir and not much more. This is innovative, but
for sure it isn't a tragedy to just ignore what already exists. Zplug
has some additional functionality that I want to recognize today,
maybe that's a different case.

> Are there sound technical reasons not to do so, or are you enjoying
> building your own and want to continue with it?

Well ZPlugin is designed from scratch to reveal as much as possible
from plugins internals at time of loading it. It's hard to add this to
existing projects.

Best regards,
Sebastian Gniazdowski

Re: ZPlugin

[Sebastian Gniazdowski]

On 25 January 2016 at 12:05, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> Well ZPlugin is designed from scratch to reveal as much as possible
> from plugins internals at time of loading it. It's hard to add this to
> existing projects.

PS. There is one other reason. ZPlugin aims to have fpath clean.
Using fpath will be probably still needed for plugins that have
completions (not having much insight into this yet), however despite
this it doesn't flood fpath with all the plugins. For example, after
loading 10 plugins with existing managers, fpath looks like this:

/Users/sgniazdowski/.zgen/psprint/zsh-cmd-architect-master
/Users/sgniazdowski/.zgen/psprint/zsh-editing-workbench-master
/Users/sgniazdowski/.zgen/psprint/zsh-navigation-tools-master
/Users/sgniazdowski/.zgen/horosgrisa/autoenv-master
/Users/sgniazdowski/.zgen/adolfoabegg/browse-commit-master
/Users/sgniazdowski/.zgen/arzzen/calc.plugin.zsh-master
/Users/sgniazdowski/.zgen/walesmd/caniuse.plugin.zsh-master
/Users/sgniazdowski/.zgen/mollifier/cd-gitroot-master
/Users/sgniazdowski/.zgen/MikeDacre/cdbk-master
/Users/sgniazdowski/.zgen/willghatch/zsh-cdr-master
/Users/sgniazdowski/github/zgen /usr/local/share/zsh/site-functions
/usr/share/zsh/site-functions /usr/share/zsh/5.0.8/functions

These are all prepended entries and I think for someone who wants to
be in control of his system this looks like quite of a mess.

Best regards,
Sebastian Gniazdowski