zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@ifh.de>
To: zsh-workers@sunsite.auc.dk (Zsh hackers list)
Subject: CVS
Date: Wed, 08 Sep 1999 11:00:43 +0200	[thread overview]
Message-ID: <199909080900.LAA08747@paris.ifh.de> (raw)
In-Reply-To: ""Bart Schaefer""'s message of "Tue, 07 Sep 1999 16:29:27 -0000." <990907162927.ZM32134@candle.brasslantern.com>

"Bart Schaefer" wrote:
> It is true that adding and removing directories is not the cleanest part
> of CVS, so it would be good to establish some file-structure guidelines
> before we deploy an "official" CVS server.  Just how great the fun will
> be depends on the write-access policy we choose; what were your thoughts?

We shouldn't any more need to add directories unless they going to
hold distinct sets of completions for a particular command set.  I
don't believe it's worth deciding for an individual completion file
whether the command or suite of commands it supports is present or not
--- we could provide an extra script for pruning the installed
functions, if anyone wants to write one --- and hence I don't think
directories like Gnu etc. are particularly useful.  In fact, I can't
currently think of a good example of an extra subdirectory that's
necessary; if the Debian and Linux directories stay fairly empty, I
may put the commands back in User.

To summarise,
- choosing the set of completions appropriate to a local environment
  is more to do with individual mix-and-match on commands than an
  operation en bloc;
- where blocks of commands are concerned, we are now in any case more
  able to provide support in a single file, making new directories
  irrelevant;
- consequently, having extra directories for external commands doesn't
  do the only thing it usefully could do, i.e. help the user with
  organisation.

One thing that might help users through the minefield is a way of
showing what completion will actually be executed in a given context.
To begin with, just being able to find that out for a given command
would be useful.

As far as organizing a CVS archive goes, we could arrange it so that,
for example, Sven made changes to the completion code, and I did it
for the rest, or Bart did in the case of my absence or total
incapacity due to huge volume of patches.  Changes wouldn't appear in
the archive until after they'd been seen on the list --- though at the
present rate of change, how much after is difficult to judge.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56100 Pisa, Italy


  reply	other threads:[~1999-09-08  9:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-06 10:19 3.1.6-pws-3 Peter Stephenson
1999-09-06 11:18 ` 3.1.6-pws-3 Andrej Borsenkow
1999-09-07 16:29 ` 3.1.6-pws-3 Bart Schaefer
1999-09-08  9:00   ` Peter Stephenson [this message]
1999-09-08 10:40     ` CVS (slightly off-topic) Adam Spiers
1999-09-08 13:44       ` Ollivier Robert
1999-09-08 17:26         ` Bart Schaefer
1999-09-08 20:03           ` BK & " Wayne Davison
1999-09-08 22:30             ` Bart Schaefer
1999-09-09  0:01               ` Wayne Davison
1999-09-09  7:44             ` Ollivier Robert
1999-09-09 19:01               ` Wayne Davison
1999-09-16 15:46       ` Adam Spiers
1999-09-18  7:04         ` Bart Schaefer
1999-11-19 11:49 CVS Oliver Kiddle
1999-11-19 16:58 ` CVS Adam Spiers
2000-04-18  7:15 CVS Sven Wischnowsky
     [not found] <44CE36D4-9044-4148-BDCE-636D85AC003B@cl.cam.ac.uk>
     [not found] ` <AANLkTi==AFonoqW8xjRMtzROxsNdPNx4e8k=7Wt8zXUd@mail.gmail.com>
     [not found]   ` <110127195309.ZM4952@torch.brasslantern.com>
     [not found]     ` <20110128221724.2f1753ba@pws-pc.ntlworld.com>
2011-01-29 23:18       ` Absolute pathnames similar to expand-cmd-path Peter Stephenson
2011-01-30  5:48         ` Bart Schaefer
2011-01-30 18:37           ` CVS Peter Stephenson

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=199909080900.LAA08747@paris.ifh.de \
    --to=pws@ifh.de \
    --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).