And…
- ignoring it
- hoping it won’t happen
- saying it can be worked around
- or any other bloody-minded approach
is foolish to oneself and others. There. I said it.
Moving on…
@TiddlyTweeter TT, I saw your message about trying to think of a hang-causing regex… one that gets me more often than not, is a completely empty regex. Yes, I know that can be easily worked around, usually. However, I’m struggling to find a nice optimal way to guard against this one.
I will find an optimum way, just having to live with it a while longer until it reveals itself.
Here’s how it surfaces…
It’s a setting in BK-TW. The setting is used in the (new to you) Writing Supervisor. The WS can be enabled/disabled in the UI. When active, common grammatical issues are highlighted in the preview pane, live, as you type in the editor.
The user can specify a set of HTML elements to be excluded from a certain “rule” within WS. Looks something like this:
\<(?!(bk-ann|bk-note|bk-problem|inset|interjection|
br|div|h1|h2|h3|hr|p|span|
|red|orange|blue|green|dull|done))[a-zA-Z0-9_\-]+>(?!\n\n)
Because this part of the regex is subsumed by the much larger WS ruleset regex, it’s not so easy to if-and-but it. Follow?
My current thinking is to disable WS completely if it’s blank – because if it is blank and the preview is open on a large tiddler (chapsec) maaan it can take ages to resurface the wiki (first move then, close the damned editor).
The specific TW code in use at the time it receives the empty setting is:
search-replace:g:regexp<var1>,<var2>search-replace:g:regexp<var3>,<var4>search-replace:g:regexp<var5>,<var6>(and so on for about a hundred or so times)
And only ONE of them might be empty to bring it all crashing to a halt. Like I said, I can’t if-and-but in the middle of that, so I think I’ll need to “if” at the very outset, unless…
someone knows a better way?