zsh-workers
 help / color / mirror / code / Atom feed
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.


  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).