GH - TextMatch doesn't match "[0]" although matching "(0)"

unhandled
rhino5-rhino6

#1

Using TextMatch component (Rhino 6) to find items in a string list, it fails to match a string containing numbers inside square brackets (e.g. “[0]” ). See image:

Bug - TextMatch .ghx (50.8 KB)

Is this a bug, or are there some hidden features in the match components which is enclosed inside square brackets?

I see the same problem in both GH 0.9 and GH1.0.

// Rolf


(David Rutten) #2

The regular pattern comparer uses the VB.NET Like operator, which does use square brackets to define character sets for matching. I’m actually not entirely sure what can be done to ignore meaningful characters, typically it involves escaping but I cannot find anything about that at a first glance.


(Nathan 'jesterKing' Letwory) #3

I think it is up to user to properly prepare the input for pattern. If a literal [ (or any of the special characters for that matter) is meant it should be escaped. It isn’t too hard to do as a preprocessing step with a simple (probably custom ) component.


(David Rutten) #4

Ideally though you’d be able to craft a pattern that works for any string matching without having to dick with the input. You can of course always switch to RegEx instead of the pattern matching, but that comes with its own set of problems.


(Nathan 'jesterKing' Letwory) #5

Ideally, but that means assuming a whole lot of intended use cases, making others hard.

I would go for the RegEx input like so:

TextMatch_suggestion.ghx (59.8 KB)


(qythium) #6

It would be helpful to have this mentioned somewhere in the component description - the current icon and param tooltip give the strong impression that only the “wildcard” characters ? and * are treated specially.

The escaping syntax seems to follow Unix style glob patterns, which require wrapping special characters in square brackets:

Again this is not obvious at all to the average user of Grasshopper, who probably won’t be familiar with regex either…


(David Rutten) #7

Yeah, proper documentation and example files would have been great, but this way at least it’ll be easy to make GH2 better.


#8

Ummmff. Yeah, tell the world what this product is good for really, and toss the major version number. :wink:

It didn’t struck my mind that it could have something with RegEx to do. Too early in the morning I guess. But perhaps I would have suspected it if I had used Icon mode, now I use text labels and so I see only “TMatch” which to me really means matching only with literal text.

Explicit RegEx or Literal Text

So, silly me didn’t expect this to be RegEx-related. I’m actually quite familiar with using RegEx although in my world (or - plug, plug, plug - in PowerGrep’s or EditPad Pro’s world, which I use daily) I’m used to explicitly switching between “Literal text” or “Regular Expression” when matching text.

In PowerGrep like so, which can’t really be misinterpreted:
bild

… and in EditPad like so; on/off and no in-betweens:
bild

I’d go for this “knowing exactly what you’re doing” kind of approach. Having a mix-match of both at the same time is… well, a bit confusing. :blush:

// Rolf


#9

I’ve never seen this pattern before (not familiar with Unix). This only means I would not have figured this one out myself even if I had tried the most common RegEx flavor syntax (see third from top):

// Rolf


(qythium) #10

Yeah, it’s sort of a less powerful but really convenient version of regex which you can use just about anywhere in the bash command shell. Mostly for matching filenames (which don’t need escaping most of the time).