Been banging my head. I give up. Help!
Consider:
_script.match(/(?:[>%])zz/g);
The “(?:[>%])” should be a non-capturing group, yet it is returned in the result. WTF am I doing wrong?
Thanks.
Solved here:
The first member of the result array is just the entire string over which the pattern was found, and can often be discarded/ignored.
The interesting matches are the following elements of the array, which correspond to the grouping parentheses. So the trick is really to put grouping parenthesis around the part you want:
Thanks.
Funny you should post this right at this time. I just posted this:
which shows how I was able to solve all my issues.
Good !
(Here, as a curiosity, is a similar function, from a slightly different tradition of script construction 
(function () {
'use strict';
// (b -> Maybe (a, b)) -> b -> [a]
function unfoldr(mf, v) {
var lst = [],
a = v,
m;
while ((m = mf(a)) && m.valid) {
lst.push(m.value);
a = m.new;
}
return lst;
}
// Regex -> String -> Maybe [Integer] -> [[String]]
function allMatches(rgx, str, lstIndex) {
return unfoldr(
// String -> [Int] -> (Regex -> (Bool valid, Maybe value, Maybe new))
function (s, lstIndex) {
// Regex -> (Bool valid, Maybe value, Maybe new)
return function (rgx) {
var m = (rgx ? rgx.exec(s) : void 0),
blnMatch = !!m;
return {
valid: blnMatch,
value: blnMatch ? lstIndex.map(function (i) {
return m[i];
}) : [],
new: blnMatch && (0 < rgx.lastIndex) ? rgx : void 0
};
};
}(
str,
lstIndex ? (
lstIndex instanceof Array ? lstIndex : [lstIndex]
) : [0]
),
rgx
);
}
var str = "one two function() three four five six seven";
return allMatches(/([^aeiou ]+)/g, str);
})();
The optional lstIndex argument allows you to specify which match(es) from the array returned by each .exec() event you want to to include in the harvest – to quote from the Mozilla docs re .exec()
The returned array has the matched text as the first item, and then one item for each capturing parenthesis that matched containing the text that was captured
Thanks. Mine’s easier to read. 
That notwithstanding, I finally figured out what your prefix “bln” means - “boolean”. Duh.
Many years ago I used that type of notation, so obviously I could read it with ease. But for the last 10 years or so, I generally haven’t been using abbreviations in variable names, so now I find it very hard to read. In fact, when I look at some of your scripts, I have to paste them into BBEdit and rename the variables, just so I can read them.
I’m a little surprised you use them. Yes, I know, it’s a very common naming convention. But you seem to love helping to educate people, so I would have thought you’d use more descriptive names. No insult intended - I’m EXTREMELY well aware that naming conventions become holy things to most developers, and I don’t want to start a holy war. Just curious, I guess.
Note, however, that I do use prefixes in naming KM variables, but that’s for uniqueness, and being able to tell what variables don’t need to persist.
Anyway, I digress. Thanks.
PS: If I inadvertently insulted or belittled you, I’m truly sorry. But join the crowd - it’s my special gift. 
No problem - 3 consonants just strikes a reasonable balance, for me, between explicit typing and typing speed
No educational claims - to be honest my preference is really for scripts that are disposable, quickly constructed, and moderately bug-safe. I probably don’t pay as much attention to run-time and clarity in scripts as I might with larger or more serious projects.
Well, start! You've got so much knowledge, I want to absorb as much of it as I can! Don't make me work for it! LOL.
Don't make me work for it!
Middle ground perhaps ? I notice that the stone tablets came down from Sinai with consonants only, so one might argue either that vowels are just a lot of hot air, or that problem-solving is memory-forming, or just that there is distinguished literary precedent for rewriting boolean as bln 
(to which, of course, others might counter that had the stone tablets come with vowels, we would all have been better behaved ...)
1 Like
LOL. I give.