Noodlesoft Forums

I have a rule that has multiple conditions, and I want to be able to setup custom patterns and reuse them in each condition.

This is related to my previous post here:
viewtopic.php?f=4&t=2113

The solution was to have a (•Name 1), (•Name 2), (•Code 1), and (•Code 2) custom patterns. This is fine when there are limited conditions, but I need to build up many conditions, and then rename the file based on that. With all these conditions, my rename action becomes very ugly looking because I need to specify all the custom patterns (•Name 1)...(•Name N) and (•Code 1)...(•Code N)

It would be nice if I could reuse the custom patterns, and the values get set to the matching condition, and any custom pattern that isn't in the condition are just set to the empty string.

This is something I've been thinking about but there are several possible ways to do it.

Say we have a pattern called "pattern" and two conditions like:

Code: Select all

If (all) match
    Name matches "(some other pattern)(•pattern)(...)"
    Name matches "(yet another pattern)(•pattern)(...)"


Now, both conditions match and "pattern" can match and capture different text. How does it deal with this?

(a) It matches the first one. Subsequent uses of that pattern have to match the text that was captured from the first one.
(b) It matches and captures the first one. Subsequent uses of that pattern will use that pattern but will not capture text.
(c) It matches all and captures the text from the last match.
(d) Something more random.

Now, personally, I'd prefer case (a) because that allows you to do cool things like:

Code: Select all

If (all) match
    Name matches (•blah)
    Extension is "bleh"
    If (all) match for (enclosing folder)
        If (all) match for (any sub-file)
            Name matches (•blah)
            Extension is "boo"


What this does is match a file with a "bleh" extension if there exists a sibling file with the same name with a "boo" extension.

While your case with "any" is more straightforward (it would just match and capture the first one), I need to handle other cases like the above.

It would be cool (though maybe complicated?) to have the following:

1) for each rule, have a list of patterns that are "captured". by default, the list of captured patterns would be all the patterns in the rule (so by default it would act like option (c)). But you can remove patterns from the captured list which will mean the pattern will need to be matched, but you won't update the captured value (so you could do something like option (a)).

2) introduce a pattern capture reference. So now we have (•pattern) to match (and possibly capture) the pattern, but add a (=pattern) reference so that it uses whatever captured value you currently have in (•pattern).

So your example could be something like:

Code: Select all

If (all) match
    Name matches (•blah) [and captures blah]
    Extension is "bleh"
    If (all) match for (enclosing folder)
        If (all) match for (any sub-file)
            Name matches (=blah)
            Extension is "boo"


I don't think this is too complicated, it explicitly conveys what the rule is trying to do without people having to know the underworkings of hazel.

Your first example could be any of the following:

Code: Select all

If (all) match
    Name matches "(some other pattern)(•pattern)(...)" [and captures pattern]
    Name matches "(yet another pattern)(•pattern)(...)" [and captures pattern]
Rename file (=pattern)


- this would be the default behaviour and rename the file to the second pattern match

Code: Select all

If (all) match
    Name matches "(some other pattern)(•pattern)(...)"
    Name matches "(yet another pattern)(•pattern)(...)" [and captures pattern]
Rename file (=pattern)


- this would also rename the file to the second pattern match

Code: Select all

If (all) match
    Name matches "(some other pattern)(•pattern)(...)" [and captures pattern]
    Name matches "(yet another pattern)(•pattern)(...)"
Rename file (=pattern)


- this would rename the file to the first pattern match

This would mean that the matching, capturing, and referencing the results of a pattern need to be separated out into separate things. But perhaps there is an easier way to do this?

I guess another way to do this, is on the (•pattern) context menu have a behaviour option which you can select from the following three options:

1) match using pattern and capture result
2) match using pattern and don't capture result
3) match using previously captured result

The =pattern idea is interesting; I'll have to think about it some. Overall, though, I'm trying to keep things simple. I want to avoid extra interface in managing these patterns, for instance. I think it might be too tweaky to have to choose which version of the pattern gets precedence in a match. I'd rather keep it simple by having a rule that says either the first or last one gets the captured value and you'd order your conditions to take that into account.

Having a rule where it either uses the first match or the last seems like it would be more confusing. At least to me. I think I would be forever looking this up in the help. "Does it keep the first match or the last?" You can make a valid argument for both, so I would never remember which. If it was configurable (via the context menu), or if the pattern matching was separate from getting the last pattern match (via the (=pattern)) then I wouldn't need to look it up in help as it would be clear. I've always been a fan of writing software with sane default behaviour, but also allowing the user to customize if they so choose.

That's just my 2 cents though. Perhaps you could have a poll and see what the user's would like?

Overall, I think Hazel is great, and the sooner I could get this feature added the happier I will be!

I'm not sure if adding more configuration options is the best thing here. As for a poll, I'd prefer if people came up with specific use cases instead of designing the feature as I find there's a huge gap between the two (i.e. what the user wants to do won't be addressed, or addressed badly, by their proposed solution). If you have specific cases, post them here as that will be far more persuasive (and may result in a totally different solution).

This is a bit of a tangent to this conversation, but I think it would be very convenient to save custom tokens for use across multiple rules.