Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Completion system directories
- X-seq: zsh-workers 11108
- From: Oliver Kiddle <opk@xxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: Completion system directories
- Date: Wed, 03 May 2000 12:35:00 +0100
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <200005030914.LAA24343@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1000503103025.ZM21416@xxxxxxxxxxxxxxxxxxxxxxx>
Bart Schaefer wrote:
>
> On May 3, 11:14am, Sven Wischnowsky wrote:
> } Subject: Completion system directories
> }
> } Here is my suggestion for moving functions around.
>
> Structurally I think this looks fine. I'm occassionally alarmed that we
> need a hierarchy this deep, but the idea is that it condenses somewhat
> upon installation, right? E.g. it would lose the {Core,Zsh,...} layer.
It looks good to me. I'm quite happy with a deep hierarchy - I prefer it when directory listings don't scroll up endlessly.
> } - Bart didn't like `Core', right? Any suggestions?
> Right. Perhaps "Kernel"? "System"?
I prefer 'Core' to those as they might be wrongly associated with the UNIX kernel/system by anyone first seeing them. I would be more inclined to use 'Base' and then rename the directory which would have been 'Base' in Core.
> } - Should it be `Utilities' instead of `Utils'?
>
> Probably. Actually I think they should all be singular e.g. "Utility".
> (Cf. "Util" et al.; too bad about "Functions" and "StartupFiles" [*].)
I agree with Bart here. I'm not convinced by the idea of using capitalised first letters for all the directories. It looks especially strange with things like 'Bsd' and 'Aix'.
> } - There must be a better name than `Types', too...
>
> "Flavor"? "Class"?
Please not 'Flavor'. I think it is better to avoid any words which have different spellings in America and Britain if at all possible.
How about 'Entity'?
[ snipped a few more points where my answer would be 'I agree' ]
> } And finally: what is the easiest way to make these changes in the CVS
> } repository? Is there really no simpler way than using `cvs add' and
> } `cvs remove'?
It would be useful to be able to check out previous releases in the future so if the repository is going to be hacked then it would be better to try to leave things so that a 3.1.7 can be checked out in the future. Either by making the changes before 3.1.7 (the CVS doesn't go back to 3.1.6 does it?) or is it possible to just copy the RCS files (instead of mv) and clear out some of the tags from the copies so the old RCS files are still there but we have the history in the new ones. Of course it wouldn't be the first time if I'm talking complete crap about CVS so ignore me if I am.
While we're on the subject of cvs can people be a little careful with the ChangeLog - I've fixed it a couple of times when the merge has gone wrong. For an example, do:
cvs diff -r 1.183 -r 1.184 ChangeLog
An update before a commit might make it less likely?
> [*] On the subject of renaming, I've never liked "StartupFiles". It
> misleads people who don't read carefully into copying those files into
> /etc (I recognize parts of RedHat's distributed /etc/z* in our samples).
> And those samples still refer to zsh 2.7, which never even existed!!
> Those files should be touched up and the directory renamed (perhaps to
> "Samples").
I'm not convinced that the example startup files have much value anymore as they are quite out of date. I have added a section for startup files to the contributed part of the web pages and I think it would be better to point people to there if they want examples and to remove those in the distribution. This might also reduce the chances of people mistaking them for example global startup files (I'll add a note to the web page to clarify that they are example user startup files). If anyone wants to contribute their startup files, I'll add them. I've already linked to Adam's.
Oliver
Messages sorted by:
Reverse Date,
Date,
Thread,
Author