Re: Strange _values completion on accept-and-menu-complete and menu selection

[Andrey Borzenkov <arvidjaar@xxxxxxx>]

On Monday 13 December 2004 00:44, Bart Schaefer wrote:
> On Mon, 13 Dec 2004, Andrey Borzenkov wrote:
> > > Normally compstate[compound_word] would be unset, but "compvalues -i"
> > > would set it based on the parse.
> >
> > I still believe this is more general and should not be limited to _values
>
> Sure; compstate[compound_word] doesn't have to be read-only, any function
> that needs it could set it.  It just seems correct and convenient to have
> compvalues set it automatically.
>
> > Here is updated patch (which also fixes initialization problem).
>
> There's one line of shell code where you have compstate[compound] but want
> compstate[compound_word].  No need to repost, but fix before commit.
>

it is far from being suitable for commit (and I was off most of the time).

> > This still has problems in completing nested calls to _values (should it
> > work?)
>
> I don't have time to debug carefully just now, but I suspect without any
> real evidence that compstate[compound_word] is becoming unset on return
> from the nested call and therefore is wrong for the subsequent selections
> for the outer call.

it is more general problem. When match is inserted it has all parts - ignored 
prefix, prefix, etc insterted. In our case we actually have as iprefix 
everything up to separator - and get everything up to separator reinserted. 
It happens without any nested calls too:

{pts/0}% foo foo,TAB
{pts/0}% foo foo,bazzz,
Completing test values
barr   bazzz

and hitting a-a-m-c

{pts/0}% foo foo,bazzz,foo,barr

It is the same problem as completion in braces. Braces are treated as special 
case inside completion code unfortunately. Hopefully it is possile to 
generalize it.

-andrey