Subject: Re: backward-kill-shell-word widget
From: Daniel Shahaf <[email-masked]>
To: Sebastian Gniazdowski <[email-masked]>
Cc: Zsh hackers list <[email-masked]>
Date: Thu, 14 Jan 2016 00:13:41 +0000
List-Id: Zsh Workers List <zsh-workers.zsh.org>

Sebastian Gniazdowski wrote on Wed, Jan 13, 2016 at 09:38:54 +0100:
> I saw this different, as an occasion to somewhat introduce Github
> community to original Zsh mainstream.

I think the opposite is true too: I think some users don't appreciate
that "zsh" and "oh-my-zsh" are not the same thing.  (I.e., think the
choice is between bash and oh-my-zsh.)

Perhaps that has something to do with the fact that the zsh default
setup is rather minimal: no cwd in PS1, no history tracking, etc..
(Actually, with StartupFiles/zshrc, I can't get even «rsync --<TAB>» to
work, even though it calls compinit.)

And features like the _match completer aren't easily discoverable...
even if $framework sets them, that wouldn't have the user know he can
«rsync --*links<TAB>».

> I think there's a crack between
> that mainstream and the community, e.g. OMZ. Maybe I'm wrong as
> zsh-syntax-highlighting was successfully introduced to Zsh-users on
> Github.
> 
> If one could easily see a generated text document that
> would enumerate which options, zstyles, aliases, etc. a plugin sets or
> creates, then it would be possible to still own the system despite
> dropping naive (or innocent:) plugins into it.

So one of the things a "plugin infrastructure" could do is standardise
a documentation format, so if you had N plugins installed, each plugin
could register the styles and parameters it cares about, and then you
could look them up, or enumerate them, in a unified way.

Vim has something similar: the ':help' command indexes the core's
documentation, all plugins' documentations, and a list of
locally-installed plugins (:h local-additions).

> That said I accept OMZ, zgen, antigen

Another one is prezto.  

Cheers,

Daniel