English version.
Не так давно я начал обращать внимание, что многие консольные утилиты выводят цветной текст. Меня заинтересовало, смогу ли я тоже добавить цвета в вывод моей консольной версии Launcher.

Задача стояла написать алгоритм, который будет применять менять разные цвета к фрагментам выводимого текста. И в этой статьей мы детально рассмотрим, как можно написать такой алгоритм на моем любимом языке AutoHotkey, как его оптимизировать и что стоит учитывать, когда вы пишете код.

Если вы не знакомы с синтаксисом AutoHotkey, не переживайте, я проведу вас через него. Ведь одна из задач этой статьи - познакомить вас с этим языком.

Часть 1: Наивный алгоритм и его оптимизация (вы здесь)
Часть 2: Управляющие последовательности
Часть 3: Атомарные регулярные выражения
Часть 4: Декларативное программирование
Часть 5: 256 цветов и стилизация текста

Наивное решение

Виды функций

Начнем с идеи раннего алгоритма. Наша цель - менять цвет сообщения при выводе в консоль (далее - терминал, так как я работаю в эмуляторе Cmder с PowerShell). Для этого сначала в самом сообщении должны быть какие-то маркеры, которые будут указывать цвет для каждой части текста. Например, маркерами могут служить html теги: <color>text</color>. Далее необходимо найти все такие теги в тексте, извлечь имя цвета и применить его в консоль.

Благо Microsoft позволяет нам обращаться к Windows и просить ее что-нибудь сделать. Для этого существует Windows API (Windows Application Programming Interface, он же WinApi или просто функции API). Каждая функция имеет свою документацию на сайте Microsoft, и располагается в своих dynamic-link libraries (DLL), которые загружаются при запуске интерпретатора AutoHotkey. В результате мы можем вызывать любые функции из этих библиотек от Microsot из AutoHotkey с помощью встроенной функции языка DllCall. Все встроенные функции AutoHotkey вроде MsgBox или FileAppend вызывают те или иные функции WinApi, но при большом желании мы можем “спуститься на уровень ниже” и вызвать их самостоятельно.

Не стоит путать: пользовательские функции мы объявляем сами; функции языка предоставляет интерпретатор; функции WinApi можно вызвать только через DllCall;

Для изменения цвета в консоли существует функция WinApi SetConsoleTextAttribute. Она принимает handle консоли (ее уникальный номер/id) и число, которое “характеризует” цвет. Это не RGB и не HEX представление, а специальный внктренний флаг, на котором мы не будем заострять внимание.

Для дальнейшего вывода в консоль существует функция языка FileAppend которая умеет выводить сообщение в текст или в консоль (специальное имя файла - CONOUT$).

В самой ранней версии алгоритма использовалась рекурсивная обработка html тегов цвета и вызов SetConsoleTextAttribute() для каждого с последующим вызовом FileAppend():

Print(text, color := 'white') {
    ; Словарь/HashMap который сопоставляет цвету спец. код
    ; статич.: инициализируется один раз при загрузке скрипта,
    ; уменьшает время исполнения
    static colors := Map(
        'black',    0,
        'blue',     1,
        'green',    2,
        'cyan',     3,
        'red',      4,
        'magenta',  5,
        'yellow',   6,
        'white',    7,
        'gray',     8,
    )
    
    ; Цвет по-умолчанию, который будет использоваться
    ; для частей текста
    normalColor := colors.Get(color, 7)
    
    _Print(msg, _color := normalColor) {
        ; Замыкание: пользовательская функция внутри функции
        ; Весьма удобно использовать как макрос для повторяющегося текста

        ; статич.: инициализируется один раз при загрузке скрипта,
        ; уменьшает время исполнения
        static hConsole := GetOutputHandle()
        DllCall(
            'SetConsoleTextAttribute', 
            'ptr', hConsole, 
            'uint', _color
        )
        
        ; Выводим цветной текст
        FileAppend(msg, 'CONOUT$')
    }

    pos := 1
    while (pos <= text.length) {
        ; Ищем все цветовые теги начиная с `pos`, 
        ; сохраняем результат в переменной `match`
        if (RegExMatch(text, 's)<(\w+)>(.*?)</\1>', &match, pos)) {
            ; Выводим текст до цвтного участка
            normalText := text.Slice(pos, match.pos - pos)
            if (normalText)
                _Print(normalText)    ; замыкание (макрос) сверху
            
            ; Обрабатываем вложенные теги
            ; Рекурсивный вызов:
            ; группа 2 = сообщение, 
            ; группа 1 = цвет.
            Print(match[2], match[1])
            
            ; Движемся вперед
            pos := match.pos + match.len
        } else {
            ; Выводим оставшийся текст
            _Print(text.Slice(pos))
            break
        }
    }
}

Message(msg, icon := '', normalColor := 'white') {
    if IsConsole
        return Print(msg '`n', normalColor)
     
    msg := RegExReplace(msg, 's)<(\w+)>(.*?)</\1>', '$2')
    return MsgBox(msg, A_ScriptName, icon)
}

RegExMatch это функция языка, которая позволяет быстро парсить текст без промедлений со стороны высокоуровневых языков

Как видите, выглядит довольно просто: найти цвет, применить цвет, вывести в консоль, повторить. И такой алгоритм обрабатывает и вложенные теги: <yellow>my colorful<cyan>message</cyan></yellow>

Так как функция Print() только обрабатывает и выводит сообщение, нам нужна дополнительная функция Color() которая добавит html теги в текст:

Color(str, regex, colorTag) {
    return RegExReplace(
        str, 
        regex,
        Format('<{1}>$0</{1}>', colorTag)
    )
}

Еще одна функция языка, которая ищет кусок текста и обрачивает его в теги. Минималистично, удобно.

Новые методы строк

Для удобства мы можем объявить дополнительные методы строк как в Python. Только в AutoHotkey в отличие от Python мы можем создать какие угодно методы для наших строк, например добавить метод Color() который будет раскрашивать строку:

'My colorful message'.Color('message', 'cyan')
; or
'-help, -h or -? displays help message'.Color('-\w+', 'green')

Как вы, наверное, догадались, метод Color() будет вызывать нашу функцию Color() и передавать первым аргументом msg ту строку, к которой он применяется. Т.е. 'My colorful message'.Color('message', 'cyan') будет эквивалентно Color('My colorful message', 'message', 'cyan').

Такая конструкция объявляет новый метод Color() для примитивов типа String:

({}.DefineProp)(String.prototype, 'Color', {call: Color})

В алгоритме выше вы могли заметить методы Slice(), атрибут length. На самом деле это тоже “добавленные методы”, которые являются обертками над функциями языка, но делают код чуть-чуть читабельнее.

Давайте посмотрим, как можно применить наш алгоритм. В коде есть функция PrintHelp(). Внутри нее сообщения со справкой: с цветовыми тегами и без них. Ниже приведен ее небольшой фрагмент (так как сообщения достаточно большие):

PrintHelp() {
    usage := 
    (
    "<gray>Launch saved scripts and applications.
    Copyright (c) 2026 Rafaello
    https://github.com/JoyHak/Launcher</gray>
    
    Usage:
      launcher --param=script1<gray>[;script2;script3...]</gray>
      launcher --param=<yellow>@file</yellow>
      launcher -switch
      launcher <cyan>variable</cyan>=value"
    )
    synopsis := 
    (
    "Parameters:
      --run     run script(s)
      --close   close script(s)
      --add     add script(s)
      --remove  remove script(s)
      --sep     set separator between scripts"
    )

    synopsis := synopsis
      .Color('[\-]+[\-\w]+', 'cyan')
    
    ; Конкатенация строк: a . b
    Message(usage . synopsis)

Так как сообщение usage уже содержит цветовые теги, Color() применятся только к собщению synopsis и раскрашивает --switches.

Красиво. Но что лежит у этих функций под капотом и сколько операций они совершают при каждом вызове? Функция FileAppend() снова и снова открывает/закрывает доступ в консоль. Функция SetConsoleTextAttribute выполняет ряд операций, которые к смене цвета не имеют отношения: опрос режима консоли, проверка свободного буфера вывода и т.д. И наконец есть риск что рекурсия в Print() может обвалиться при многократно вложенных тегах и вызвать stack overflow.

Время выполнения

Давайте попробуем измерить время выполнения алгоритма. Для этого используем обертку над функцией WinApi QueryPerformanceCounter:

Timer(_start := false) {
    static previous  := 0, 
           frequency := 0, 
           current   := DllCall("QueryPerformanceFrequency", "Int64*", &frequency)
    
    _result := !DllCall("QueryPerformanceCounter", "Int64*", &current)
    if _start {
        previous := current
        _result += current / frequency
    } else {
        _result += (current - previous) / frequency
    }
    
    return _result * 1000  ; seconds to milliseconds
}

Приницип прост: Timer(1) запускает таймер, а Timer(0) - останаливает и возвращает время в миллисекундах. Измерим время обработки всей справки и сохраним в файл:

PrintHelp() {
	; ...
	Timer(1)
    synopsis := synopsis
      .Color('[\-]+[\-\w]+', 'cyan')	; switches
      
    examples := examples
      .Color('(mainDir|AhkDir)(?=\=)', 'cyan')	 ; variables names
      .Color('%[^%]+%',                'blue')	 ; variables values
      .Color('@(file|list\.ini)',      'yellow') ; list
    
    Message(usage . synopsis . examples)
    time := Timer(0)
    
    FileAppend(
        Format('Color tags, multiple SetConsoleTextAttribute() calls: {:.4f}ms`n', time), 
        'C:\Temp\launcher_bench.log'
    )

Так как вывод в консоль и обработка аргументов возможна только в исполнямых файлах, сначала соберем наш launcher.ahk в launcher.exe и сохраним его в директорию v1. Выполним &"C:\Temp\v1\launcher.exe" -help в терминале и увидим в файле время 77.6859ms.

Довольно неплохо, хотя и видно как в терминале текст появляется постепенно, по частям. Можем ли мы оптимизировать наш код?

Производительное решение

ANSI коды

Как я писал выше, самое медленное здесь - связка SetConsoleTextAttribute и FileAppend. Было бы здорово оставить только один вызов FileAppend, но тогда мы должны выполнить пре-процессинг сообщения самостоятельно, без вызова SetConsoleTextAttribute.

Мне удалось выяснить, что SetConsoleTextAttribute добавляет специальные коды в сообщение при выводе в терминал. И хотя исторически за ними сохранилось название ANSI codes, на самом деле они представляют собой расширение для текущей кодировки (обычно Windows-1252).

Причем сама функция довольно ограничена, ведь число этих кодов (и способов кодирования) гораздо больше. Более того, мой эмулятор Cmder, как и многие другие хорошие эмуляторы терминала способны обрабатывать эти коды выводить 256+ цветов. Не уверен, что Windows Terminal на это способен.

Таким образом, теперь наш алгоритм должен сам добавлять ANSI коды в полученный на вход текст. Для простоты мы ограничимся однобайтовым набором символов. Они имеют следующий вид: \e[0;31m - красный, \e[0;34m - синий, и т.д. И хотя есть также “стилизация” текста, например \e[1;31m - жирный красный или \e[0;41m - красный фон, для простоты мы будем рассматривать только цвета текста без стилизации.

Для окрашивания сообщения нам достаточно "обернуть" найденные фрагменты текста в соответствующе коды согласно найденным цветовым тегам: \e[1;31mmessage\e[0m где \e[0m - "завершающий" код, после которого текст приобретает цвет по-умолчанию (зависит от настроек эмулятора, но обычно - белый).

В таком случае перепишем наш алгоритм так, чтобы он добавлял необходимые коды. Каждому коду дадим понятное имя, которое и будем ожидать на входе в качестве параметра color:

Color(text, color := 'white') {
    ; Словарь/HashMap который сопоставляет цвету ANSI код.
    ; статич.: инициализируется один раз при загрузке скрипта,
    ; уменьшает время исполнения
    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,
    )
    ; Default color for text
    normalColor := colors.Get(color, 37)
    
    static esc := Chr(27)     ; ASCI escape character \e
    static end := esc '[0m'   ; Прекратить обработку цвета: \e[0m 
    begin  := esc '[0;' normalColor 'm'  ; Начать обработку цвета, код вроде \e[0;37m 
            
    clrText := ''  ; итоговое цветное сообщение
    pos := 1       ; начало сообщения
    
    while (pos <= text.length) {
        ; Ищем все цветовые теги начиная с `pos`, 
        ; сохраняем результат в переменной `match`
        if (RegExMatch(text, 's)<(\w+)>(.*?)</\1>', &match, pos)) {
            ; Нормальный текст до цветового участка
            ; (цвет зависит от уровня рекурсии)
            clrText .= begin . text.Slice(pos, match.pos - pos) . end
            
            ; Обрабатываем вложенные теги
            ; Рекурсивный вызов:
            ; группа 2 = сообщение, 
            ; группа 1 = цвет.
            clrText .= Output(match[2], match[1])
            
            ; Движемся вперед
            pos := match.pos + match.len
        } else {
            ; Выводим оставшийся текст
            clrText .= begin . text.Slice(pos) . end
            break
        }
    }
    
    return clrText
}

Print(msg, icon := '') {
    if IsConsole
        return FileAppend(msg '`n', 'CONOUT$')
   
    msg := RegExReplace(msg, 's)<(\w+)>(.*?)</\1>', '$2')
    return MsgBox(msg, A_ScriptName, icon)
}

Код стал значительно проще. Вместо двух независимых алгоритмов подсветки и парсинга текста мы получили один небольшой алгоритм в функции Color() и маленький алгоритм в функции Print(), который только выводит готовое сообщение одним вызовом FileAppend().

Выполним &"C:\Temp\v2\launcher.exe" -help и увидим время 3.5338ms. Ускорение в 21.9836 раз! Наглядный пример, почему много вызовов функций - это плохо.

Решение без тегов

Несмотря на удобный алгоритм у нас осталось несколько недостатков:

Html теги неудобно писать руками в некоторых текстовых редакторах вроде Notepad++.
Html теги удлинняют сообщение и замедляют парсинг.

Попробуем уменьшить количество символов в справке. Если вы знакомы с Markdown, то вы знаете символы форматирования текста: # __ `

При рендере .md документа они исчезают, чтобы сфокусировать внимание на тексте с помощью форматирования, а не с помощью доп. символов.

Вместо html тегов мы можем создать похожий синтаксис вроде #header#, magenta etc. который удобно парсить:

PrintHelp(*) {
	; ...
    msg := usage . synopsis . examples
    
    Timer(1)
    msg := 
      msg
        .Color('(@(file|list\.ini))',    'yellow')   ; list
        .Color('(mainDir|AhkDir)(?=\=)', 'purple')   ; variables names
        .Color('(%[^%]+%)',              'blue')     ; variables values
        .Color('(\-+[\-\w]+)(?=[ =])',   'cyan')     ; switches
        .Color('\*\*([^\*]+)\*\*',       'crimson')  
        .Color('__([^_]+)__',            'magenta')  
        .Color('(~)',                    'gray')
        .Color('(``)',                   'green') 
        .Color('(#)',                    'orange')
      .Print()
      
    time := Timer(0)
    
    FileAppend(
        Format('ANSI codes, multiple .Color() calls: {:.4f}ms`n', time), 
        'C:\Temp\launcher_bench.log'
    )
}

В таком коде мы ожидаем, что можно раскрасить текст внутри символов передав соответствующее выражение и ожидаемый цвет. Например, для синего текста, окруженного символами процента %, мы передаем выражение вроде (%[^%]+%).

Для поддержки таких ожиданий необходимо переписать Color():

Color(msg, regex, color) {   
    ; Словарь/HashMap который сопоставляет цвету спец. код
    ; статич.: инициализируется один раз при загрузке скрипта,
    ; уменьшает время исполнения 
    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)     ; ASCI escape character \e
    static end := esc '[0m'   ; Прекратить обработку цвета: \e[0m 
    begin := esc '[0;' colors.Get(color, 37) 'm'    ; Код текущего участка текста

    pos := 1
    len := msg.length
    clrMsg := ''
    
    while (pos <= len) {
        if !RegExMatch(msg, regex, &match, pos) {
            ; Remaining text
            clrMsg .= msg.Slice(pos)
            break
        }
        
        ; Текст перед цветным участком
        clrMsg .= msg.Slice(pos, match.pos - pos)
        ; Добавляем ANSI код
        clrMsg .= begin . match[1] . end
        ; Движемся дальше
        pos    := match.pos + match.len   
    }
    
    return clrMsg
}

Print(msg, icon := '') {
    if IsConsole
        return FileAppend(msg '`n', 'CONOUT$')
   
    msg := RegExReplace(str, 'U)' esc '\[\d+(;\d+)?m')
    return MsgBox(msg, A_ScriptName, icon)
}

; дополнительные методы для строк
({}.DefineProp)(String.prototype, 'Color',  {call: Color})
({}.DefineProp)(String.prototype, 'Print',  {call: Print})

Теперь мы последовательно ищем каждый шаблон с помощью цикла, и благодаря добавленному методу Print() можем создавать цепочки вызовов: "My colorful message".Color("message", "cyan").Print()

Выполним &"C:\Temp\v3\launcher.exe" -help в терминале и увидим время 2.5428ms. Весьма неплохо! Алгоритм из рекурсивного стал итеративный, и читабельность чуть-чуть улучшилась.

Исходный код алгоритма вывода цветного текста доступен на GitHub. А здесь вы можете прочитать про некоторые дополнительные возможности этого алгоритма.

Вывод

Первое решение далеко не всегда самое правильное. Конечно, если вы пишите маленький AutoHotkey скрипт, скорость написания зачастую имеет значение. А вот если вы пишите полноценные проекты, которые выполняют большие и сложные задачи, разумно попытаться “притормозить” и попытаться сделать кодовую базу более читабельной, а используемые алгоритмы - более производительными.

В данной статье мы увидели, что AutoHotkey вовсе не примитивный язык для написания макросов и переназначения клавиш. Это полноценный язык программирования, на котором можно писать алгоритмы и собственный синтаксический сахар.

В следующей статье мы попробуем еще больше оптимизировать полученный алгоритм, рассмотрим вложенные цвета и некоторые интересные возможности регулярных выражений. Заглядывайте на мой GitHub, если вы хотите увидеть возможности языка на практике.

Цветной текст в консоли в AutoHotkey