I have a search variable that I only need to find one save capture, and the equation is set up that way. When I first made it, the box for search variable on keyboard maestro looked fine. However, I did notice the macro was working slowly after awhile and when I looked again, this particular search variable box has created dozens of (empty) save capture lines for some reason, 127 to be exact. I know this is causing a problem, because when I went into the macro group to look around and clicked on the particular macro with this search variable, keybaord maestro crashed.
By the way, this has happened in the past too in other macros, and I've never figured out what causes it. It does happen rarely, but it does happen. In this instance, the expression I'm searching for is basically "%b%\n%c%\n%d%\n%e%\n(\d)", and basically saving to variable f. Here are screenshots of the top of the box, and just to show how long it goes, the very bottom (the entire thing is too long to show in its entirety).
I may not be able to help if it's a bug in KM, since I'm just a regular user, but I'm trying to replicate your situation. You showed enough of the macro to replicate that, but you didn't show what the variable z contains. I'm not getting 127 variables lines like you are. So I can't replicate it.
Are you able to replicate this behaviour on demand?
No, I can't do it on demand exactly for this one. At other times in other macros, it has come and won't leave. This one wouldn't leave when I wrote the first post, but is gone now that I'm checking it just at this moment (and for now; it might return). It doesn't matter what is in the variable. It happened when all the variables were empty, and just to be sure I emptied them again. I even created another search variable in the same macro and put in the same equation, and it created the 127 lines again.
Do you want us to find a different regular expression that's less likely to cause the issue? Or are you just pointing this out to help KM's author remove possible bugs, which is okay too.
Do the variables you're including in your search contain digits? If not, you could probably just search z for (\d) or (?<=\n)\d and get what you need without making KM search for other variables. If they do contain digits, you could use a For Each Substring action as an alternative, which might perform better with whatever data you're using that's causing this to happen:
If you're looking for an answer as to why this is happening and how to prevent it, you'll need to share what sort of data is in all these other variables you're searching, and the kind of data you're trying to capture.
@Sleepy Well, I'm not sure. I'd like to figure out what causes it specifically. I'd like to know what causes more than anything so I can prevent it in the future.
@gglick The other variables can contain digits, and there are other lines with digits. This search is looking for a specific match or lines. I'm not sure what "(?<=\n)" is exactly but I'll look into it; I don't know what the "<=" is exactly. Also, I have a hazy understanding of For Each substrings so I'll look into that too. Your example I'm not understanding exactly but I'll look closer at it; thanks.
@JMichaelTX I didn't restart the Mac, but I restarted the engine multiple times (I often have to anyway in a normal day to keep it running smoothly). It's not doing that behaviour now, though it was for awhile when I first posted. I did restart my engine, and it crashed so it restarted then too.
There are two wizards helping you now, so let's see what the say. I can't help much anymore because you indicated you weren't really interested in workarounds, just getting it fixed. One of them was suggesting a workaround for you, which you said you would investigate, which tells me that maybe you are interested in workarounds. If something is broken, being able to replicate it is quite important.
(?<=) is regex lookbehind syntax. In other words, it looks for a match that comes after whatever you specify inside it (a new line, in (?<=\n)'s case) but doesn't include it in the match itself. If you search
Lorum Ipsum
3
for \n\d without lookbehind, the match returned will be
3
because the search included the new line. But if you search for (?<=\n)\d, the match returned will be
3
This makes it very useful for obtaining data you want and leaving out data you don't want.
As for the substring example I showed you, it essentially takes the first instance of text in your z variable that matches your regex, puts it into its own variable called LocalMatch, then searches that variable for the digit that comes at the end and saves it to f. This should get the same result as the Search Using Regular Expression action, but without repeating the search in whatever way that's causing KM to spawn multiple capture fields.
Peter, to be clear, I assume by "search field" you mean the field where the RegEx pattern is entered, correct?
Having this field show only one line has occasionally caused me to have a very confusing problem, one that is very hard to debug. All of the other RegEx tools (BBEdit, Regex101.com for example) that I have used always autoexpand the RegEx pattern field to show as many lines as is needed to show the entire pattern.
Perhaps you could add this as a Feature Request to your list. Nothing urgent, but it would certainly be very nice to have.
