Heiko wrote:This feature is already included. Chose the logical and trigger option and set line delta to 0. The trigger will only match if all conditions on the list are true on the same line.
Then how do I make a multi-line trigger that explicitly _doesn't_ match on the same line? As an example, say I want to colour the line immediately following "Line 1". I can make a multiline trigger that has condition 1 as an exact match for "Line 1", and then I can make condition 2 be a regex "^(.*)$", and I can colour that capture group. But it doesn't work, because condition 2 is always checked against the same line that matches condition 1. The workaround I'm using right now is to have one trigger match "Line 1" and create a temporary line trigger that will enable a second trigger. Then the second trigger will colour, or chain, or whatever--and disable itself every time it fires. (Actually, that's one of about eight different workarounds I've tried, and only one of about three that work and I currently use.)
Heiko wrote:This feature is also included. Substring and begin of line substring patterns always pass the pattern itself as matches[1] as there is no way in the pattern syntax to specify capture groups.
Color triggers always pass all characters that have the specified trigger color as capture groups.
Consequently, you want to use perl regex patterns. If you use a pattern like this:
(?:cobble) (?:stone) (road) you define 3 capture groups, but the ?: at the beginning of capture group #1 and #2 indicates that these capture groups are not supposed to capture anything. As a result capture group #3 i. e. (road) will be passed as the only capture group to the table matches or pass the filter if you use the trigger as a filter.
But what if I need to capture cobble and stone to do something with? Like with the prompt example: the pattern is "^^(\d+)h, (\d+)m, (\d+)e, (\d+)w", to catch health/mana/etc, and that chained to a second trigger: "^\d+h, \d+m, \d+e, \d+w (.*)", which filtered to a bunch of others to catch whether you have balance, etc. The whole thing could be simplified to just one filter if you could specify a way to pass only the fifth capture group (matches[6]) on to the filter's children. This one isn't a big problem for me, because when it comes right down to it, I can use that workaround or just ignore it and let the children fire on all matches (which is usually harmless). But it'd be nice.
Heiko wrote:This is actually something I'd like to do myself very much, but so far I couldn't find a suitable graphical representation of the problem that would be efficient enough for the user to be useful without being utterly confusing. If you have a good idea of how exactly this should look like, please let me know.
Right now you have to resort to using more complex regex patterns to solve this sort of problem.
I was thinking about it, and
this is all I've got at the moment. The ugly colours are just to show where the boxes would go, of course. The idea is that each sub-condition is collapsable and name-able. So, for instance, if I click on the yellow OR box, lines 1 and 2 will collapse together. The pattern type dropdown will change to a dropdown where you select between "OR" and "AND" (and possibly other logical operators). And in a clearly different font, the pattern field will say "subcondition 5", or a simple default like that, and you can just type in there to rename that subcondition.
As for how to create the subconditions, maybe put "OR" and "AND" in the pattern type all the time, and if you select them, the line will immediately change to a collapsed subcondition. Then as long as it's smart enough to recognise that (A or (B or C)) can be reduced to (A or B or C), it should work okay.
It's not perfect, but I think it's functional. But maybe it just seems unconfusing to me because I actually drew it.