fredludlow
commented
5 years ago I think the reason is that residue names and numbers are potentially ambiguous: if you want to be totally explicit (a good idea if generating selection strings in code) then always use square brackets for your residue names (this is supported). If you want to save some typing when using it interactively then (non integer) residue names can be un-bracketed.
it might be a good idea to just combine these two expressions and just require that all residue names have square brackets around them.
I'd be very reluctant to do this, as it would break a lot of existing code, though AFAIK you can always use square brackets in your own code to avoid ambiguity
Alternatively, the parser could be edited to account for numeric residue names without square brackets.
This again would break existing code (a bare 032 becomes a residue name rather than a residue number)
Perhaps tweaking the documentation would be helpful?
residue name: ALA, [ALA], [032], [1AB] ... (square brackets are required where a residue name could be interpreted as a number) ?
Note that [1AB] requires brackets as parseInt('1AB') returns 1 in javascript
Hello, I work for a company that is implementing NGL Viewer in our Django app. We ran into a bug where all of our residue names that began with a number were not being displayed. After digging through the Selection Language docs we finally found the line that describes a separate field for
numeric residue namethat requires an extra set of square brackets around it:I am just wondering if there is a biological reason to keep these separate, or if perhaps this numerical distinction was added on later as a sort of bandaid fix to the parser. If the latter is the case it might be a good idea to just combine these two expressions and just require that all residue names have square brackets around them to avoid the confusion that we endured when we came across this issue. Alternatively, the parser could be edited to account for numeric residue names without square brackets.