zsh-workers
 help / color / mirror / code / Atom feed
From: dana <dana@dana.is>
To: Sebastian Gniazdowski <sgniazdowski@gmail.com>
Cc: Daniel Shahaf <d.s@daniel.shahaf.name>,
	Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Official plugin manager?
Date: Thu, 2 Jan 2020 15:30:40 -0600	[thread overview]
Message-ID: <0C0C9775-59EE-4FBB-AB84-3E7FEF6E5024@dana.is> (raw)
In-Reply-To: <CAKc7PVCqRLFdN-1RBnmkZWcJ7JnyfyE5i5zpVFsD28DUF=5k=Q@mail.gmail.com>

On 2 Jan 2020, at 05:37, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> Okay. I think that the one interesting point was the 3rd one. I think
> that it harms Zshell's picture out there by making the following
> thinking common: that you cannot use Zsh without loading a bloated
> framework like Oh My Zsh.

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.

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*. The existence of OMZ does not prevent
this. OMZ itself can be used to manage settings like that. The only thing that
would be different about a first-party plug-in manager is that you wouldn't
have to install it first. Beyond that, for *managing plug-ins*, it makes very
little difference.

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 on dev.to or whatever, and OMZ fulfills that
desire by unconditionally modifying the shell's configuration to enable
whatever its developers consider desirable functionality. I assume that's what
you meant when you said that OMZ is 'bloated'. It *is* bloated, but that's
exactly the selling point. 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.

When i first started using zsh, i had the same experience with the new-user
wizard that Roman did, and it's my impression that that's not uncommon. It's a
good idea in theory, but I think the success of projects like OMZ and fish
shows that most users now don't really want the degree of control that it
provides. 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.

dana


  parent reply	other threads:[~2020-01-02 21:29 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-02  3:17 Sebastian Gniazdowski
2020-01-02  4:28 ` Eric Cook
2020-01-02 11:03 ` Daniel Shahaf
2020-01-02 11:37   ` Sebastian Gniazdowski
2020-01-02 11:55     ` Sebastian Gniazdowski
2020-01-02 21:30     ` dana [this message]
2020-01-03  0:25       ` Sebastian Gniazdowski
2020-01-03  1:36         ` dana
2020-01-03  2:43           ` Sebastian Gniazdowski
2020-01-03  2:45           ` Bart Schaefer
2020-01-03  3:26             ` dana
2020-01-03  5:13               ` Sebastian Gniazdowski
2020-01-03 15:00               ` Peter Stephenson
2020-01-03 20:48                 ` Daniel Shahaf
2020-01-03 21:51                   ` Roman Perepelitsa
2020-01-03 22:06                     ` Daniel Shahaf
2020-01-03 22:26                       ` Bart Schaefer
2020-01-03 22:37                       ` Roman Perepelitsa
2020-01-04  0:42                         ` dana
2020-01-04  1:06                           ` Daniel Shahaf
2020-01-04 15:46                           ` Roman Perepelitsa
2020-01-04 16:27                             ` Daniel Shahaf
2020-01-04 16:41                               ` Roman Perepelitsa
2020-01-04 17:35                                 ` Daniel Shahaf
2020-01-04 17:42                                   ` Roman Perepelitsa
2020-01-04 17:11                             ` Bart Schaefer
2020-01-05 10:40                               ` Oliver Kiddle
2020-01-06 17:47                   ` Leah Neukirchen
2020-01-03 11:15             ` Oliver Kiddle
2020-01-04  5:16               ` Sebastian Gniazdowski
2020-01-04  6:00                 ` Sebastian Gniazdowski
2020-01-02 12:00   ` Roman Perepelitsa
2020-01-02 12:21     ` Sebastian Gniazdowski
2020-01-02 12:27       ` Roman Perepelitsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0C0C9775-59EE-4FBB-AB84-3E7FEF6E5024@dana.is \
    --to=dana@dana.is \
    --cc=d.s@daniel.shahaf.name \
    --cc=sgniazdowski@gmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).