{"id":486811,"date":"2026-07-09T18:32:26","date_gmt":"2026-07-09T18:32:26","guid":{"rendered":"https:\/\/savepearlharbor.com\/?p=486811"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=486811","title":{"rendered":"Atomic Regular Expressions"},"content":{"rendered":"
\n

In this series of articles, we explore the capabilities of the AutoHotkey<\/a> language by demonstrating how to output colored text to the terminal for the Launcher<\/a> console utility. <\/p>\n

Part 1: Naive algorithm and its optimization<\/a>
Part 2: Control sequences<\/a>
Part 3: Atomic Regular Expressions (you are here)
Part 4: Declarative Programming
Part 5: 256 Colors and Text Styling<\/p>\n

In the previous part, we learned about control sequences and how to apply them in our algorithm to change the color of text. In this article, we will explore some of the capabilities of regular expressions that will allow us to change the color of an entire text region.<\/p>\n

If you are not familiar with regular expressions at a basic level, I recommend reading this article<\/a>. If you are not familiar with the AutoHotkey syntax, I recommend reading the first part<\/a>. However, this is not necessary to understand this article \ud83d\ude09<\/p>\n

Constructing Expressions<\/h3>\n

Paired Characters<\/h4>\n

In the previous part, we wrote an algorithm for processing character pairs: \" \"<\/code> or * *<\/code>. We pass the intermediate array aRegexColor<\/code> consisting of \u201ccharacter-color\u201d pairs, convert it into a HashMap chrColors<\/code> containing \u201ccharacter-code\u201d pairs, and then search for each pair and add the corresponding character from chrColors<\/code> before the opening character:<\/p>\n

Color(msg, aRegexColor) {    static colors := Map(        'black',    30,        'red',      31,        'orange',   33,        'magenta',  35,        'gray',     90,        'crimson',  91,        'green',    92,        'yellow',   93,        'blue',     94,        'purple',   95,        'cyan',     96,    )        static esc := Chr(27)    static end := esc '[0m'        regex     := '' ; final regular expression    chars     := '' ; character string    chrColors := Map()        index := 1    loop (aRegexColor.length \/ 2) {        ; `aRegexColor` - input array of \"char-color\" pairs        str   := aRegexColor[index++]        color := aRegexColor[index++]            chars .= str        chrColors[str] := colors[color]  ; `colors` - HashMap of \"color-code\" pairs    }        if chars        regex .= '([' chars '])'    else        regex := regex.RTrim('|')            stack := []    while (pos <= len) {        if !RegExMatch(msg, regex, &match, pos) {            ; Remaining text            clrMsg .= msg.Slice(pos)            break        }                ; Normal text before the found character        clrMsg .= msg.Slice(pos, match.pos - pos)        ; Move forward        pos := match.pos + match.len                if (stack.Has(-1) && stack[-1] = match[1]) {            clrMsg .= match[1] . end            stack.Pop()        } else {            begin  := esc '[0;' chrColors[match[1]] 'm'            clrMsg .= begin . match[1]            stack.Push(match[1])        }    }        return clrMsg}<\/code>
<\/a><\/div><\/pre>\n
RegExMatch<\/a> searches for characters from the set (e.g., [\"*]<\/code>) and stores one of the found characters in match[1]<\/code>. As a result, the algorithm processes one character per iteration. This allows us to correctly highlight text inside paired characters: \"text and text\"<\/code>. It also highlights text inside that text: \"text *and* text\"<\/code>.<\/p>\n
<\/figure>\n
However, we have a more complex help message in which we need to highlight specific constructs: --switches<\/code>, @file<\/code>, and variables like %AhkDir%<\/code>. We need to improve the algorithm and add the ability to work with entire expressions, rather than just individual characters.<\/p>\n
<\/figure>\n
Key-Value<\/h4>\n
In the algorithm above, we passed a \u201ccharacter-color\u201d array, where the key<\/em> is a character and the value<\/em> is a color code:<\/p>\n
msg.Color([   '\"',  'cyan',  '*',  'green'])<\/code>
<\/a><\/div><\/pre>\n
This array was converted to chrColors<\/code>:<\/p>\n
\" 96* 92<\/code>
<\/a><\/div><\/pre>\n
As a result, we could call chrColors['\"']<\/code> or chrColors['*']<\/code>, where each character served simultaneously as a search pattern (the regular expression, the regex<\/code> variable), the matched character (the match[1]<\/code>), and a key in chrColors<\/code>.<\/p>\n
Now we\u2019re going to pass \u201cexpression-color\u201d pairs (for simplicity, let\u2019s temporarily forget about characters):<\/p>\n
msg.Color([  '(@(file|list\\.ini))',    'yellow',   ; list  '(mainDir|AhkDir)(?=\\=)', 'purple',   ; variables names  '(%[^%]+%)',              'blue',     ; variables values  '(\\-+[\\-\\w]+)(?=[ =])',   'cyan',     ; switches])<\/code>
<\/a><\/div><\/pre>\n
With this approach, each expression can no longer serve as both a search pattern and a matched expression (text) at the same time, and therefore cannot be a key in chrColors<\/code>.<\/p>\n
Every regular expression we pass to RegExMatch<\/a> is plain text. On its own, it doesn\u2019t search for anything; instead, it is first compiled into a set of instructions for the processor. In other words, Regular Expressions is something that we can call a low-level language that can be compiled, where every character, such as \\w<\/code>, is converted into a specific instruction.<\/p>\n
In our case, this means that an expression like (%[^%]+%)<\/code> is converted into code that searches for a text like %AhkDir%<\/code>, %mainDir%<\/code>, and so on. In other words, the input ((%[^%]+%)<\/code>) is not equal to the output (%mainDir%<\/code>), and as a result, information about the original regular expression itself — which allowed us to apply the desired color to the found text — is lost. Consequently, the expression itself cannot serve as a key in chrColors<\/code> to retrieve the color.<\/p>\n
Mark<\/h4>\n
As you may have noticed earlier, the match<\/code> variable is somewhat similar to an array: match[0]<\/code> stores everything that was found, and match[1]<\/code> stores what capturing group 1 found. However, it is actually a match\u00a0object<\/strong>, and it stores not only indices<\/em> but also fields<\/em>: match.pos<\/code>, match.len<\/code>, match.count<\/code>. It also has a mark<\/code> field. When RegExMatch()<\/code> encounters the (*MARK:..)<\/code> construct<\/a> in the pattern, the mark<\/code> field takes on the value following the colon :<\/code> For example, after (*MARK:chr)<\/code>, the value of match.mark<\/code> will be \"chr\"<\/code>.<\/p>\n
Let\u2019s look at another expression:<\/p>\n
(%[^%]+%)(*MARK:1)|(~[^~]+~)(*MARK:2)<\/code>
<\/a><\/div><\/pre>\n
If group 1<\/em> is captured, match.mark<\/code> will be equal to \u201c1\u201d. If group 2<\/em> is captured, match.mark<\/code> will be equal to \u201c2\u201d.<\/p>\n
We can use this feature to mark<\/em> (index) the patterns: 1, 2, 3, \u2026 Each pattern will have a unique mark<\/em>, a unique key that we\u2019ll use to retrieve the color from chrColors<\/code>:<\/p>\n
begin  := esc '[0;' chrColors[match.mark] 'm'clrMsg .= begin . match[1]<\/code>
<\/a><\/div><\/pre>\n
To do this, we need to add mark<\/em> with the corresponding index to the end of each pattern in the aRegexColor<\/code> array, and then combine all the patterns into a single regular expression using the OR operator |<\/code><\/p>\n
regex     := '' ; final regular expression    chars     := ''     ; separate expression with chars    chrColors := Map()        index     := 1; array index    idxColor  := 1  ; mark index        loop (aRegexColor.length \/ 2) {        str   := aRegexColor[index++]        color := aRegexColor[index++]        if (str.length = 1) {            ; Characters are grouped into set like [\"*\"]            chars .= str            chrColors[str] := colors[color]; char-code        } else {            ; Group patterns into one            regex .= str '(*MARK:' idxColor ')|'             chrColors[String(idxColor++)] := colors[color]  ; index-code        }    }        if chars        regex .= '([' chars '])(*MARK:chr)'  ; Add the characters separately at the end    else        regex := regex.RTrim('|') ; Remove the extra OR |<\/code>
<\/a><\/div><\/pre>\n
The result will be a single large expression like (..)(*MARK:1)|(..)(*MARK:2)|...|([..])(*MARK:chr)<\/code>. For convenience, we\u2019ll use the same HashMap that contains \u201cindex-code\u201d pairs and the \u201ccharacter-code\u201d pairs we\u2019re already familiar with:<\/p>\n
    \n
  1. \n
    Expressions: the key is match.mark<\/code> (index).<\/p>\n<\/li>\n
  2. \n
    Characters: the key is the character itself, match[1]<\/code>.<\/p>\n<\/li>\n<\/ol>\n
    Since each expression (whether a character<\/em> or an indexed expression<\/em>) has a different key, we need to distinguish between indexed expressions<\/em> and character expressions<\/em> using (*MARK:chr)<\/code>:<\/p>\n
            if (match.mark != 'chr') {            ; Indexed expression: wrap in color            begin  := esc '[0;' chrColors[match.mark] 'm'            clrMsg .= begin . match[1] . end            continue        }        ; Character expression        if (stack.Has(-1) && stack[-1] = match[1]) {            clrMsg .= end            stack.Pop()        } else {            begin  := esc '[0;' chrColors[match[1]] 'm'            clrMsg .= begin            stack.Push(match[1])        }<\/code>
    <\/a><\/div><\/pre>\n
    Branch Reset<\/h4>\n
    The constructed expression has a critical flaw: it has many capturing groups. As a result, each captured text fragment will be associated with its own capturing group: 1, 2, \u2026<\/p>\n
    Let\u2019s look at this code snippet:<\/p>\n
    \"%variable% is ~gray~\".Color([    '(%[^%]+%)', 'blue',     '(~[^~]+~)', 'gray'])<\/code>
    <\/a><\/div><\/pre>\n
    Color<\/code> will construct the expression:<\/p>\n
    (%[^%]+%)(*MARK:1)|(~[^~]+~)(*MARK:2)<\/code>
    <\/a><\/div><\/pre>\n
    which contains 2 capturing groups:<\/p>\n
    \n
    \n\n\n\n\n\n
    \n
    Index<\/p>\n<\/th>\n
    		\n
    Group<\/p>\n<\/th>\n
    		\n
    Text<\/p>\n<\/th>\n<\/tr>\n
    \n
    1<\/p>\n<\/td>\n
    		\n
    (%[^%]+%)<\/p>\n<\/td>\n
    		\n
    %variable%<\/p>\n<\/td>\n<\/tr>\n
    \n
    2<\/p>\n<\/td>\n
    		\n
    (~[^~]+~)<\/p>\n<\/td>\n
    		\n
    ~gray~<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n
    Accordingly, the text ~gray~<\/code> will be stored in match[2]<\/code>, while match[1]<\/code> (which we use in the algorithm) will be empty. In other words, we need to know the group\u2019s index to retrieve the text. But if the user has included multiple groups in each pattern, such as =(%([^@](\\w+))%)<\/code>, it will be difficult to determine the index. We want the text or character to always be stored in match[1]<\/code>.<\/p>\n
    To solve this problem, we can use Branch Reset<\/a>. Branch Reset is a (?|..)<\/code> construct, which makes the index of each group relative. If we represent the expression ()|()|...<\/code> as a list of items separated by |<\/code>, then the index of each capturing group within each item will be relative to that item:<\/p>\n
    ( () )|( () () )1  2   1  2  3 <\/code>
    <\/a><\/div><\/pre>\n
    In other words, we don\u2019t look at the entire expression, but rather to its individual items, and then at groups within those items. Without Branch Reset, indexing is absolute:<\/p>\n
    ( () )|( () () )1  2   3  4  5 <\/code>
    <\/a><\/div><\/pre>\n
    Let\u2019s wrap the constructed expression in (?|..)<\/code>:<\/p>\n
    (?|(%[^%]+%)(*MARK:1)|(~[^~]+~)(*MARK:2))<\/code>
    <\/a><\/div><\/pre>\n
    It is important to understand that (?|..)<\/code> is not a capturing group, but a \u201cBranch Reset\u201d construct. And (*MARK:..)<\/code> is a \u201cverb\u201d (verb<\/strong>). The parentheses are merely part of the syntax.<\/p>\n
    As a result, we end up with the following indexing:<\/p>\n
    \n
    \n\n\n\n\n\n
    \n
    Index<\/p>\n<\/th>\n
    		\n
    Mark<\/p>\n<\/th>\n
    		\n
    Group<\/p>\n<\/th>\n
    		\n
    Text<\/p>\n<\/th>\n<\/tr>\n
    \n
    1<\/p>\n<\/td>\n
    		\n
    1<\/p>\n<\/td>\n
    		\n
    (%[^%]+%)<\/p>\n<\/td>\n
    		\n
    %variable%<\/p>\n<\/td>\n<\/tr>\n
    \n
    1<\/p>\n<\/td>\n
    		\n
    2<\/p>\n<\/td>\n
    		\n
    (~[^~]+~)<\/p>\n<\/td>\n
    		\n
    ~gray~<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n
    match[1]<\/code> will always contain the captured text from the 1st, 2nd, or 3rd group. At the same time, match.mark<\/code> will still store the correct index:<\/p>\n
        if chars        regex .= '([' chars '])(*MARK:chr)'    else        regex := regex.RTrim('|')    regex := '(?|' regex ')'<\/code>
    <\/a><\/div><\/pre>\n
    Color Switching<\/h4>\n
    Currently, our algorithm simply wraps the found text fragment in the opening and closing colors:<\/p>\n
         static esc := Chr(27)     static end := esc '[0m'         if (match.mark != 'chr') {            ; Indexed expression: wrap in color            begin  := esc '[0;' chrColors[match.mark] 'm'            clrMsg .= begin . match[1] . end            continue        }<\/code>
    <\/a><\/div><\/pre>\n
    However, as you may remember from the previous part<\/a>, control sequences \u201ctoggle\u201d colors:<\/p>\n
    \\e[96m\"  <- own color# level 1text     \\e[92m*   <- own color   # level 2    and    *\\e[96m    <- previous color   text\"\\e[0m   <- no previous color<\/code>
    <\/a><\/div><\/pre>\n
    The closing color of each pair of characters depends on the nesting level of that pair. That is why we use a stack<\/em> to keep track of which color to apply: the opening color (the begin<\/code> variable) or the closing color \\e[0m<\/code> (the end<\/code> variable).<\/p>\n
    The closing color does not depend on anything in the current algorithm. The text region is simply wrapped in color, and then the color is reset to white using \\e[0m<\/code>.<\/p>\n
    <\/figure>\n
    However, it would be more correct to check whether we are inside a pair of characters (e.g., \" \"<\/code>) and switch the color to the previous one, opened by the paired character:<\/p>\n
            if (match.mark != 'chr') {            ; We take the `begin` color from chrColors            begin  := esc '[0;' chrColors[match.mark] 'm'            if (stack.Has(-1)) {                ; Within a pair, we look for the closing color                 ; using the \"key\" from the stack                _end := esc '[0;' chrColors[stack[-1]] 'm'                clrMsg .= begin . match[1] . _end            } else {                ; Independent - close the color                clrMsg .= begin . match[1] . end            }            continue        }<\/code>
    <\/a><\/div><\/pre>\n
    <\/figure>\n
    As a result, the algorithm, whose source code is available on GitHub<\/a>, looks like this:<\/p>\n
    ; Define add. method for readability({}.DefineProp)(String.prototype, 'Match', {call: RegExMatch})Color(msg, aRegexColor) {; The color name corresponds to the color code    static colors := Map(        'black',    30,        'red',      31,        'orange',   33,        'magenta',  35,        'gray',     90,        'crimson',  91,        'green',    92,        'yellow',   93,        'blue',     94,        'purple',   95,        'cyan',     96,    )        ; Constants    static esc := Chr(27)    static end := esc '[0m'; Transform the input array    regex     := ''    chars     := ''    chrColors := Map()    chrColors.capacity := aRegexColor.capacity        index     := 1    ; array index    idxColor  := 1    ; mark index        loop (aRegexColor.length \/ 2) {        str   := aRegexColor[index++]        color := aRegexColor[index++]        if (str.length = 1) {            ; Group chars into a set [..]            chars .= str            chrColors[str] := colors[color]    ; char-code        } else {            ; Group atomic patterns using OR |            regex .= str '(*MARK:' idxColor ')|'             chrColors[String(idxColor++)] := colors[color]    ; index-code        }    }        if chars        regex .= '([' chars '])(*MARK:chr)'    else        regex := regex.RTrim('|')            ; Apply Branch Reset    regex := options '(?|' regex ')'            ; Color the message    pos := 1    len := msg.length    clrMsg := ''        stack := []    stack.capacity := aRegexColor.capacity * 2    while (pos <= len) {        if !msg.Match(regex, &match, pos) {            ; Remaining text            clrMsg .= msg.Slice(pos)            break        }                ; Regular text before the match        clrMsg .= msg.Slice(pos, match.pos - pos)        ; Move forward        pos    := match.pos + match.len                if (match.mark != 'chr') {            ; Atomic pattern.            ; Take the `begin` color from `chrColors`            begin  := esc '[0;' chrColors[match.mark] 'm'            if (stack.Has(-1)) {                ; Within a pair, we look for the closing color                 ; using the \"key\" from the stack                _end := esc '[0;' chrColors[stack[-1]] 'm'                clrMsg .= begin . match[1] . _end            } else {                ; Independent - close the color                clrMsg .= begin . match[1] . end            }            continue        }        ; Paired char        if (stack.Has(-1) && stack[-1] = match[1]) {            ; Found the char that completes the pair.             ; Close the color            clrMsg .= end            stack.Pop()        } else {            ; Open matching color            begin  := esc '[0;' chrColors[match[1]] 'm'            clrMsg .= begin            stack.Push(match[1])        }    }        return clrMsg}<\/code>
    <\/a><\/div><\/pre>\n
    In the first part<\/a>, we began with the help message. Now we can color it completely<\/a>:<\/p>\n
    PrintHelp(*) {; ...    msg :=       msg.Color([        '(@(file|list\\.ini))',    'yellow',   ; list        '(mainDir|AhkDir)(?=\\=)', 'purple',   ; variables names        '(%[^%]+%)',              'blue',     ; variables values        '(\\-+[\\-\\w]+)(?=[ =])',   'cyan',     ; switches        '\\*\\*([^\\*]+)\\*\\*',       'crimson',          '__([^_]+)__',            'magenta',          '~',                      'gray',        '``',                     'green',         '#',                      'orange'      ]).Print()}<\/code>
    <\/a><\/div><\/pre>\n
    <\/figure>\n
    Conclusion<\/h4>\n
    Regular Expressions<\/a> are very convenient tool to parse text. They are not so readable, but they allow us to find text regions using low-level code and process them using the high-level AutoHotkey<\/a> language.<\/p>\n
    In this article, we saw that regular expressions have the ability to track the path and they have some reflection. Thanks to these capabilities, we were able to use them more effectively and write a concise and readable algorithm.<\/p>\n
    In the next article, we\u2019ll explore how to describe text parsing in human-readable language using AutoHotkey and examine the language from the perspective of declarative programming. Check out my GitHub<\/a> if you want to see the AutoHotkey capabilities in action!<\/p>\n<\/div>\n
    \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 https:\/\/habr.com\/ru\/articles\/1057662\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
     In this series of articles, we explore the capabilities of the AutoHotkey language by demonstrating how to output colored text to the terminal for the Launcher console utility. Part 1: Naive algorithm and its optimization Part 2: Control sequences Part 3: Atomic Regular Expressions (you are here) Part 4: Declarative Programming Part 5: 256 Colors and Text StylingIn the previous part, we learned about control sequences and how to apply them in our algorithm to change the color of text. In this article, we will explore some of the capabilities of regular expressions that will allow us to change the color of an entire text region.If you are not familiar with regular expressions at a basic level, I recommend reading this article. If you are not familiar with the AutoHotkey syntax, I recommend reading the first part. However, this is not necessary to understand this article ;)Constructing ExpressionsPaired CharactersIn the previous part, we wrote an algorithm for processing character pairs: » » or * *. We pass the intermediate array aRegexColor consisting of \u201ccharacter-color\u201d pairs, convert it into a HashMap chrColors containing \u201ccharacter-code\u201d pairs, and then search for each pair and add the corresponding character from chrColors before the opening character:Color(msg, aRegexColor) {    static colors := Map(        ‘black’,    30,        ‘red’,      31,        ‘orange’,   33,        ‘magenta’,  35,        ‘gray’,     90,        ‘crimson’,  91,        ‘green’,    92,        ‘yellow’,   93,        ‘blue’,     94,        ‘purple’,   95,        ‘cyan’,     96,    )        static esc := Chr(27)    static end := esc ‘[0m’        regex     := » ; final regular expression    chars     := » ; character string    chrColors := Map()        index := 1    loop (aRegexColor.length \/ 2) {        ; `aRegexColor` — input array of «char-color» pairs        str   := aRegexColor[index++]        color := aRegexColor[index++]            chars .= str        chrColors[str] := colors[color]  ; `colors` — HashMap of «color-code» pairs    }        if chars        regex .= ‘([‘ chars ‘])’    else        regex := regex.RTrim(‘|’)            stack := []    while (pos <= len) {        if !RegExMatch(msg, regex, &match, pos) {            ; Remaining text            clrMsg .= msg.Slice(pos)            break        }                ; Normal text before the found character        clrMsg .= msg.Slice(pos, match.pos — pos)        ; Move forward        pos := match.pos + match.len                if (stack.Has(-1) && stack[-1] = match[1]) {            clrMsg .= match[1] . end            stack.Pop()        } else {            begin  := esc ‘[0;’ chrColors[match[1]] ‘m’            clrMsg .= begin . match[1]            stack.Push(match[1])        }    }        return clrMsg}RegExMatch searches for characters from the set (e.g., [«*]) and stores one of the found characters in match[1]. As a result, the algorithm processes one character per iteration. This allows us to correctly highlight text inside paired characters: «text and text». It also highlights text inside that text: «text *and* text».However, we have a more complex help message in which we need to highlight specific constructs: —switches, @file, and variables like %AhkDir%. We need to improve the algorithm and add the ability to work with entire expressions, rather than just individual characters.Key-ValueIn the algorithm above, we passed a \u201ccharacter-color\u201d array, where the key is a character and the value is a color code:msg.Color([   ‘»‘,  ‘cyan’,  ‘*’,  ‘green’])This array was converted to chrColors:» 96* 92As a result, we could call chrColors[‘»‘] or chrColors[‘*’], where each character served simultaneously as a search pattern (the regular expression, the regex variable), the matched character (the match[1]), and a key in chrColors.Now we\u2019re going to pass \u201cexpression-color\u201d pairs (for simplicity, let\u2019s temporarily forget about characters):msg.Color([  ‘(@(file|list\\.ini))’,    ‘yellow’,   ; list  ‘(mainDir|AhkDir)(?=\\=)’, ‘purple’,   ; variables names  ‘(%[^%]+%)’,              ‘blue’,     ; variables values  ‘(\\-+[\\-\\w]+)(?=[ =])’,   ‘cyan’,     ; switches])With this approach, each expression can no longer serve as both a search pattern and a matched expression (text) at the same time, and therefore cannot be a key in chrColors.Every regular expression we pass to RegExMatch is plain text. On its own, it doesn\u2019t search for anything; instead, it is first compiled into a set of instructions for the processor. In other words, Regular Expressions is something that we can call a low-level language that can be compiled, where every character, such as \\w, is converted into a specific instruction.In our case, this means that an expression like (%[^%]+%) is converted into code that searches for a text like %AhkDir%, %mainDir%, and so on. In other words, the input ((%[^%]+%)) is not equal to the output (%mainDir%), and as a result, information about the original regular expression itself — which allowed us to apply the desired color to the found text — is lost. Consequently, the expression itself cannot serve as a key in chrColors to retrieve the color.MarkAs you may have noticed earlier, the match variable is somewhat similar to an array: match[0] stores everything that was found, and match[1] stores what capturing group 1 found. However, it is actually a match\u00a0object, and it stores not only indices but also fields: match.pos, match.len, match.count. It also has a mark field. When RegExMatch() encounters the (*MARK:..) construct in the pattern, the mark field takes on the value following the colon : For example, after (*MARK:chr), the value of match.mark will be «chr».Let\u2019s look at another expression:(%[^%]+%)(*MARK:1)|(~[^~]+~)(*MARK:2)If group 1 is captured, match.mark will be equal to \u201c1\u201d. If group 2 is captured, match.mark will be equal to \u201c2\u201d.We can use this feature to mark (index) the patterns: 1, 2, 3, \u2026 Each pattern will have a unique mark, a unique key that we\u2019ll use to retrieve the color from chrColors:begin  := esc ‘[0;’ chrColors[match.mark] ‘m’clrMsg .= begin . match[1]To do this, we need to add mark with the corresponding index to the end of each pattern in the aRegexColor array, and then combine all the patterns into a single regular expression using the OR operator |regex     := » ; final regular expression    chars     := »     ; separate expression with chars    chrColors := Map()        index     := 1; array index    idxColor  := 1  ; mark index        loop (aRegexColor.length \/ 2) {        str   := aRegexColor[index++]        color := aRegexColor[index++]        if (str.length = 1) {            ; Characters are grouped into set like [«*»]            chars .= str            chrColors[str] := colors[color]; char-code        } else {            ; Group patterns into one            regex .= str ‘(*MARK:’ idxColor ‘)|’             chrColors[String(idxColor++)] := colors[color]  ; index-code        }    }        if chars        regex .= ‘([‘ chars ‘])(*MARK:chr)’  ; Add the characters separately at the end    else        regex := regex.RTrim(‘|’) ; Remove the extra OR |The result will be a single large expression like (..)(*MARK:1)|(..)(*MARK:2)|…|([..])(*MARK:chr). For convenience, we\u2019ll use the same HashMap that contains \u201cindex-code\u201d pairs and the \u201ccharacter-code\u201d pairs we\u2019re already familiar with:Expressions: the key is match.mark (index).Characters: the key is the character itself, match[1].Since each expression (whether a character or an indexed expression) has a different key, we need to distinguish between indexed expressions and character expressions using (*MARK:chr):        if (match.mark != ‘chr’) {            ; Indexed expression: wrap in color            begin  := esc ‘[0;’ chrColors[match.mark] ‘m’            clrMsg .= begin . match[1] . end            continue        }        ; Character expression        if (stack.Has(-1) && stack[-1] = match[1]) {            clrMsg .= end            stack.Pop()        } else {            begin  := esc ‘[0;’ chrColors[match[1]] ‘m’            clrMsg .= begin            stack.Push(match[1])        }Branch ResetThe constructed expression has a critical flaw: it has many capturing groups. As a result, each captured text fragment will be associated with its own capturing group: 1, 2, \u2026Let\u2019s look at this code snippet:»%variable% is ~gray~».Color([    ‘(%[^%]+%)’, ‘blue’,     ‘(~[^~]+~)’, ‘gray’])Color will construct the expression:(%[^%]+%)(*MARK:1)|(~[^~]+~)(*MARK:2)which contains 2 capturing groups:IndexGroupText1(%[^%]+%)%variable%2(~[^~]+~)~gray~Accordingly, the text ~gray~ will be stored in match[2], while match[1] (which we use in the algorithm) will be empty. In other words, we need to know the group\u2019s index to retrieve the text. But if the user has included multiple groups in each pattern, such as =(%([^@](\\w+))%), it will be difficult to determine the index. We want the text or character to always be stored in match[1].To solve this problem, we can use Branch Reset. Branch Reset is a (?|..) construct, which makes the index of each group relative. If we represent the expression ()|()|… as a list of items separated by |, then the index of each capturing group within each item will be relative to that item:( () )|( () () )1  2   1  2  3 In other words, we don\u2019t look at the entire expression, but rather to its individual items, and then at groups within those items. Without Branch Reset, indexing is absolute:( () )|( () () )1  2   3  4  5 Let\u2019s wrap the constructed expression in (?|..):(?|(%[^%]+%)(*MARK:1)|(~[^~]+~)(*MARK:2))It is important to understand that (?|..) is not a capturing group, but a \u201cBranch Reset\u201d construct. And (*MARK:..) is a \u201cverb\u201d (verb). The parentheses are merely part of the syntax.As a result, we end up with the following indexing:IndexMarkGroupText11(%[^%]+%)%variable%12(~[^~]+~)~gray~match[1] will always contain the captured text from the 1st, 2nd, or 3rd group. At the same…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-486811","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/486811","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=486811"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/486811\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=486811"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=486811"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=486811"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}