That’s very true, of course. But you would get chance to take one last look. And also, your regex wouldn’t be executed before it is finished being written, which was my overriding concern.
1 Like
Rather than a “go” button, which may still not prevent problems, why not have a limit applied? Say 150 tiddlers. Then if a user is sure they want to see all the results, they can select to “See all tiddlers – this may slow your machine down.” . This way users can use the interface normally 90% of the time, be protected from mistakes, verify that a filter works, and still have complete usability when they need it.
It could be 50,000 operations in just the first tiddler (again, this is your splitter in use, asking it to do something really stupid where it matches “everything”). Then add in just 1,000 tiddlers and you’re going to be there a while… like a week 
It’s not ideal, I agree, but something like the Go! button helps slow me down a notch.
And of course, the point in this thread is about stopping regexes running before they’re finished being written.
Anyway… the ship’s already sailing, I think.
Ciao @Mark_S
Ha! Nice one! Thinking about it, despite @CodaCoder’s caveats, I think that might be a good practical solution in many, if not most, use cases?
I guess, finally, it is an empirical issue. Sad to say I haven’t yet created a regex that locks up mother.
Best, TT
I’m a keen user of regexp and I definitely prefer my expression not being used before I’ve completed it! Especially because my machine is slow! And because it would just be a visual nuisance it it would be a quick machine!
But, when it’s written and executed at least once without having been modified afterwards, I would really appreciate it would be live and auto-updated’ in the usual TW way.
@jypre Agreed, it’s a conundrum. The Go! button solves the former problem, but doesn’t help much after that.
1 Like
@CodaCoder Hum… Let’s see: after clicking on go, I could write a copy of the regexp as a live expression that would do the trick. Any modification in the edit box would immediately delete that live expression and that’s for the second part. It would only necessitate a hook on that edit box.
That’s pretty much how I do it - with a button inside the hook.
@CodaCoder You mean you auto-click your button (with js I suspect) in order to get your hook doing its job? Could you post a source for this? It is of tremendous interest!!!
No, not like that, like this:
input <---> button ---> copy-of-input ---> tiddler-field <---> "live code"
1 Like
Right. It is. Because of the combo of the “liveness” of TW and the potential “recursive dead-end” of incomplete regex OR (even after “Go”) malformed regex that cause near infinite repetitions that don’t resolve.
I did think @Mark_S’ idea to “throttle” (strictly limit the number of input Tiddlers) could be a pragmatic salve in most serious contexts whilst first developing a regex. BUT, I think this would need empirically testing to be sure.
FYI, I’ve been trying to create a regex that causes serious recursion issues but so far have failed at getting to one that causes critical issues 
Just a comment
TT
@TiddlyTweeter If you can’t forge that criminal regexp (complete or incomplete), then this indicate a very low probability of apparition. This is akind to a nuclear war: noone has to manage that kind of risk. You just have to live with it. And prey your gods if you so wish.
1 Like
@CodaCoder I don’t seee what you mean with your double arrows.
And as far as “with a button inside the hook” is concerned, I’m still not getting your clever idea. Regular management of input data finishes in tiddler fields (or indexes) which will make auto-updates for the tiddlers that use them. I did this only to write html so far. Are you telling you are using this to launch further macro?
Something like this perhaps:
<$set name=nextStep filter="[[data]get[flag]match[goForIt]then[celebrate]]">
<$macrocall $name=<<nextStep>> first=<userData>> second=<yetAnotherData>>/>
</$set>
And with the call to the //celebrate// macro be also in the context of a button click? Otherwise, //celebrate// would not be able to have any side effect (except on generating an output).
I believe what make Tiddlywiki crashes, is not the regex pattern entered in Advanced Search, as it is a non-destructive operation! Actually the number of results may be produced and rendering time may cause this happen, so if you have unsaved data, they will be lost! This freezing happened to me a lot of times when I am writing a script in an ordinary tiddler and the preview is open!
I learned just to click on save button before such operation!
1 Like
I tried to convey this:
-
The
live codereads the content oftiddler:field -
The user types into
input -
The user clicks
button -
Button copies
inputintotiddler:field -
Go to 1.
How would a new user know to do that? To “save before experiment?”
A point of the issue is there is a possibility to use regex so it locks the wiki. In my experiments it is rare in ordinary use. But I might be worth in docs for “Search In Fields” mentioning that upfront?
Just a comment
TT
1 Like
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?
As you suggested, I will add recommendation to “Search In Fields” docs.
But this is the way Tiddlywiki behaves! searches are live!
1 Like
Right! Sometimes the aliveness is troubling … 
@Mark_S suggested that limiting the number of Tiddlers searched to, maybe, 150 could be a good idea whilst developing a regex.
Regarding a general regex “watchdog”, I doubt it is good idea or viable. Why? Though TW uses regex extensively, I mean majorly, I think it is uncommon. Most web pages never ever use it. Browser back-end support is good but limited. AFAIK there is virtually no serious backend error tracking for regex? Dunno.
A comment, TT