Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: PATCH: Completion/Cvs/



In article <199909010925.LAA32701@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
  Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx> writes:

> In this example I think I would like to have it complete `vi' if the
> cursor is directly after the `-e' (same word), because the `*::...'
> should only take affect on whole words, i.e. in this case the word
> after the `-e...'.

Why? Since a first non-option argument is the `a', I think the
`*::...' should take affect the `-e...' after the `a'.

I want to stop completion by _arguments until first non-option
argument --- the `a'. So In the example, I want the behaviour that
there should be no completion after the `a'.

> With that, this is just a special case of a more general problem with
> completion after a `-e+:...' option. Currently we use the description
> for the first option-argument to complete the next word after the `-e' 
> only if there really is nothing after the `-e' in the same word (so
> that `foo -e <TAB>' completes the option-argument and `foo -ebar <TAB>'
> completes normal arguments). But what if the empty string is a valid
> option-argument? I think `-e+::...' should give us that (that's what
> the patch below does).

I think this is another issue.

Even if the empty string is a valid option-argument, getopt does not
take the option-argument from the same word because getopt never
knows it. In general, it is impossible to parse command line with the
rule that enable the empty string option-argument just after (without
white space) the option-argument word. So I think it is useless.
-- 
Tanaka Akira



Messages sorted by: Reverse Date, Date, Thread, Author