zsh-workers
 help / color / mirror / code / Atom feed
From: dana <dana@dana.is>
To: Marlon <marlon.richert@gmail.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Rewrite of zsh-newuser-install (Mikael's subthread)
Date: Sat, 10 Apr 2021 15:46:57 -0500	[thread overview]
Message-ID: <A6A66D59-5043-46C1-B3AB-05279CB895E1@dana.is> (raw)
In-Reply-To: <15283D59-F7B5-4A4C-AFFA-B9D3BB46963F@gmail.com>

On 10 Apr 2021, at 06:23, Marlon <marlon.richert@gmail.com> wrote:
> I have heard many criticism against OMZ, but it being “too magical” is new
> to me. What exactly do you mean with that?

Isn't it the *primary* criticism of OMZ? Most of its users seem to have zero
understanding of what it does or what separates it from zsh itself.

***

Aside from being busy, i've kind of stepped back from this project because
i've started to have some anxiety about it myself. Although i still feel we
can't be *too* minimalistic with a default config, since nobody would use it,
the proposed changes have gone beyond the scope i'd initially envisioned. At
the same time, i don't know how to make an 'objective' case for why x change
is desirable but y change is excessive.

I will say that we talked about this a bit on IRC (which is what prompted
Mikael to respond) and it seemed like most of the people in that discussion
felt that the proposed configuration is too complex to be of much help with
the stated goal of demonstrating how new users can modify their own config. I
hope it's not too arrogant to say, but it feels like if i as a zsh developer
don't understand what a lot of the config does without looking it up, it's
going to be nearly indecipherable to a beginner.

That ties in with another concern i have, which is that once a user installs
this configuration, it's basically untouchable to us. We can't really patch it
after the fact if there's a problem with it. The more complex the config is,
the greater the risk that we'll have an issue like that.

Those two observations lead me to feel that, if we do go forward with this,
maybe implementing it with prompt styles and auto-loaded functions would be
the way to go after all. That would hide some of the more overwhelming aspects
of the config from end users, and it would allow us to patch bugs or otherwise
improve things after the fact.

I feel silly for bringing up fundamental 'architecture' questions so late in
the game but maybe that's something that we should come to a consensus on
before we finalise exactly what options/styles/whatever will be set.

dana



  reply	other threads:[~2021-04-10 20:47 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-05 19:44 Mikael Magnusson
2021-04-05 21:01 ` Mikael Magnusson
2021-04-05 21:44 ` Bart Schaefer
2021-04-07 13:44   ` Marlon
2021-04-07 16:24     ` Daniel Shahaf
2021-04-10 11:23       ` Marlon
2021-04-10 20:46         ` dana [this message]
2021-04-10 21:41           ` Bart Schaefer
2021-04-10 22:03             ` Roman Perepelitsa
2021-04-11 11:38               ` Marlon Richert
2021-04-13 14:49               ` Daniel Shahaf
2021-04-13 14:55           ` Daniel Shahaf
2021-04-07 14:28 ` Marlon
2021-04-07 15:14   ` Daniel Shahaf
2021-04-07 16:36   ` Bart Schaefer
2021-04-07 18:15   ` Mikael Magnusson
2021-04-07 18:50     ` Daniel Shahaf
2021-04-07 20:08     ` Arseny Maslennikov
2021-04-09 20:07     ` Marlon
2021-04-09 22:04       ` Oliver Kiddle
2021-04-09 23:04         ` Daniel Shahaf
2021-04-09 23:55           ` Bart Schaefer
2021-04-13 15:00             ` Daniel Shahaf
2021-04-09 23:08         ` Bart Schaefer
2021-04-10  7:44           ` Roman Perepelitsa
2021-04-09 23:23       ` Mikael Magnusson
2021-04-10  7:45         ` Marlon Richert
2021-04-09 15:29   ` Marlon

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=A6A66D59-5043-46C1-B3AB-05279CB895E1@dana.is \
    --to=dana@dana.is \
    --cc=marlon.richert@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).