Bart Schaefer wrote:

> [Aside:  Is it possible for you to convince your mail client not to
> send text labeled us-ascii when it contains multi-byte characters (I
> think they must be Unicode apostrophes?)  It makes it quite difficult
> to read.  I've manually edited them back to ' in the excerpt.]

As Dan Nelson points out, it all seems to be in order.  I don't want to
push it back at you, but perhaps your mail client is being fooled by the
mime-type of the second attachment (which was us-ascii).  Anyway, if
this problem persists, I can live without using fancy apostrophes on
this list.

> On Jul 7,  4:02am, Nikolai Weibull wrote:

> > There's a problem with the +<n> option, though. I couldn't figure out
> > a proper way of escaping the + that is the options name (just using \+
> > doesn't work).

> The + is not the option's name.  The name is whatever comes *after* the
> initial - or + that introduces the option.  In fact, in this case +<n>
> is not really an option at all; really it's a non-option argument that
> happens to be allowed to be mixed in among the options.

OK.

> I prefer the behavior of the modified _my_files (which, by the way,
> should probably be renamed _vim_files if this is going to be added to
> the stock completions).

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

_vim_files () {
  if [[ $(echo $PREFIX*(N)) == '' ]]; then
    case $PREFIX in
      (+) _message -e 'start at a given line (default: end of file)' ;;
      (+<1->) _message -e 'line number' ;;
    esac
  fi
  case $PREFIX in
    (+*) _files -P './' $* ;;
    (*) _files $* ;;
  esac
}

This may not be the best solution, though. I kind of hope that there's a
nicer way to test if there are any files having $PREFIX as a prefix.

Thank you for your help,
        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);}