Re: Moving completion functions

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mar 15, 10:30am, Sven Wischnowsky wrote:
} 
} I've used Oliver's suggestion for exchanging the names of the Core and 
} Base directories and Bart's suggestion to use the singular.  I'm still 
} not too happy with the name `Type', but since we constantly say things 
} like `type of matches' in the docs, this name is probably not that
} bad.

The only alternatives I can think of would be "Category" or "Class",
but I'm not too excited about those either.
 
} Some directories (esp. Unix/Command) could make one think about
} splitting them up even further (Unix/Net, Unix/Graphic, but also
} Zsh/Function and probably others).

The question to ask is, what's our primary purpose in splitting them up?
Is it to allow selective installation?  (The original reason for BSD/ and
AIX/, I think.)  Is it to help us as developers decide where to put new
ones?  To help users decide what should be in $fpath?  To help users and
developers understand how the system works?

Of course it's some of each of those, but which ones are more important
can indicate just how much splitting up is worthwhile.  For example, no
one would ever selectively install parts of Base/, but it still seems to
me important for understanding to subdivide Base/ as you did.  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.

} The rule of thumb is that those functions were put into Type that are
} usable as functions for completing types of <whatever>, even if they
} aren't (yet) used in that way.

Seems reasonable to me.

} For some files we could also think about better names, maybe (_vars_eq 
} comes to mind).

Yes, that could definitely get renamed as _typeset.

I think I'd also rename _set_options and _unset_options as _options_on
and _options_off respectively.  In a similar vein, consider _labels_all
and _labels_next, _matches_all, _parts_multi, _parts_sep, _cache_store,
_cache_retrieve, _jobs_bg, _jobs_fg, ...  (I have a tendency to want
related files to group together in a sorted listing, but in some cases
[like _all_matches and _dir_list] I waffle because the readability of
the calling scripts will suffer.  I also wouldn't use _options_diff
because the relationship to _diff is the more important one.  Etc.)

} Any better way to update the .distfiles[1]?

Probably not.

The script looks good.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net