One of my filters I've been using successfully without a hitch since I bought TextPipe Standard 7.9.5 in August has suddenly stopped working after I upgraded to version 8.0 and installed it in accordance with instructions.
The filter just stops at a certain number (98,304) of bytes, and I have to Cancel.
Since emailing Simon, I have isolated the problem to be somewhere within the following lines:
I have now isolated the problem to the search filter action "Send matching text to subfilter".
98,304 in decimal is 18000 in hexadecimal.
That this is a round number in hex strongly suggests that this is a software bug.
Changing both the external replace list files to imported replace lists made no difference to the bug, nor did changing the search pattern to an equivalent expression.
If you make a simple filter in which a comment has a replace list as a subfilter, then if you export the filter to clipboard, only the first row of the replace list is indented as part of the subfilter. The remaining rows are NOT indented, but are in the same level as the comment.
|--Comment...
| | Miscellaneous punctuation corrections
| |
| +--Replace [..] with [.]
| [ ] Match case
| [ ] Whole words only
| [ ] Case sensitive replace
| [ ] Prompt on replace
| [ ] Skip prompt if identical
| [ ] First only
| [ ] Extract matches
Replace [!.] with [!]
| [ ] Match case
| [ ] Whole words only
| [ ] Case sensitive replace
| [ ] Prompt on replace
| [ ] Skip prompt if identical
| [ ] First only
| [ ] Extract matches
Replace [.,] with [,]
| [ ] Match case
| [ ] Whole words only
| [ ] Case sensitive replace
| [ ] Prompt on replace
| [ ] Skip prompt if identical
| [ ] First only
| [ ] Extract matches
Replace [,.] with [.]
| [ ] Match case
| [ ] Whole words only
| [ ] Case sensitive replace
| [ ] Prompt on replace
| [ ] Skip prompt if identical
| [ ] First only
| [ ] Extract matches
This could be the real bug. For this example, the comment being the parent, it has no effect. However, if the parent was a restrict filter, the effect would be very significant. The same bug might just as well apply to a replace list from an external file as to an internal replace list. This observation matches the symptoms.
I just tried something similar with the earlier version of TextPipe that is installed in my computer at work. Version 7.1.7 is a few years old.
The same issue affects a replace list subfilter of (for example) a restrict filter.
|
|--Comment...
|
|--Restrict lines:Line 8 .. line 18
| |
| +--Perl pattern [A] with [Z]
| [ ] Match case
| [ ] Whole words only
| [ ] Case sensitive replace
| [ ] Prompt on replace
| [ ] Skip prompt if identical
| [ ] First only
| [ ] Extract matches
| Maximum text buffer size 4096
| [X] Maximum match (greedy)
| [ ] Allow comments
| [ ] '.' matches newline
| [X] UTF-8 Support
Perl pattern [B] with [Y]
| [ ] Match case
| [ ] Whole words only
| [ ] Case sensitive replace
| [ ] Prompt on replace
| [ ] Skip prompt if identical
| [ ] First only
| [ ] Extract matches
| Maximum text buffer size 4096
| [X] Maximum match (greedy)
| [ ] Allow comments
| [ ] '.' matches newline
| [X] UTF-8 Support
Perl pattern [C] with [X]
| [ ] Match case
| [ ] Whole words only
| [ ] Case sensitive replace
| [ ] Prompt on replace
| [ ] Skip prompt if identical
| [ ] First only
| [ ] Extract matches
| Maximum text buffer size 4096
| [X] Maximum match (greedy)
| [ ] Allow comments
| [ ] '.' matches newline
| [X] UTF-8 Support
|
Every row in the replace list table should be indented below the restrict filter, rather than as shown above.
Either the filter itself must be significantly in error, or the export to clipboard feature must be in error. If it turns out to be merely the latter, then please raise as a separate issue.
While DataMystic are still working towards a solution, I have re-installed version 7.9.5 in place of version 8.0 - so that I can continue using the filter as before.
Status: This bug was found to be due to the inefficient use of filters. In particular, the title attribute of every tag (and not just the div2 tag) was being checked for
\w\w\w (ie 3 word characters)
without the whole word option, which led to a lot of backtracking, and this was in turn searched against a replace list of 30 items.
A div2 tag restriction around the whole lot returned performance to previous levels.
