Re: completion implementation woes

Re: completion implementation woes

[Oliver Kiddle]

On 2 Oct, Roman Neuhauser wrote:
>   why does '*::' pop $words?

*:: removes all recognised options from $words. *::: would strip it to
just arguments corresponding to this spec.

>   is there any chance to get the - thing working with chained _arguments
>   calls?  this seems to be the least-clutter notation...

Try the patch below. This makes it check if the word is a recognised
option rather than just seeing if it starts with '-' or '+'. I've not
been able to really establish what purpose the whole condition serves.

When it was first added, the sets notation didn't get too much use
because it is slower, requiring multiple parses of the command-line. So
bugs are less likely to have surfaced.

>   in fact, i'd love to get as close to a grammatic pov as possible,

There's also _regex_arguments which is closer to a grammatic pov,
though use of it is more than a bit messy compared to plain BNF
notation.

>   and the more faithful the representation the better.  eg. activate
>   does not take any operands, so the '*::option or operand:..' rule
>   rubs me the really wrong way.

You don't have to have 'option or operand' in there as a description.
Use a single space to leave it blank.

Oliver

diff --git a/Src/Zle/computil.c b/Src/Zle/computil.c
index e9bad1c..cb3c32f 100644
--- a/Src/Zle/computil.c
+++ b/Src/Zle/computil.c
@@ -2158,7 +2158,8 @@ ca_parse_line(Cadef d, int multi, int first)
 		state.opt = 0;
 	    else
 		state.curopt = NULL;
-	} else if (multi && (*line == '-' || *line == '+') && cur != compcurrent
+	} else if (multi && (*line == '-' || *line == '+') && cur != compcurrent &&
+		ca_get_opt(d, line, 0, NULL)
 #if 0
 		   /**** Ouch. Using this will disable the mutual exclusion
 			 of different sets. Not using it will make the -A