Re: Moving completion functions

[Oliver Kiddle <opk@xxxxxxxxxxxxx>]

Sven wrote:

> Radical idea: let's just wait and do nothing about all this yet.  If

Probably a good plan.

> I don't like _want(|ed)_now, though, because it is too easily confused 
> with _wanted, I think.  And with _wanted we want to add the
> completions *now*, too.

Fair enough. _wanted_yet would possibly address your second point above
but not the first. It would be nice though if we can find some names
which better express the difference between _wanted and _requested. I
can't though and the current names aren't too bad.

> There's now the call to `cvs tag' in it, too.  I think using a tag
> that looks completely different than the version tags is a good idea
> but I otherwise I don't know what to use as a tag.

I agree that it shouldn't look like the version tags. I'd try to use
something which makes it clear that the tag is set before the move -
something like old-comp-dirs or pre-comp-mv. I've never dealt with cvs
tags though so am probably not the best person to answer this.

> Builtins/_popd                  Zsh/Command

_popd could possibly be something like Zsh/Type/_directory_stack as
that is all it completes and it is called by _cd. It might make _cd
more readable and would adapt better to changes in popd's usage.

The script looks fine though I've not looked in as much detail as
before.

Other than the naming of _compalso, _wanted, _requested, _next_label,
_all_labels and the cvs tag are there any other outstanding issues on
this?

Bart wrote:
 
> What exactly would you like fpath to contain by default?  Nothing?

Yes. Unless the parent process exported FPATH to zsh. At the least, we
should change zsh so that if FPATH is set in the environment when it
starts, the completion directories are added to it instead of replacing
it..

> it also sets it to get the stuff from the Functions subdirectory, etc.

I always thought of them as just examples and user contributions as
opposed to being part of zsh's functionality. Before the new
completion, they had to be manually installed and added to $fpath. I've
just noticed though that they are now mentioned in the documentation
which I suppose makes them more official. 

> If we remove the Completion directories from the default fpath, then we
> must also give up --enable-function-subdirs.  Not that we can't use the
> subdirs for installation, but that we must hardwire the installation so
> that compinit can know what to add to fpath.  Even then, compinit needs
> to get the base path (to which to append /Completion/...) from 
> somewhere.

As I said with the original suggestion, there could be a variable set
to point to the base of the installed functions. I don't understand why
compinit would need to know before-hand what directories it should add -
it would just use a bit of globbing modified for $OSTYPE and options
passed to it, I'd be very much against any manufacturing of compinit,
especially while it is installed below /usr/local/share.

> Issues of setting fpath aside, the following patch makes it possible to
> source compinit.  (Not committed yet, pending further discussion.)  One
> thing that bothers me a bit is that the (ARGC=0) test will give the
> wrong result if compinit is sourced from within some other function; as far 
> as
> I can tell, there's no completely reliable way to determine that 
> "source"
> (or ".") is in progress.

The ARGC test thing is clever. Do we need to account for kshautoload
though? How does someone with kshautoload set get the new completion
system to work short of doing unsetopt kshautoload? Having tried a few
ideas, I can't think of any better ways to detect when source is in
progress.

Oliver