Re: zle messes up 'words' variable?

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Tue, May 3, 2011 at 5:39 PM, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> 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.

Except that 'words' is not really acting as local, and 'local' should
be considered 'declared otherwise'. That's part of the weirdness.

> } 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.

That's true.

> } 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.

I see.

> } > 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.

I didn't intend that as an insult; some people are good are
compartmentalizing, some people are not.

> } 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.

Well, bashcompinit is also a script. If my script can be fixed without
modifying _foo() or set_vars(), then the same fix can be applied to
bashcompinit:

+typeset -h words
 complete -F _foo foo

-- 
Felipe Contreras