Bart Schaefer wrote:

> > Done.  I modified the function a bit to handle files named +<n> a bit
> > better:

> I'm not sure this is better.  Previously you should have seen the
> explanation of 'line number' on the first tab, and then been able to
> complete the file name on the second tab.  With your change, you'll
> never see the 'line number' message, it'll always complete the file.

No, that's true.  However, when I tried it, I never get to the second
group on sucessive tabs (even after an 'emulate zsh').

> But if that's the behavior you wanted, this would be a better way:
> 
>     _vim_files () {
>       case $PREFIX in
>         (+*) _files -P './' $* && return 0 ;;
>         (*) _files $* ;;
>       esac
>       case $PREFIX in
>         (+) _message -e 'start at given line (default: end of file)' ;;
>         (+<->) _message -e 'line number' ;;
>       esac
>     }

OK, I changed it to that.

> Oh, one other thing ... having _vim_files embedded in the file named _vim
> in that way, causes _vim_files to be redefined as a function every time
> the _vim function is *called*.  I should have noticed that before.  See
> something like _cvs for an example of defining multiple functions in the
> same file.

Ah, I was looking for examples of completion functions using auxiliary
functions and actually saw that, but never got around to adding the
redefinition-protection.  Thanks.

I've included a patch against CVS,
        nikolai

-- 
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}