Re: Completion function for bitkeeper?

[Danek Duvall <duvall@xxxxxxxxxxx>]

On Tue, Nov 11, 2003 at 08:06:12PM +0100, Oliver Kiddle wrote:

> Sorry, I should have been more clear. What I mean is actually in the
> _arguments action itself not within a function called as part of the
> action. Looking at the documentation, it isn't as clear on this as it
> should be. It doesn't help that in the rearrangement of the
> documentation, the expl mention has become separated from the
> `{eval-string}' action form and a little from the initial space
> feature (have a look at 4.0 documentation).
> 
> Basically, it is intended so you can do things like this:
> 
>   '-a:desc: _foo -x -y -z "$expl[@]" a b c'
>   '-b:desc:{compadd "$expl[@]" one two three}'

Okay, I see what you mean now.  It's not intended for $expl here to be
visible inside the function that's called, but it is, because of the
scoping issues you and Peter are talking about.

Is there any reason (other than it would break code relying on the
current behavior) not to just require someone to explicitly add $expl to
the action, so that they can control where it goes?  You can do that now
by prefixing with a space, but ... that just seems a bit silly to me ...
too much automation for a case that doesn't really require it.  But now
that I understand it, I guess I can live with it.

> Any ideas on how to make the documentation clearer on this?

I'm not sure.  I think what made it click for me was your example above.
Perhaps saying that

    '-a:desc:_foo -x -y -z a b c'

is equivalent to

    '-a:desc: _foo "$expl[@]" -x -y -z a b c'

as a "that is" statement somewhere in that paragraph would be helpful?
Getting rid of the automatic passing would certainly help make the
documentation easier to write here.  <grin>

The root of the problem is that I was getting arguments in my function
called from the action that I didn't know how to deal with, and I didn't
know how to ignore, other than putting the initial space in, which felt
like a kludge, or possibly the wrong answer.

If that's the only confusion that needs to be addressed, perhaps we
could say that if a function called as an action wants to do argument
parsing, it may have difficulty because of the options passed to it by
_arguments.  Such a function should probably be called in an action
starting with a space to avoid the problem, and $expl[@] be passed
explicitly in such a way that the function can handle extracting those
arguments from the non-compadd related ones.

Then, if you really wanted to lay it on thick, you could also mention
that trying to extract the contents of $expl as _arguments sees it from
within the function is not supported, and that it only works because
there's currently no way to prevent the function from inheriting it from
_arguments, but that may change at some point in the future.

> How's that bitkeeper function doing these days by the way? Is it at a
> stage we could include with zsh? Does it conflict with _sccs?

Well, none of the usual zsh folks commented on it, so while it works for
me, I don't feel it's undergone much review.  There's some work that
still needs to be done, I think:

  - flesh out all the bk sub-commands; not all of them have clauses in
    _bk yet
  - there are a number of comments in the function that indicate things
    I couldn't quite figure out what to do
  - I don't think that it conflicts with _sccs at all, but it might be
    nice to get _sccs to use _sccsfiles in the appropriate places.
  - _sccsfiles probably should have some way of controlling the depth to
    which it searches for matches.  Currently, it just does **/ and if
    that has to search through tens of thousands of files and
    directories, then you're just going to have to wait, and I don't
    think that's necessarily the best behavior.  Suggestions for more
    appropriate behavior would be greatly appreciated.

Other than that, I'm perfectly happy for any of this stuff to get into
the tree.

Thanks,
Danek