I've been trying to use the tempComplexRegexTrigger, but I run into a problem every time. The name it returns is actually the pattern given, rather than the name argument. I wouldn't normally care, but it prevents me from adding a second line (to make a multiline trigger) unless I want each line to be using the same regex pattern. I tried just ignoring it and seeing what would happen, and it just makes a "multiline" trigger for each pattern I try to add, each acting on just that line, and rather than the lines all working together like they should.
Is this a known/fixed issue in the coming release? Also, is there any way around this at present (in 2.1)?
Thanks.
tempComplexRegexTrigger Broken?
Re: tempComplexRegexTrigger Broken?
This is more or less what happens, not a stance on what is right or wrong:
The first argument is the parent, which if found will be added under it. The name of the current trigger is set to the pattern.
So to add something, you would want to do:
tempComplexRegexTrigger("level 1", pattern and other stuff)
tempComplexRegexTrigger(pattern_as_parent, pattern and other stuff)
This is fairly obtuse, but it is an issue because there is no restriction on triggers having the same name. I think an API redesign is really what is called for here, and given that the current implementation is actually broken, maybe tempComplexRegexTrigger should be changed instead of a new fixed function added.
So some questions:
Given that trigger names are not unique -- how to best proceed? How can we unambiguously identify a trigger.
Should a unique name be an added argument?
Should we return trigger ID #'s that are guaranteed to be unique through some indexing scheme?
Other solutions?
The first argument is the parent, which if found will be added under it. The name of the current trigger is set to the pattern.
So to add something, you would want to do:
tempComplexRegexTrigger("level 1", pattern and other stuff)
tempComplexRegexTrigger(pattern_as_parent, pattern and other stuff)
This is fairly obtuse, but it is an issue because there is no restriction on triggers having the same name. I think an API redesign is really what is called for here, and given that the current implementation is actually broken, maybe tempComplexRegexTrigger should be changed instead of a new fixed function added.
So some questions:
Given that trigger names are not unique -- how to best proceed? How can we unambiguously identify a trigger.
Should a unique name be an added argument?
Should we return trigger ID #'s that are guaranteed to be unique through some indexing scheme?
Other solutions?
Re: tempComplexRegexTrigger Broken?
So, are you saying that I can do the following to create a single temp trigger with multiple pattern lines:
Or does it instead create a tree of triggers, each firing independently?
Re: tempComplexRegexTrigger Broken?
more like:
Re: tempComplexRegexTrigger Broken?
To test this, I used the following lines of code:
When I tried the same thing with both being given "unique_name" for the parent argument, I saw one table with pattern1 and one with pattern2, though they remained separate tables (implying they fired as independent triggers).
Am I doing something wrong here?
I then used feedTriggers("\npattern1\npattern2\n") and saw two tables displayed, each with "pattern1" as the only match (obviously there were two copies, for matches[1] and matches[2]).
When I tried the same thing with both being given "unique_name" for the parent argument, I saw one table with pattern1 and one with pattern2, though they remained separate tables (implying they fired as independent triggers).
Am I doing something wrong here?