blank atomspecs cause errors

[Elaine Meng]

If the atomspec is blank, none of the special color names (byhet, bychain, byseq etc.) work in the current daily build. For example "color #1 byhet" works, but "color byhet" gives error:

Missing or invalid "objects" argument: (1:1) "byseq" is not a selector name : ^{selector_name as_term atom_specifier}

Don't know who's the culprit, reassign as needed.

[Elaine Meng]

Oh, it's worse than I thought... seems like blank atomspec causes an error in many (all?) commands, even without special color names, e.g.

color red
style sphere
(etc.)

[Conrad Huang]

The color command is registered as

color (ObjectsArg|EmptyArg) [ColorArg|S!pecialColors]

When parsing "color red", ObjectsArg.parse calls AtomSpecArg.parse which calls AtomSpecArg._parse_unquoted. The parser (eventually) figures out that "red" is a word and calls _AtomSpecSemantics.selector_name to process it. selector_name sees that "red" is not a registered selector and raises grako.FailedSemantics. The problem is that it tries to set the "pos" and "endpos" attributes of the exception instance, but the parser catches the constructed FailedSemantics exception and reraises a grako.FailedParse exception. The latter does not use our custom "pos" attributes (0 in this case); instead, it uses the "pos" constructed by the parser (3 in this case). The FailedParse exception is caught by AtomSpecArg._parse_unquoted and converted to an AnnotationError with attribute "offset" set to "pos". This AnnotationError is caught by Or.parse, which reraises the Annotation exception because "offset" is non-zero.

I'm reluctant to change the exception processing in parsing since FailedSemantics is the exception that the grako documentation recommends. Changing Or.parse to ignore the offset value makes "color red" work, but I don't know what it breaks. Greg?

[Conrad Huang]

Greg wrote the cli.Or class and needs to determine how to handle AnnotationError exceptions. Still not sure when this broke.

[Greg Couch]

This bug looks like it is due to a change in grako 3.17: "Report the parse exception (grako.exceptions.FailedParse) ocurring furthest in the input so error messages are more meningful even when no cut (~) expressions are used."

ChimeraX's AnnotationErrors expects the "pos" attribute to reflect how much input was successfully parsed before there was an error. In this case, was the "red" successfully parsed or not? From ChimeraX's point of view, it was not, it did not match an atomspec. But grako did find a token. Need to look at how atomspec parser works.

[Greg Couch]

Reverted to grako 3.16.5.