From: Bruce Stephens <B.Stephens@isode.com>
To: zsh-workers@sunsite.auc.dk
Subject: Re: Out of the box user experience
Date: 16 Mar 1999 14:24:43 +0000 [thread overview]
Message-ID: <vbn21d4ims.fsf@snake.isode.com> (raw)
In-Reply-To: Peter Stephenson's message of "Tue, 16 Mar 1999 14:37:33 +0100"
Peter Stephenson <pws@ibmth.df.unipi.it> writes:
> Bruce Stephens wrote:
> > How about sticking them in $prefix/lib/zsh/ (in suitable
> > subdirectories---maybe version-specific?), and adding a shell-set
> > parameter, ZSH_SCRIPTS or ZSH_LIB or something, so it's easy to
> > find them.
>
> This will probably happen (if someone does it). The last thing I
> though of was two configure options, --completion-lib for where to
> install it and --completion-install=core,base,builtins,all (with a
> cumulative effect) to specify what to install.
What about Functions, Misc (and StartupFiles, for that matter)?
Specifically, what does RedHat do when they build a binary package of
zsh? (I really ought to look, I suppose!)
I'm guessing they regard the example functions and things as
documentation, and install it into /usr/doc/zsh-$ZSH_VERSION.
Why not install the whole lot in subdirectories of
$prefix/lib/zsh/3.1.6? Actually, I suppose that looks ugly, since the
modules get stuck there. Maybe the modules could go into a
subdirectory too?
I suppose the scripts really ought to go into
$prefix/share/zsh/$ZSH_VERSION/*. That would be a better division.
So the modules stay where they are, and the scripts (including
completion) get stuck in share somewhere.
I'd prefer to have them installed automatically. I don't see the need
for optional installation of these scripts.
> The zshcompwid manual is probably not finished yet, since there are
> a few bits still in the pipeline. I was intending to tidy it up
> when it was.
OK.
> Then there may be a separate manual for the standard functions. Any
> existing non-completion-widget documentation is probably unlikely to
> change much unless changed forcibly.
OK. As far as I remember, the last time I read the manual I didn't
notice anything wrong (other than features I hadn't noticed before,
and the general overwhelming complexity of it).
So I probably shouldn't spend time on checking the documentation. If
I feel the urge, I may have a go at writing some new documentation
instead.
next prev parent reply other threads:[~1999-03-16 14:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-03-16 13:31 Bruce Stephens
1999-03-16 13:37 ` Peter Stephenson
1999-03-16 14:24 ` Bruce Stephens [this message]
1999-03-16 16:08 ` Bart Schaefer
1999-03-16 16:26 ` Bruce Stephens
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=vbn21d4ims.fsf@snake.isode.com \
--to=b.stephens@isode.com \
--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).