Re: Official plugin manager?

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

On Thu, 2 Jan 2020 at 22:28, dana <dana@xxxxxxx> wrote:
> I agree that zsh provides an underwhelming out-of-box experience for novice
> users and that they are funnelled into OMZ in an attempt to address that. It'd
> be nice if that wasn't the case. I'm not necessarily opposed to an official
> plug-in manager, but i'm not sure it follows that creating one would solve
> this specific problem.

I cannot recall my first contact with Zsh as it was ~14 years ago,
however, when reconstructing I would say that I was pretty much
impressed by the hash table availability, about which I've read in
some pros and cons, Bash vs. Zsh article. I've couldn't believe how
can you have an "official Linux shell" (i.e.: Bash) without them. Then
I recall reading the description of *each* option and turning it
on/off in .zshrc. I'm still using the options, like octal_zeros, for
example, c_bases, numeric_glob_sort, complete_in_word,
no_glob_complete, and others. Noticing: the last one isn't active now
when I'm using menu select. Then I've probably searched the net
looking for how to make the keys like home, end work, found out the
$terminfo trick to notice that it's not working for all keys and then
hardcoding cat -v sequences.

So my experience was maybe a bit different, I was ready to get the
best shell imagined (because of the hash tables) by going close to the
detailed configuration from the start. But maybe others were like this
too and they are just recalling the literally first contact with Zsh.

> Lots of zsh plug-in managers already exist. Any one of them can be used by
> blog authors to 'share decent zshrcs which would also include the other needed
> setopts and zstyles, etc.' *right now*.

I think that this hits a wall of having a choice. "Hey, I just want a
*reasonable* p-m to get all the plugins, as that's what actually
matters, isn't it? Why do I have to decide on the p-m, if I'm going to
do this properly then I'll at least enter 'best zsh plugin manager' in
Google, and this means work, work, lost time and large impatience
intake. And then the slight discomfort of not diving into the topic
enough deep and deciding on a p-m mostly by its cool name - hey, am I
really using the p-m that I should?"

> The only thing that
> would be different about a first-party plug-in manager is that you wouldn't
> have to install it first.

Yes and I think that this is a significant factor in the first-contact
experience.

> Novice users don't use OMZ because they want to manage plug-ins. They use it
> because they want a command they can just run to get the fancy completion and
> prompts they see in screen-shots (...)
> Were we to provide a first-party plug-in manager,
> in the absence of other changes, it would simply be used to install OMZ, or
> something like it.

Ok, I can agree with this, although having a theme loaded by a single
line in zshrc does contribute very much to fulfilling the expectations
of new users that you've mentioned. As for the completion and other
things, like properly working home/end keys, the p-m could address
this by point 6. in the original post – by allowing sourcables, not
only autoloads. For example, Roman shares a decent bindkey setup:

https://www.reddit.com/r/zsh/comments/eblqvq/d/fb7337q/

Why not store this snippet into a plugin called 'bindkeys', which
would have been a subdirectory in
/usr/share/zsh/<VER>/plugins/bindkeys, in a file "translate.zsh" to
highlight the bindkey-s-translation property of the setup, to then
allow users loading it with:

zsh-pm pick=translate.zsh @bindkeys

?

> (...) that most users now don't really want the degree of control (...)
> They just want the cool stuff. If that's true, i feel like having
> the wizard simply offer to turn on that (pre-determined) cool stuff would be
> an easier and more effective way to cut into the OMZ use case than a plug-in
> manager.

OK, however, the sourcables-backend to zsh-newuser-install is IMO
needed first. Then the install function could offer to append:

zsh-pm pick=nodups.zsh param='size -> 10000' @history

to the zshrc.

PS. The zsh-pm is just a conservative quasi-idea of the possible name
of the function of the p-m.

PS2. To illustrate the benefits of sourcables I'm gonna again use
Roman's snippet, as it serves well for the possible bundled-plugin
example:

https://www.reddit.com/r/zsh/comments/dkjp27/bindkey_quest/f4glg6n

zsh-pm @meta-cd

OR

zsh-pm param='back -> ^B; forward -> ^F' @meta-cd

Basically, such a plugin would be one other way to spice-up the first
contact with Zsh, and it shows the benefits of sourcables-approach.

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org