Re: Forgetting about compinit with manual alteration of _comps

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

On 10 February 2016 at 11:32, Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
> Another thought is designing a plugin interface designed around how
> zsh actually works, rather than bending over backwards to accomodate
> cargo culted code that barely works in the first place.

That's quite true, sadly. Most of the plugins are written very poorly.
One reason for Zplugin to exist, with the debugging functionalities
that are intended to quickly identify a junk plugin. Other thought is
that writing robust zsh code isn't that simple. Let's forget about
possibility of KSH_ARRAYS, which will break probably all plugins.
There are other robustness-demanding options like GLOB_SUBST, where
simple echo ${fg_bold[red]}"Hello"$reset_color will cause problems. I
would create a list of options that would be repeated loudly for green
Zsh programmers. Not that I knew all this myself always, only recently
I discovered that SH_GLOB disables parentheses at parse time. The
point is that flexibility of Zsh can be converted into quality control
tool. Let fresh programmers know just few options (KSH_ARRAYS,
GLOB_SUBST, SH_GLOB, POSIX_IDENTIFIERS, that's only four) and they
will write better code regardless of their will. Plus patterns, which
will allow to leave ABS scripting that utilizes sed, etc. Of course,
this results in {} being all over the place, around
${#every_identifier}, etc. But not quite, when one writes plugin he
can use setopt localoptions and configure zsh according to his needs.
Exposed code would have {} everywhere, resulting in whole
/usr/share/functions/* working with emulate sh.

Best regards,
Sebastian Gniazdowski