zsh-workers
 help / color / mirror / code / Atom feed
From: Adam Spiers <adam@thelonious.new.ox.ac.uk>
To: zsh workers mailing list <zsh-workers@sunsite.auc.dk>
Subject: Re: PATCH: prompt fun
Date: Tue, 5 Oct 1999 00:36:59 +0100	[thread overview]
Message-ID: <19991005003659.B19603@thelonious.new.ox.ac.uk> (raw)
In-Reply-To: <991004231403.ZM3580@candle.brasslantern.com>

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> On Oct 4,  7:40pm, Adam Spiers wrote:
> > Subject: PATCH: prompt fun
> > Here's a more light-hearted addition, which I've finally got round to
> > turning into a releasable form -- themeable prompts.
> 
> This is cool, but it's the kind of thing that makes me repeat my suggestion
> that things like this (and most of the more esoteric bits of the completion
> system) should be packaged and supported separately from the shell itself.

Yes, I've been thinking about these issues myself, although I always
tend to come down on the side in favour of packaging it all together.
I really like the idea of one `super-shell' which has all the good
stuff bundled with it.  Why?  Hmm.  I suppose because:

  - separate packages for one shell is quite fiddly and very likely to
    put people off (I've had enormous problems persuading highly
    intelligent, open-minded friends that even changing /from/ /tcsh/
    is worth the hassle), and so it seems important that the install
    path is made as smooth as possible.

  - zsh's main characteristic, for me, is that it's jam-packed with
    loads of great extra features.  I suspect that many people view it
    in that light, and download it because they want all those extras,
    rather than because they want a standard UNIX shell with a
    slightly different flavour.  Hence, it seems rather perverse to
    download and install zsh and then have to download and install
    other packages before you have all the bonus goodies.  [As an
    aside along the same argument, it seems a shame that most of zsh's
    bells and whistles aren't enabled by default, but I suppose there
    are strong backwards compatability arguments for this, and that
    individual distributions can enable them.  We've already seen this
    happening with the new completion system and Mandrake Linux, in
    fact.]

  - Improvements to (say) the new completion system very often go
    hand-in-hand with improvements/bugfixes to the C source, so
    splitting up this parallel development would probably cause more
    a lot more problems than it would solve.

  - zsh is hardly bloatware, and shows no danger of becoming even
    remotely close IMO.

However, there are obviously cons to the single package argument too,
which is probably shown up at its most absurd when k3wl_d0oD ANSI PS1
strings end up inside the main source tree.  I'm not sure what the
best answer is, but my instincts would say a compromise - include a
few nice prompts catering for a wide range of tastes, and then leave
the rest to the IRC kiddies (hmm, that's me I guess) to work on.  That
was the approach I tried to take with this prompt patch.

Thoughts?


  reply	other threads:[~1999-10-04 23:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-10-04 18:40 Adam Spiers
1999-10-04 23:14 ` Bart Schaefer
1999-10-04 23:36   ` Adam Spiers [this message]
1999-10-05  1:48     ` Mike Fletcher
1999-10-05 11:31 ` Zefram
1999-10-06 20:58   ` Adam Spiers
1999-10-07 10:43     ` Zefram
1999-10-07 13:29       ` bashprompt license (was Re: PATCH: prompt fun) Adam Spiers
1999-10-07 14:19         ` Bart Schaefer
1999-10-07 15:25           ` Oliver Kiddle
1999-10-07 16:45       ` PATCH: prompt fun Clint Adams
1999-10-07 16:49         ` Zefram
1999-10-07 17:03           ` Clint Adams
1999-10-07 17:06             ` Zefram
1999-10-11 13:19 ` Andrej Borsenkow
1999-10-11 16:39   ` Bart Schaefer
1999-10-11 21:30     ` Adam Spiers
1999-10-11 22:47       ` Bart Schaefer

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=19991005003659.B19603@thelonious.new.ox.ac.uk \
    --to=adam@thelonious.new.ox.ac.uk \
    --cc=adam@spiers.net \
    --cc=zsh-workers@sunsite.auc.dk \
    /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).