String pattern matching language in Blender and Geometry Nodes

Anything is simplier than regex :slight_smile: So this is not a problem. But language should be “normal” (operators/methods/branching), some obstructive DSL is not viable… imho. and regex can be a part of it without additional overhead (and will be used by users that really need them)

Basically would be great to have a lightweight scripting (that not affect geometry/etc, of course, this is a separate hell). Lightweight and robust.

BTW, just curious, is it possible to use OSL for this? It is already bundled with blender, it is compilable, it is complete, c-like (with simplifications), everything is needed already here. GN engine could mute rendering-related stuff in wrapper, compile user-provided input into executable piece and exec it - just as with rendering. If it is fast for rendering - it is fast for anything, “problem solved”! just kidding… but who knows :slight_smile:

How can a language be ‘simpler than regex’ and still incorporate regex? From a maintainers point of view ‘just regex’ will always be simpler than ‘custom language with regex embedded’, and even from a usermanual pov that would not be simpler.

Just a choice between simple globbing using fnmatch or full regex as ‘advanced’ mode is imho the best solution.

btw @Hadriscus Is that screenshot an example of what you’d like to have? Or warning for how not to do it? :stuck_out_tongue: that monstrosity scares me more than a regexp.

How can a language be ‘simpler than regex’ and still incorporate regex?

i mean regex can be a method/syntax sugar in language, and user may skip it, if regex is not really needed.

your choice means user must be aware of patterns, at least. scripting means user should be aware of scripting syntax. but scripting has much more use cases than regex - and can include regex without extra-efforts for maintainers, that is my point

With “some simple custom language” I meant something between fnmatch and regex in complexity. It’s still supposed to be a pattern matching language, not a full blown programming language with control flow. I’m currently not voting for that option though. I kind of see it as the approach with the most work and least benefit currently.


May main question to @ideasman42 and @brecht right now is whether having a “Paste Escaped” operator in the context menu (as mentioned in my previous post) is enough to overcome the issues with escaping in your opinion. If yes, then being able to switch between exact match and regex is still best to me overall.

4 Likes

I think users even have to be aware of what regex or escape character is makes the functionality quite esoteric. I was programming for many years before I ever had to learn regex, it just seems like a completely different world from Blender users to me.

Mainly I would be convinced by a compelling use case.

I can imagine cases where you have some naming scheme for objects or attributes, give them a particular prefix or suffix and filter by that. If you are in control of that naming scheme, I would hope you don’t design it such that you need full regex to deal with it.

If you are specifically doing text processing in geometry nodes, then I have no problem with a regex node for that. But what are these object names, attribute names, file paths, or other things where you need regex to filter them?

3 Likes

I can at least tell you - from a user perspective: I don’t know regex but I can use that monstrosity and get the results I want and even save patterns for often used things. I totally agree that it could be a lot prettier but it works without learning regex and it even previews the output you’re gonna get.

2 Likes

I like the idea of using regex for string matching but I’m probably biased since it’s relatively easy for me because I had to learn it at some point and use more or less often. I can imagine most users will struggle with it.

Maybe for simple cases some help/docs can be provided with regex recipes. As where advanced users can use regex for complex string matching when needed. Or as was already suggested, allow both fnmatch and regex.

1 Like

I’m in the same position; personally I’d like to see regex support since I’m already familiar with it, but I can see how it would be difficult for someone new to it.

I think that the idea of having examples though is a good one, and potentially having some suggestions of common patterns built in to the regex string property could greatly enhance the usablility:

(These aren’t very imaginative, but it’s the idea that’s important).

5 Likes

Yea, the preview is very valuable, as a way to make sure you did the right thing before committing. It also needs no skill, it’s completely self-explanatory.

I agree and this is the exact same idea as bundled group nodes : snippets to serve as concrete examples of how to use such-and-such feature. Common patterns should be saved and offered to the user by default.

2 Likes