Re: One last _values / compvalues nit, and a nasty crash bug

[Oliver Kiddle <opk@xxxxxxxxxxxxx>]

Back on 10th May, Sven Wischnowsky wrote:
> 
> Bart Schaefer wrote:
> 
> > Now the bug -- press TAB three times after `: a' and get a crash:
> >
> > schaefer<501> function _tv { _values -S '' -s : 'a: :(foo)' b }
> > schaefer<502> compdef _tv :
> > schaefer<503> function _tv { _values -S '' -s : test 'a: :(foo)' b }
> > schaefer<504> : afoo:afoo:BUG: attempt to free more than allocated.
> > _values:149: command not found: 0R^O^H\M-^?\M-^?\M-^?\M-^?@T^O^H\M-^?\M-^?\M-^?\M-^?pR^O^H\M-^?\M-^?\M-^?\M-^?\M-@S^O^H\M-^?\M-^?\M-^?\M-^?\M-pP^O^H\M-^?\M-^?\M-^?\M-^?ws
> > zsh: segmentation fault (core dumped)  zsh-4.0.1-pre-4
> 
> That was because compvalues couldn't handle an empty string as a
> separator.  It still can't, but the patch makes it test that and report
> an error.  More below.

But we use _values in a number of places with and empty string as a
separator so this isn't good, for example:
wget -n<tab>
: $fpath[(<tab>
both now produce the invalid separator error where they previously
worked. I don't suppose it is only the -S separator (as opposed to -s)
that compvalues doesn't like an empty string?

Is there any chance that compvalues, comparguments etc could be given
some sort of documentation. I know this was mentioned recently but it
could go in either the zsh-development-guide or completion-style-guide
file.

Oliver