zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: dana <dana@dana.is>,
	Sebastian Gniazdowski <sgniazdowski@gmail.com>,
	Daniel Shahaf <d.s@daniel.shahaf.name>,
	Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Official plugin manager?
Date: Fri, 03 Jan 2020 12:15:23 +0100	[thread overview]
Message-ID: <7379-1578050123.754942@oZAF._NjJ.PSyK> (raw)
In-Reply-To: <CAH+w=7YqyRmVvknW9DMMi_q6ik7oOYQ6BP-3aOHD8PZv1=tnSg@mail.gmail.com>

Bart wrote:
> It has been our long-standing practice to recommend that package
> builders/installers do NOT create /etc/z* files, or make them minimal,
> so as not to interfere with users own initialization files.  Maybe
> it's time to relax that, or at least to provide a suggested skeleton

A packaged system-wide zshrc is not the same thing as a skeleton zshrc.
The recommendation should stand for the former. A skeleton zshrc,
meaning a file that is copied from, e.g. /etc/skel/.zshrc to a new
user's home directory by useradd is not something I'd
discourage. 

> zshrc -- which we could connect to zsh-newuser-install to be slurped
> in without having to go through all the questions if you just want to
> "feel lucky".

I've never been especially fond of the newuser feature but that's
mainly because of the periodic irritation of having to read how to
quit it when using a blank account. If it discourages distributions
from including skeleton files, then that isn't great. Perhaps it
could just print a helpful message, autoload functions for invoking
things like setup widgets and prompt theme selectors, do some minimal
setup like enabling completion and then give you an actual prompt.

For a setup widget, using zcurses and colour for something more visual
and interactive might be more approachable. But I wouldn't want that
invoked automatically.

> I've been noodling with a default completion setup module for a while
> (though haven't worked on it in months) and we could certainly do a
> better job of exposing the prompt theme system since pretty prompts
> apparently are what many people go looking at OMZ to find.

We might also want to reconsider the actual themes. They all predate
vcs_info and unicode. Meddling with PROMPT_CR and PROMPT_SP seems
unhelpful while the state of TRANSIENT_RPROMPT is sooner an aspect of
the actual prompt. The prompts do some nice things that are not obvious
to a casual observer, e.g. getting signal names from the return status
(clint/zefram) and the conditional newline (oliver). What's popular
in the OMZ world is whatever looks cool even if you have to install
modified fonts to make them work.

As for an official plugin manager, I think the idea has merits. I
brought the idea up in users/22179 but there was little enthusiasm
then. And I had different problems in mind than those outlined by
Sebastian: for all its popularity and multitudes of "contributors",
OMZ has a quality problem. Contributions are largely forgotten once
accepted because ownership is transferred. They don't make good use of
autoloading, possibly run compinit more than once with changed $fpath
and don't seem to encourage the use of things like add-zsh-hook. The
plugin standard and documentation of it determines those things.

Oliver

  parent reply	other threads:[~2020-01-03 11:16 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
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 [this message]
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=7379-1578050123.754942@oZAF._NjJ.PSyK \
    --to=okiddle@yahoo.co.uk \
    --cc=d.s@daniel.shahaf.name \
    --cc=dana@dana.is \
    --cc=schaefer@brasslantern.com \
    --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).