Comment regarding comment ambiguity

[pnathan]

Suppose:

[describe.number.#]
blathering = "here"   

But, consider these definitions - the comment one first:

They go from the symbol to the end of the line.

vs.

Name your key groups whatever crap you please, just don't use a dot. Dot is reserved. OBEY.

and:

Keys start with the first non-whitespace character and end with the last non-whitespace character before the equals sign.

This results in two correct parses: describe.number. or describe.number.#.

While ambiguity is good in poetry, it drives parsers mad.

[88Alex]

The example you gave is syntactically incorrect, as there is no ] tag, but I think that the correct parse would be describe.number.

[pnathan]

Alex, I don't understand what you mean. There is a ] character.
The spec indicates that I can either strip out # and everything following, or everything between [] is a valid keygroup.

[88Alex]

Well, there is a ] character, but it's commented out.

If this answers your question, I believe # characters aren't allowed in keygroup names. If they were, it would lead to so much confusion.

[pnathan]

The spec is ambiguous. As I point out in the filing of the issue, it can be read to both allow or disallow comment characters in the keygroup.

Name your key groups whatever crap you please, just don't use a dot. Dot is reserved. OBEY.

[88Alex]

The specification should be updated to this:
"All characters are allowed in key-group names, except for these: = [ ] # ."

[BurntSushi]

I've interpreted the spec to allow # in both table names and key names.

I think @pnathan is right here. This is an ambiguity. If we fix the wording in the spec, then it needs to be for both table names and key names. Or we could allow # in table names and key names. Either way, a clarification seems good.