A parsing bug that has been around for ... years? decades?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

Consider:

zagzig% a=( 1 2 3 4 5 )
zagzig% noglob print x=( $^a )
x=( 1 ) x=( 2 ) x=( 3 ) x=( 4 ) x=( 5 )

There are spaces around $^a, so one (or perhaps both) of the following 
should have happened:

1. 'x=(' and ')' should have been separate words, and RC_EXPAND_PARAM 
   should have had no effect at all, yielding "x=( 1 2 3 4 5 )".

2. a parse error should have occurred on the closing paren.

What apparently did happen, but IMO should not have, is that everything
in the parens was swallowed up as glob qualifiers, but then the glob was
not performed.

Consider further:

zagzig% setopt correct
zagzig% fOo() { : }
zagzig% foo
zsh: correct 'foo' to 'fOo' [nyae]? a
zagzig% noglob foo
zsh: command not found: foo

Surely noglob is not supposed to subsume the function of nocorrect?  Not
even "setopt correctall" is effective there.

The fix for both of these would appear to be that parse.c:par_simple() has 
to actually recognize noglob as a token, the way it does nocorrect, so 
that the "command position" context can be preserved for the following
word, and so that parsing of glob qualifiers can be disabled for the rest
of the command.

However, I imagine the latter would break something somewhere, so perhaps
that part should merely be better addressed in the documentation.