Re: Official plugin manager?

[Sebastian Gniazdowski <sgniazdowski@gmail.com>]

On Fri, 3 Jan 2020 at 02:34, dana <dana@dana.is> wrote:
>
> Is the problem you're trying to solve 'people don't know which plug-in manager
> to use' or 'people don't know how to configure zsh so they just install OMZ'?
> The one you're describing here is the former.

To be able to configure Zsh people need a p-m (to be able to use the
sourcables like @bindkeys, @history, etc. – that would be doing the
actual configuration). So it's not A vs. B, but A -> B, where A is
"people need a p-m / sourcables" and B is "people are able to
configure Zsh".

> Once they *have* a plug-in
> manager, they can install whatever they want, and they seem to want OMZ. (It's
> even the first example in the Antigen documentation...)

Well OK, however, there is the obstacle of having a choice. I think
that this is also promoting OMZ: "so many frameworks / p-m out there
and it's so difficult to choose? well, I better stick to 1500
contributors-backed Oh My Zsh".

> On 2 Jan 2020, at 18:25, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> > 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.
>
> You've responded to me saying 'instead of providing fine control over the
> profile set-up it could simply give them some good defaults' with 'OK, but
> first we need to add more complexity in order to provide finer control over
> the profile set-up'

Well yes, because I suspect that there will be a rough time on
establishing what the defaults are supposed to be. And also, the
sourcables are a new method of providing the snippets with the
defaults. With them, there could have been a few variants of each
plugin like @bindkeys, which would ease the problem of establishing
the defaults.

> Also, your example command is about 20 characters longer, and significantly
> harder to read or to transfer into a broader understanding of how the shell
> configuration works, than just setting it the normal way. How would this
> address the difficulty me and Roman described re: not understanding the
> implications of the wizard?

I thought about the @history / nodups.zsh to be something like:

HISTFILE=${file:-~/.zhistory}
HISTFILE=${~HISTFILE}
HISTSIZE=${size:-10000}
SAVEHIST=$HISTSIZE
setopt hist_ignore_dups
setopt inc_append_history hist_fcntl_lock

# Default-off options
setopt ${all+histi_gnore_all_dups}   ${find+hist_find_no_dups}
setopt ${space+hist_ignore_space}   ${copy+hist_save_by_copy}
setopt ${verify+hist_verify}   ${clobber+hist_allow_clobber}

# Default-on options
setopt ${nolex-hist_lex_words}  ${noblanks-histreduceblanks}

These are not all history options considered. So the loading of the
sourceable would have been:

zsh-pm pick=nodups.zsh @history
zsh-pm pick=nodups.zsh param'size -> 2000; file -> ~/.zhist' @history
zsh-pm pick=nodups.zsh param'copy; all; nolex' @history

And this would allow elastic providing of defaults with an additional
layer – the sourceable file. Normally the file contents would have to
be hardcoded into the newuser install script (plus the not exactly
solvable problem of the option modifiers). Here, only a few keywords
will have to be remembered in the installer and then the sourceable
could be freely edited.

The example sourceable script shows also how difficult will it be to
come up with the non-elastic default settings for history.

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