implement wildcarding for atom specs

[pett]

As per: ​https://www.rbvi.ucsf.edu/trac/ChimeraX/wiki/2018-10-22

(basically globbing throughout, though in attribute tests only if '~' is the operator. Also, '='/'~' as the operators do case insensitive matching, where as '=='/'' do case sensitive)

[Conrad Huang]

Initial implementation is in the daily build. Leaving ticket open for a while in case there are issues.

[Elaine Meng]

Is this just for residue names and atom names?  In Chimera we also had some special stuff for ranges, something like the words start or end or * to mean either one of those (if it were at the start or end of the range specification, respectively).

[Conrad Huang]

Yes, it is strictly wildcarding for names.  In fact, for now, wildcards 
are disabled if you have a range, mainly because I couldn't think of a 
rational way of combining wildcards and ranges.  So, for example, @c*-cz 
will interpret "c*" as the literal string rather than as a wildcard.

Our old interpretation of @cb-* was retired for ChimeraX in a long-ago 
discussion.  It is more difficult to implement in ChimeraX than in 
Chimera because of the way the data structures are designed.  I think 
there was something about "you can just use 'sidechain'" as well.

Conrad

On 10/26/2018 9:31 AM, Elaine Meng wrote:

[Elaine Meng]

I agree we don’t need ranges of names.  However, I was referring to numerical ranges, for which I think we should have wildcards for start and end  (one often does not know the first or last residue number).   It can be a separate ticket, though. Let me know if I should make one.

[Conrad Huang]

It might be ugly to implement, but is the proposal that a lone "*" as 
either start or end of a residue range is interpreted as "first" or 
"last" residue in a chain?

If so, can you please make another ticket?
   Thanks.


Conrad

On 10/26/2018 12:48 PM, Elaine Meng wrote:

[Elaine Meng]

OK, the ticket for numerical ranges is #1388.  As mentioned in that ticket, I’m OK with using words instead of asterisk.  Just want the convenience of not having to look up the first and last residue number in a structure.

[Conrad Huang]

Removed ~, ~~, !~ and !~~ operators. =, ==, != and !== now use simple compare or glob matching depending on the absence or presence of wildcard characters in the user-entered value.

At our meeting, we agreed to use backslash as the escape character. However, I looked at the documentation for fnmatch, the ​Python module we use for glob matching, and it has its own way for escaping characters: "For a literal match, wrap the meta-characters in brackets. For example, '[?]' matches the character '?'.". Should we use that instead?

[Elaine Meng]

My 2 cents’ is that  \ is easier to type and seems more familiar as an escape character, but maybe there are other factors I don’t understand (like how important it is to adhere to the module).

[Elaine Meng]

Seems that we settled on the scheme, with * wildcard, ? single-char wildcard, and square brackets [ ] to indicate a set of characters to substitute individually, or to “escape” a single character that would otherwise have a special meaning, as currently documented
​http://rbvi.ucsf.edu/chimerax/docs/user/commands/atomspec.html#wildcards

I.e. seems like the ticket could be closed.

[Conrad Huang]

Wildcard issues have been resolved here and in #1388