Re: zle messes up 'words' variable?

[Bart Schaefer <schaefer@brasslantern.com>]

On May 3, 11:05am, Felipe Contreras wrote:
}
} The fact that it's documented as a special variable doesn't mean that
} the behavior should be totally unexpected.
} 
} 1) Without modifier
} 
} Then 'words' can be re-used like any other variable.
} 
} 2) With 'local' modifier
} 
} Then modifying 'words' has an impact only on the current function, not
} on the scope where the variable was defined as local.

Ahh, I see the problem.  You haven't read the entire documentation.
At the very top of (what in the info file is) section 19.2 is this
paragraph (caps mine for emphasis):

    Inside completion widgets, AND ANY FUNCTIONS CALLED FROM THEM, some
    parameters have special meaning; outside these functions they are
    not special to the shell in any way. These parameters are used to
    pass information between the completion code and the completion
    widget. Some of the builtin commands and the condition codes use or
    change the current values of these parameters. Any existing values
    will be hidden during execution of completion widgets; EXCEPT FOR
    COMPSTATE, THE PARAMETERS ARE RESET ON EACH FUNCTION EXIT (INCLUDING
    NESTED FUNCTION CALLS FROM WITHIN THE COMPLETION WIDGET) to the
    values they had when the function was entered.

In other words, these variable are always local in all scopes, unless
they are explicitly declared otherwise (which in this case requires
the use of typeset -h).  That's part of their special-ness, and is one
of the things I assert is extremely unlikely to change.

} 2.1) When using #compdef tag
} 
} Then 'words' can be modified like any other variable.

I thought you'd decided you were unable to reproduce this?  If you now
*are* able to reproduce it, then *that* might be a bug.
 
} 3) With 'typedef -h'
} 
} Then 'words' can be modified like any other variable.
} 
} I was expecting an explanation of these discrepancies, and a way to
} globally make 'words' work as expected without having to replace each
} use of 'local' by 'typedef -h'.

I apologize for not understanding the source of the mis-understanding.
I was focusing on why #compdef might make a difference, not on the
details of the actual scoping problem you perceived.
 
} > If what you want to discuss is ways to fix bashcompinit so that the
} > functions in bash completion work as expected, that's one thing.  If
} > what you're asking is for the special-ness of "words" to be undone
} > for completion in general, that's so unlikely to happen as to not be
} > worth continuing.
} 
} You are not good at compartmentalizing aren't you?

I'm really disappointed in the way that mailing list discourse in
general lately (and not just on this list) tends to rapidly descend
into insults and ad-hominem attacks.  I've been watching the CentOS
list collapse under the weight of this sort of thing and I plead that
we try to avoid it here.

} If you fix the issue with my example, you fix the issue with
} bashcompinit. It's the same issue. Or "riddle" if that word makes you
} more comfortable.

No, it's not the same issue, because bashcompinit has responsibility
for loading the bash completion functions in a way that makes them
compatible.  That's not the same as first loading bashcompinit and
then independently defining a new completion, though I lean toward 
the conclusion that use of the bash-compatible "complete" command is
probably the correct place to fix this if it can be managed.

--