Added a pair of configuration keys to EntityLookup5 to allow user-configurable non-alphanumeric characters in candidate matches.
The motivation is to be able to match certain abbreviations such as "%ile". Current behavior rejects any candidate matches if the first character of the first token is non-alphanumeric (or non-greek-letter), and while this is basically always what one wants there are a handful of particular abbreviations/jargon terms I need to be able to match that start with punctuation. The default behavior should be unchanged, but if metamaplite.entitylookup5.considerNonAlphaTokens is true, it will also allow tokens whose first character is in the list specified by metamaplite.entitylookup5.additionalAllowedFirstChars.
In terms of implementation, since this is very much on a hot performance path, I tried to structure things so that the most common case is likely to fail early.
Added a pair of configuration keys to EntityLookup5 to allow user-configurable non-alphanumeric characters in candidate matches.
The motivation is to be able to match certain abbreviations such as "%ile". Current behavior rejects any candidate matches if the first character of the first token is non-alphanumeric (or non-greek-letter), and while this is basically always what one wants there are a handful of particular abbreviations/jargon terms I need to be able to match that start with punctuation. The default behavior should be unchanged, but if
metamaplite.entitylookup5.considerNonAlphaTokensistrue, it will also allow tokens whose first character is in the list specified bymetamaplite.entitylookup5.additionalAllowedFirstChars.In terms of implementation, since this is very much on a hot performance path, I tried to structure things so that the most common case is likely to fail early.