hex color parsing kaput when code starts with number

[Elaine Meng]

Apparently it gets confused with a model number. Although all the examples Greg sent me were for opaque red, which generally starts with "#f", there was this one mysterious example: #0xff0000

I was skeptical because I thought the correct hex RGBA for opaque red would be #ff0000ff, which does indeed work in Chimera2. When the mysterious example didn't work I tried several other hex-RGB and hex-RGBA specs and they also don't work. I don't know if the mysterious example above is really supposed to work, but just try any 3- or 6-digit hex RGB that starts with an arabic numeral, say plain old blue: color #0000ff

error message for that is "expected keyword, got 'ff'

[Greg Couch]

This is a bug in the atomspec argument parser. It should be raising an error when the valid atomspec is not followed by the end of a string or a space. Once it fails, it should then be interpreted as a color spec. It does mean that you won't be able to color something black with "color #000", instead you would have to "color color #000", ie., give the color as a keyword argument instead of an optional argument. Unless the atomspec parser were smart enough to know that there is no model zero and thus #000 could not be a real model.

[Greg Couch]

The #0xff0000 example was a bug, it should have been #ff0000.

So this really isn't a bug in the atomspec parser, but a conflict between the #model of an atomspec and #hex colors. In the color command, the optional atomspec comes first, and the #00ff00 was matching the regular expression '#[0-9]+', so #00ff00 was a bad atomspec instead of a green color.

One way of fixed this would be to reorder the arguments, so a required color comes before an optional atomspec. But to keep the current argument order, a workaround has been added that only allows up to five digits for the model number and it must not be followed by a letter.

Should probably be discussed at a chimera meeting.