From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8049 invoked from network); 16 Mar 2001 10:20:16 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 16 Mar 2001 10:20:16 -0000 Received: (qmail 19171 invoked by alias); 16 Mar 2001 10:20:07 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13649 Received: (qmail 19122 invoked from network); 16 Mar 2001 10:20:05 -0000 Date: Fri, 16 Mar 2001 11:20:02 +0100 (MET) Message-Id: <200103161020.LAA28826@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.dk In-reply-to: Oliver Kiddle's message of Thu, 15 Mar 2001 15:46:11 +0000 Subject: Re: Moving completion functions [Answering Oliver and Bart here, I'll shuffle things around a bit, simple stuff first.] There are 84 functions in Unix/Command. In the first version of the script I held myself back when thinking about renaming files, that was probably wrong. Comments about the files/directories that have been mentioned: - I hadn't thought about using Zsh/Command. I like that. I'll use it. - _vars_eq will become _typeset - I can also put _dict_words into a separate function (compared to the whole thing that extra bit of work doesn't count) - I don't think _diff_options should be in Utility, after all, it completes a certain type of matches. - _dirs becomes _directories, ok (I think this is one of the oldest functions -- hmm, the memories...) - I was wondering if _mere is for the function or for some command I don't know... - _mysql_utils should probably keep it's name. I think this was modelled after _psutils and _xutils. Those two should then be renamed to _ps_utils and _x_utils. - move _gv, _nedit and _netscape to X/Command - _pdf to User/Type (there I just pasted the wrong directory) - _use_lo should get a better name, yes. Hm, I don't like mixing the underscore-style we use with hyphens in function names, and anyway I prefer _parse_help (or _options_from__help?) - I'll change _(un|)set_options and _[fb]g_jobs. - We could also change _call to _call_program and _funcall to _call_function. - And there could be a better name for _compalso. - _all_matches can stay as it is, I think, because this is a completer and those are more equal than the other animals. - Btw: I thought about _oldlist -> _old_list, but since people might have that in their .zshrc's... - For the label functions (and the tag functions) I think we should either leave them or try to find names that are both readable and have the sorting behaviour Bart wants (and not only he, I like that, too). So... _tags _tags _wanted _tag_wanted _requested _tag_requested or _tag_selected _all_labels _labels_for _next_label _label_selected (These are used as in: _tags while _tags; do ... done _tag_wanted if _tag_selected ...; then ... fi _labels_for while _label_selected ; do ... done ) Would that be acceptable? Lotsa changes... Now to the other things... Oliver Kiddle wrote: > ... > > My preference would be for the lowest level to be removed leaving > directories for AIX, Linux, Zsh etc but not having directories for > Type, Command etc. [...] Like Bart I like this idea. > Is it only me who uses > --enable-function-subdirs? [...] You're not alone. Bart wrote: > [...] On the > other hand, the only reason I can see for splitting Unix/Command into > more specific directories would be for selective installation, and I'm > not sure that's important enough. Yes, I wasn't sure either (obviously). One gets functions for commands one doesn't have... so what. It only gets interesting if we start writing different versions of certain functions (like the _path_files-for-cygwin Bart mentioned) or if we want to put different functions for the same command into different directories (as mentioned by Oliver). That's the old problem which we've never solved. Currently we put the different versions in the same file in the User directory and decide there and then what to do. I think this approach is better than using different files as long as there aren't too many versions to support (although it'll look very wrong if we ever find commands with the same name that do completely different things on different systems). My first reflex is to postpone this decision until we run into serious problems. Then we can start thinking about a convention for dealing with different versions of one command and about a way to configure this so that the right files will be installed or loaded. I just hope we can make sure that the directory structure we build up now is able to deal with such possible changes. But there's probably no way to ensure that if we don't decide now. Oliver: > For this reason, I think a Network directory is a good idea because it > is quite possible to have a computer which is not connected to the > network so all the networking related stuff are of no use. The X > division is I think useful. If we remove the second level on installation, this should be a first-level directory like X, though. And there's even stuff to fill a Network/Type directory. > Graphic and Sound is a more complex issue > because you might care about programs which manipulate sound files or > images but not have the ability to play or display them. Yes, similar foe Network if it's a first level directory. There are network commands that need X and ones that don't. > Another > possbile division would be for commands which are related to sysadmin > such as those which are only likely to be in root's path. Hmhm. Considering this discussion (and that today is Friday) I think I'll better not start on Monday... Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de