ViewColor — Монструозная раскраска некоторых синтаксисов в консоли поверх просмотрщика

[Ultrabyte]

ViewColor с конфигуратором (клавиша F11)

• MaskFile (6 полей: eng, rus, code, log, hex, none) — указывает, какие файлы должны открываться в определённых схемах, чтобы исключить влияние AutoScanner.
• AutoScanRun - запускает автоматический анализ содержимого экрана (соотношение eng, rus, знаков, триггеров). Может ошибаться, но вроде правильно определяет TXT от EXE.
• ShowScan - отображает в верхнем статусе количество символов, знаков и итоговый результат выбора схемы. Для дебага.
• HistoryScheme - запоминает выбранную схему для каждого файла (через F5 / AltF5) в 20-и слотах памяти в базе-данных (при переполнении начнется замещение самых старых-редких записей). Может сохранять по расширению *.ext (выбранная схема будут применяться для всех типов файлов с этим расширением), по конкретному файлу file.ext, или по полному пути C:\folder\file.ext. Полезно, если Юзер ежедневно изучает длинный документ, а AutoScanner на момент открытия на разной странице документа постоянно глючит, то -code-, то -log-. Юзер может выбрать 1 раз нужную схему и подождать 10сек, и сохранится в память. (мне по большому счету не пригодился данный пункт, но может кому-то еще полезно).
• [log ] by Default - схема по умолчанию ("log", "code" и прочее), которая применяется при нераспознанных случаях (отсутствие MaskFile, не смог AutoScanner и нет раннее использованных схем в HistoryScheme).
• ShowListScheme - показывать маленькое всплывающее окошко Списка Схем при нажатии F5/AltF5 (можно поменять на другие клавиши, например CtrlK/ShiftJ. Или впишите F20 для частичного отключения)
• Safe - тоже относится к показу Списка Схем, но отрисовывается силами FarAPI (не WinAPI). Преимущества FarAPI: самоубирающее окошко через доли секунды. Но есть недостаток, клавиши клавиатуры плохо "ощущается", хотя может Юзеры не замечали, пока не написал об этом =)
• RefreshTSR - обновление экрана силами резидента (TSR) по таймеру каждые 100мс. Полезно для автоматического обновления логов, где FAR Viewer постоянно обновляет содержимое файла (RealTime). В этом случае TSR отслеживает изменения и перерисовывает экран. Совет: если отключён обработчик клавиш (RefreshKEY), лучше уменьшить таймер до 35мс — это позволит быстрее и резво перерисовать после клавиш-навигации.
• RefreshKEY - обновляет экран с помощью событий клавиатуры/мышки, при ОТжатии клавиш: Up / Down / PageUp / PageDown и т.п.
• WorkIndicator - индикатор в верхнем углу: красный (RefreshTSR), желтый (RefreshKEY), зеленый (запись в HistoryScheme). Для дебага, помогает видеть активность программы, например, отслеживать почему иногда 2 раза перерисовываются с "желтым" и "красным" одновременно.
• ViewDumpClean - очистка Dump/Hex от разноцветных символов, цифр, букв как циганщина непотребство. Стоит на это один раз посмотреть, чтобы понять всю сущность бытия и преисполнится...
• OffColorInF7 - отключает раскраску при Shift/Alt/Ctrl+F7. Полезно, если яркость выделенного текста слишком низкая. (в дефолтном FAR'е, я практически не вижу где этот выделенный блок).
• ConEmuRefreshForcibly - были случаи когда в оболочкеConEmu не работала раскраска, поэтому принудительно заставляет перерисовать экран (снижается быстродействия на 30%). Отключите, если используется Windows Terminal (или ViewColor сам сообщит о "разбитом экране", когда появятся иероглифы и посоветует отключить этот параметр).
• ConEmuRefreshApiFar - (если это включено, то НЕ учитывается предыдущий пункт Forcibly). Использует вывод раскраски через сам FAR, а не WinAPI, что даёт возможность управлять RGB-цветами (если поддерживается, т.е. обращайте внимание на надпись Status: Far is RGB). Недостаток — клавиши управление ощущаются ватными, в верхнем углу виден "прыгающий мячик", что говорит о удержании экрана и ожидании следующих клавиш. Для комфортной работы с этим параметром (FarApi) желательно иметь версию Far v6369 или выше, чтобы не ощущать дискомфорт "подзависшие" клавиши курсора или PgUp/PgDn.
• ColorTableRGB - если появится надпись Status: Far is RGB, можно включить этот параметр и увидеть собственную палитру цветов, настраиваемую внутри ViewColor (поиск по ColorTableRGB). Можно подстроить палитру так, чтобы цвета были более мягкими, не бросались в глаза. Например, сделать красный и фиолетовый более белыми с оттенками. Это помогает сделать русский текст более читаемым с нежной розовой подсветкой. (да, этот бред написал сам чатгпт=)

Некоторые параметры вступают в силу, только после выхода из просмотрщика и снова открыть (например, упоминается в RefreshTSR Need ESC->F3). В некоторых случаях, например, переназначения клавиш F5/AltF5, потребуется Restart в главном меню или перезапустить FAR.

Пока не придумал, как правильнее назвать, решил назвать "Global", так как по сути сюда входят изменения цветов, которые влияют глобально на все схемы: "eng", "rus", "code", "log", "hex". Также это удобно тем, что есть хоткей на букву G.

• ColorHexAddress - раскрашивает в Hex-экране адресные строки.
• ColorHexDigital - раскрашивает в Hex-экране шестнадцатеричные строки.
• ColorFarSystem - автоматически распознает из системных настроек FAR (в верхнем углу иногда можно видеть мелькания 1234) - это запись RGB-кода на экран и последующего чтения 4-bit цветового кода. На мой взгляд это надежный способ, но в ConEmu происходят какие-то странные аномалии, поэтому оставлена возможность ручного управления (снять галочку и ввести свои значения). Важно не ошибиться с цветовыми кодами, иначе может затереть выделенный текст в поиске F7 (в диалоге об этом явно предупреждается need exact value to not losing selected block). В общем, как догадались, территория ConEmu - это страшный сон программиста...
• ColorUserText - тоже для страшных снов с ConEmu, кто хочет довести до стресса правильной работы с цветами.
• ColorUserCmnt - в стандартной реализации комментарии имеют самый тусклый цвет, чтобы подчеркнуть, что это не активная часть кода. Однако у разных ЖК-мониторов бывают проблемы - у тех, у кого офисные ноутбуки купленные на распродаже 11.11 с синючими экранами, то предпочитают включать темно-голубой цвет, а у тех, у кого хороший контраст и красные цвета яркие, - можно смело выбрать значение 5 (темно-фиолетовый) или 6 (темно-желтый), что позволяет лучше видеть и отличать комментарии от голубого кода. В ViewColor часто можно видеть переменную ColorUserCmntDark - она отвечает за выбранный пользователем цвет, заданный в конфигураторе.
  Вторая переменная - ColorUserCmntLight - пока не применена в кодах ViewColor, но оставлена для будущих целей для пользователя. Её можно привязать к чему угодно, например, к русскому тексту или знакам-синтаксическим символами и т.д. и управлять на быструю руку через конфигуратор (например, установив код A - зеленый или C - красный и т.д.)

Open brck 1st+2nd to Far"»"= CloseALL - алгоритм-анализатор находит первую открывающую скобку, например, <, то ищет её закрывающую пару, но встречает снова открывающую (, это уже напрягает, не правда ли? запомним, ищем дальше - встречает закрывающую Far">" (граничный маркер), тут передаем "наши полномочии" юзеру: Юзер установил CloseALL, следовательно, все ранние открытые скобки - завершены благополучно, подкрашиваются скобки < и ( соответствующими цветами. Что делать, если юзер установил Close2nd - следовательно, закрывается вложенная скобка (, но осталась первичная скобка <, анализатор ищет дальше, где её пара > в следующей строке (которую так и не находит, потратив ресурсы времени, гигаватты и электромиграцию атомов)... раскрашивается (, но не раскрашивается <.
А теперь вопрос, зачем вот это всё было?:) насколько помню на заре создания были постоянные спотыки с визуализацией стиля HTML...

Far"«"→">" or "<"→Far"»"= Coloring - алгоритм-анализатор для граничных маркеров (far"<" или far">"), из-за них слишком много ложных срабатываний, программа не знает, насколько глубоко уходит текст за границы Far">", с высокой доли вероятности там находится закрывающая пара (чаще всего нет, ибо знак > это математическое оформление a<b или b>c). Юзер может установить STOP, чтобы перестать раскрашивать скобки из-за граничных маркеров. Отмечу, в алгоритме встроен еще тонкий анализатор: является ли скобка < единственной в строке до этой скобки? и также является скобка > единственной в строке после этого знака. Типичный пример <title> <body> <script> в HTML или XSLT

Встроенный бенчмарк позволяет оценить быстродействие, длительность всего 1 минута (точнее 50 секунд), и выдаст три значения FPS:

- среднее (без учёта максимума и минимума, поскольку эти числа считаются "браковочными", так как пути LuaJIT неисповедимы).
- минимальное — это у LuaJIT болит голова.
- максимальное — это у LuaJIT хорошее настроение.
Часто бывают рандомные значения, поэтому среднее рассчитывается без учёта максимума и минимума. Для надежности показателей, мне приходится каждый раз перезапускать FAR, и даже там у LuaJIT настроение как у ...

Для эксперимента лучше найти большой документ, например, в комплекте FAR — Changelog. Правда, схема -log- — это не самая тяжёлая нагрузка. Наверное, самая тяжёлая нагрузка — это просмотр ViewColor.lua в схеме -code- (лучше дважды скопировать самого себя, так как у меня быстро доходит до конца, и в конце экран замирает, резко повышается FPS). Или открыть просмотр Far.exe в режиме Dump (Shift-F4: Dump) и запустить бенч.

На коротких файлах, например, вмещающихся на один экран, могут выдаваться слишком высокие FPS. Возможно, причина в том, что функции WinAPI не задействованы в полной мере, поэтому всё происходит борзо-резко, или LuaJIT читерит...

На моем компе (сборка 16 года) в среднем отрисовка составляет Avg=80fps. Думаю, это нормально-терпимо. Однако интересно, у кого насколько получается, так как нередко вижу, как окна FAR растягивают до 300х100 символов...

Если чувствуется, что еле ползёт (Avg: 15-25fps), рекомендуется выполнить следующие шаги:
В конфигураторе System:

• включить ViewDumpClean (очистка экрана в Dump'е). Магическим образом LUA легче выполнять сложный код внутри себя, чем раскрашивает новогоднюю ёлку на экране...
• вЫключить WorkIndicator - даже маленький одиночный знак в верхнем углу вызывает выполнения тяжелых функций WinAPI (FarAPI)
• вЫключить ConEmuRefreshForcibly - отключает принудительную повторную раскраску (лишний вызов WinApi для плохой версии ConEmu).
• проверить по ситуации ConEmuRefreshApiFar - возможно быстрее окажется при активации этого пункта (не рисует на пробельные зоны просмотрщика), или, наоборот, работа с RGB еще больше утяжелит код.

В конфигураторе Global:

• Настроить цвета так, чтобы не было несоответствия цвета FarColorText с фоновым цветом букв (например, с ColorUserTextViewer). Проще говоря, чтобы фон Viewer соответствовал цвету фоновых шрифтов (Background). В противном случае ViewColor, заметив различие цветов, запускает тяжёлый код выравнивания краёв с пробельными отступами.

На мой взгляд, ViewColor v50 стал слишком раздут и загромождён, что вызывает обеспокоенность у ряда стран и партии Зеленых…
К сожалению, не имею возможности ускорить работу, если не переходить полностью на C++, но это разве что в следующей жизни…
Однако заметил интересный момент: предыдущая версия 0.42 (без конфигуратора) имеет чуть лучшие характеристики по быстродействию (разумеется, при настройке внутри ViewColor переменной ConEmuRefreshForcibly на "false" для повышения скорости). Видимо, LuaJIT более щадяще относится к старым версиям и лучше трассируется горячий код в свой узкий кэш…

Важный момент: учитывайте наличие ScrollBar (Ctrl-S) — его присутствие снижает FPS примерно на 10..20%. Но лучше с скроллбаром, чем без них...
Ну и не лишним будет отметить, что если запущены два бенчмарка в двух разных FAR, то почему-то однопоточность делится ещё на две части, и работает куда медленнее.

Производительность в разных версиях FAR (с v4242, 14г., по v6570, 25г.) особой разницы не заметил, ни между разрядностями x86 и x64. Возможно, влияние составляет около ±10%, но никакого «в 2 раза» не зафиксировано.

Однако отмечено влияние окружения: например, под ConEmu производительность может быть выше на 20–50%. Вероятно, это связано с тем, что ConEmu по-другому взаимодействует со своей «виртуальной» консолью.

В старых версиях ViewColor скорость раскраски была неоптимизированной, поэтому с течением времени в ViewColor постепенно проводились оптимизации быстродействия, и появилась возможность включить режим RealTime (в конфигураторе System, внизу расположена кнопка RealTime). Эта настройка позволяет достичь максимальной производительности и минимального размера таймера 1 мс.

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

drkns 27.05.2021 23:22:21 +0100 - build 5804

1. Experimental: removed constant polling from the main thread. This should noticeably reduce CPU consumption and make various idle events more predictable.
   1. Экспериментальная функция: убран постоянный опрос из основного потока. Это должно заметно снизить нагрузку на процессор и сделать различные события простоя более предсказуемыми.

- движения экрана намного плавнее, без дерганности.
Far v6369 - переработан код обработки таймера, исключив подлагивания всей консоли путем пропуска несостоявшихся событий(?) (видимо отсюда пошло) — значительно повысилась плавность навигации и скроллинга. (полезно для ConEmuRefreshApiFar)

Тем не менее, если заметили появление дублирующихся строк или артефактов на экране просмотрщика (при включенном пункте ConEmuRefreshApiFar), вероятно, стоит вручную увеличить интервал таймера до 5 или 10 миллисекунд. Это может вызвать небольшое мелькание, но зато устранит проблемы с двойными-тройными строками мусора при навигации с помощью стрелок.

Однако экстремальные настройки режима RealTime едва ли подойдут для устаревших устройств, таких как Atom-нетбуки. Лучше вернуться к исходным настройкам, используя кнопку Default.

Еще интересное наблюдение: на Atom-нетбуке значения 1ms по факту НЕ являются как 1ms, а скорее всего FAR округляет как 15ms (проверено в дебаг-счетчике), видимо для безопасности или лимит отклика самой системы, т.е. это значит, что для Atom-процессоров будет весьма неприятно мелькать во время скроллинга текста (15ms - это не 1ms).
На мощном процессоре 1ms действительно становится 1ms - очень плавная прокрутка. Но попробовав 0ms - Far опять таки округляет до 1ms по выше означенной причине.

---

Если по каким-либо причинам просмотрщик (и весь FAR) зависли из-за экстремальных настроек RealTime и не можете попасть в конфигурационный интерфейс (F11), рекомендуется воспользоваться альтернативным способом:

• в режиме панели (не просмотрщик) зайти в верхнее меню (F9)
• выбрать Options (Параметры)
• выбрать Plugins configuration (Параметры плагинов)
• найти ViewColor... и в конфигураторе System нажмите внизу Reset — это удалит все установленные ранее параметры в реестре FAR'a. После перезапуска FAR'а - ViewColor вернется к своему первоначальному состоянию.

=== для v53 - НЕ АКТУАЛЬНО ===

Целый пласт диалоговых настроек цветов: eng, rus, code, log, hex. Это значительно утяжеляет размер кода примерно в два раза (казалось бы, такие мелочи, как диалог с System и Global, уже занимают 20кБ пространства в никуда).

Поэтому наспех написан примитивный код для открытия редактора:

В верхней части — схема eng (для справки и комментариев на русском языке), а в нижней — редактор необходимой схемы.
Переключать между окнами Ctrl+Shift+Tab - вверх, Ctrl+Tab - вниз. Обратите внимание на скриншот: эта информация также отображается в статусной строке, чтобы не забыть.
Надеюсь, будет понятно, что там и о чём… Например, часто встречается выражение: b+0x0B — означает фоновый цвет b (background), заданный через конфигуратор, например, автоматически распознается через ColorFarSystem (или ColorFarText, если User вручную настраивает в Menu->Global), а +0x0B — это светло-голубой цвет. Можно писать просто b+13, что равноценно b+0x0B.
Также есть выражение n+0x0B (в старых версиях без конфигуратора был c+0x0B). Это означает цвета, близкие по оттенкам к b. Например, b — это темно-синий, то n — автоматически выбирает самый подходящий фон - черный, или, если b был красным, то n станет фиолетовым — ближайшим по оттенкам цветом (согласно таблице соответствия цветов ColorTableNear).

После редактирования схемы необходимо нажать пункт Restart в главном меню. Это перезапустит ViewColor, и, если потребуется, можно выйти и заново зайти в просмотрщик.

Также не завезли в конфигуратор некоторые переменные (флажки), они доступны только при редактирования внутри ViewColor:

• KeyMiniSpisokAltTimer=300 - время в миллисекундах, в течение которого окно остаётся на экране перед исчезновением (работает только в паре с KeyMiniSpisokAlt=true). Думаю, этот малозначимый параметр не стоит раздувать лишними килобайтами ради пункта в диалоге...
• RefreshScreenAlways=false - раскрашивать экран всегда, даже если ничего не меняется. По умолчанию — false, то есть раскрашивание происходит только при движении или изменениях на экране. Полезно только для дебага: было интересно, что произойдет при RefreshAlwaysTime=1 и RefreshScreenAlways=true (всегда раскрашивать в течение каждой 1ms) — зависнет ли Windows12 или запустится рекурсия в большом коллайдере… Напомню, LuaJIT/Far — таки однопоточный процесс…

• Скачать ViewColor.lua
• поместить в папку \Macros\scripts\ (например, выполнив команду cd %FARPROFILE%\Macros\scripts окажетесь в этой папке)
• перезапустить FAR
• нажав F3-View (просмотрщик) должна появится раскраска, как показана на скриншотах.

На всякий случай, сохраняю старые версии для сравнения стабильности, если что, пишите багрепорты.

Избирательно проверил на нескольких версиях:

• FAR 3156, 13г. - крашится: ошибка Event.
• FAR 3249, 13г. - v0.43 + заменить lua5.1.dll от Far v3525;
• FAR 3367, 13г. - v0.43 + заменить lua5.1.dll от Far v3525;
• FAR 3525, 13г. - с v0.42 работает. (v52,v53 - нет)
• FAR 3900, 14г. - с v0.42 работает. (v50,v51 - нет, v52 и выше - да).
• FAR 4242, 15г. - c v0.42 работает. (v50,v51 - да)
• FAR 4700, 16г. - c v0.42 работает.
• FAR 4774, 16г. - c v0.29 работает.
• FAR 5225, 18г. - c v0.29 работает.
• FAR 5454, 19г. - c v0.29 работает.
• FAR 5511, 19г. - проверено, работает.
• FAR 6161, 23г. - проверено, работает.
• FAR 6378, 24г. - проверено, работает.
• FAR 6552, 25г. - проверено, работает.

Замеченные багофичи моменты:

• FAR 5804, 21г. - увеличилась производительность FAR-консоль, ViewColor эффективнее работает в режиме RealTime.
• FAR 5805, 21г. - Фаровский Clock (в углу экрана) всегда перекрывает и не видно WorkIndicator (с включенным ConEmuRefreshApiFar)
• FAR 6369, 24г. - таймер больше не накапливает опоздавшие события(?). ViewColor теперь не подлагивает при работе с клавишами.
• FAR 6552, 25г. - путается в показателях Dump/Hex. ViewColor всегда раскрашивает там, где не надо. Версия 6550 и 6558 - норм.
• FAR 6571, 25г. - поправили древнейший баг в QuickView после поиска F7 -> мусор на экране. Подробности.

v55 (26г.) - beta-версия (экспериментальная), ScrollFast + NoBlink, первая попытка "без мерцания". Но возможно глюки..
v54 (26г.) - ускорения 5% за счет меньшего Lua-сборки-мусора, ScrollFast на клавишу вверх/вниз, Standby через 5сек..60сек.
v53 (26г.) - конфигуратор цветов, import / export схем
v52 (26г.) - серьезная работа над ошибками, +10 ускорения (пропуск анализов в повторяющих знаков)
v51 (25г.) - ускорил производительность на 10% (выкинул лишнюю конвертацию в string)
v50 (25г.) - первый конфигуратор (только System и Global) + RealTime + Benchmark

[Ultrabyte]

Latest post of the previous page:

я именно так и сделал, а так же пробовал версию 0.32.

Вы правы. Попробовал версию 6161_x86 ошибка не воспроизводится. В старом 5787_x64 - устойчиво воспроизводится "vi is nil".

Оставлю код исключения, чтобы была совместимость со старыми FAR'ами.

[Ultrabyte]

Прошло полгода с момента 0.34 версии - зафиксировал 65 скачивании.
Судя по всему - это удачная и стабильная версия, не увидел здесь жалоб Да и у меня на рабочем компе исправно служит 0.34 без глюков.
Но решил таки доработать и "закрыть гештальт": раскрашивать списки. Это то, что умел делать в FarColor при редактировании текста.

Версия 0.35 (выложен в первом посте).

• Добавил ColorSpisok=(цвет), позволяет раскрашивать списки или перечисления, т.е. раскраска на скобку, точку, двоеточие.
  Обратите внимание на розовый цвет:

  

  Допускается замены на другой цвет, например, светло-серый.
  ColorSpisok = 0 или отрицательное - отключает данный функционал, если показалось излишне разноцветно.
• Добавил ViewTextClean=true который выполняет также как раннее ViewDumpClean: не раскрашивает бинарный код в текстовом окне (не dump/hex, а именно в "text")
  Удобнее читать, если внутри EXE, есть какие-то куски HTML.
  Обратите внимание режим "t" в верхней строке и часть кода не раскрашиваются:

  

  Хотя иногда возникают неудобства, в обычных TXT-файлах есть спец-коды для красоты оформления и из-за них срабатывает ложный триггер
  ViewTextClean = false - отключает данный функционал (вернуть как раньше)

[Ultrabyte]

Выложил версию 0.36.

• Исправлен старый баг: если нажать мышкой на F3-View, то нет раскраски. Если нажать клавиатурой F3, то раскраска есть.
  (обнаружил этот баг на ноутбуке с тачкрином, где пытался пальцем тыкнуть на экран и открыть просмотрщик. Теперь всё ок).
• Исправлен MouseWheel (колёсико) для версии Far ~ 6132 и выше. Раньше работало колёсико только в Far ~ 5787 и ниже. Теперь всё ок.
  (более точную версию Far'а когда "поломалось" - не интересовался)

Если будут новые глюки - сообщайте На всякий случай оставил предыдущую версию 0.34

[Ultrabyte]

Выложил версию 0.37.

• (продолжение с v0.29) исправлена ошибка в MultiTask (нажать на Ctrl-Tab -> мусор);
• (продолжение с v0.36) исправлен глюк MouseWheel (колёсико) при ConEmuRefreshApiFar=true
• Улучшено клавиатурное ожидание KeyPress(), теперь "слышит" знаки/рус-клавиши.
  Актуально при включенном ConEmuRefreshApiFar=true.
• Для ConEmuRefreshApiFar=true установлен таймер на 30 минут и отключается
  "удержания экрана", иначе происходило непонятное, замирал на 5 мин (чистка мусора?).
• (продолжение с v0.35) теперь автоматически отключает "расцветку цветов" при
  предварительном анализе и нахождения машинного-hex-кода в TEXT-экране.
  Плюсы: теперь НЕ отключает расцветку в любом нормальном текстовом файле.
  Раз получился автоматически, то убран флажок ViewTextClean.
• (продолжение с v0.31) исправлена ошибка в Windows Terminal при ConEmuRefreshForcibly=true,
  из-за этого флажка экран разбивался (сдвигаются символы из-за иероглифов),
  причем в ConEmu не портится (этот флаг как и задуман для ConEmu). Таким образом
  добавлен код определения: если экран "разбился", то автоматически переводит в false,
  и выдаст соответствующее сообщение: "ViewColor: auto-turn ConEmuRefreshForcibly=false"

  

  "разбитый" экран из-за иероглифов и соответствующее сообщение, после этого автоматически исправится, все будет Ок.

  Лучше самому перевести в false, чтобы не тратить ресурс постоянной проверки экрана.
• Для Dump'а добавлено "игнорирования ScrollBar" (долгое время у меня по дефолту
  был отключен ScrollBar, и ViewColor создан без учета этой вертикальной полоски,
  позже познал дзен с полоской ScrollBar, соответственно пришлось доработать код)
• Улучшил алгоритм чистки экрана в Dump-просмотре, не засвечивает бессмыслицу
  наподобие "ATAWA" во всех x64 EXE-файлах (вестимо VisualStudio так оскверняет);

  

  не засвечивает AVVAW, AVVWUSH. Теперь легко читаются куски: PDS_VERSION_IDI, Recurse/tags (читать задом на перед)

• Авто-пролистывания вперед/назад в режиме Dump'а при просмотре EXE/DLL на
  выявления куски текста (много мусора, но кое-что интересное попадаются).
  Клавиши: Space (если был поиск F7, то нет), >, Alt+Down - вперед или <, Alt+Up - назад
  На всякий случай добавил в режиме Dump'а (в exe,dll файлах) - подсказку:

  

  Всплывающая подсказка, чтобы не забыть об клавишах. Легко читаются: about:client

  Подсказка всплывает только один раз, до следующей перегрузки самого FAR'а.
  Если раздражают подсказки, то найти и переключить HintForDumpKey=false
• Расширил возможности Комментирования в файлах "python, pascal".
  Пришлось изрядно утяжелять код, чтобы исправно работало: /*/ или """
  И добавлен поиск по маске CmntFileMask="" и исключения CmntDontMask=""
  Это полезно, т.к. в Python'e запрещено триггерить знаком "//" или в С++ знаком "--"
• Добавлен простецкий алгоритм выделения цветов русских синтаксисов (названия, имена)

  

  Образец текста с выделенным желтым цветом в схеме -rus-

  Пока работает в схеме -rus- (это настраивается в NazvanieRus по-желанию user'ом).
• Увеличено быстродействие, что на пользу для нетбука Atom. Для примера: в версии 0.35
  при зацикленном 300 раз - тратилось от 40-50сек, то в текущей 0.37 тратится 9-14сек.
  Однако, иногда замечаю какое-то подтормаживание самого Lua-интерпретатора:
  иногда быстро отрисовывается, иногда статоры-лаги.

В итоге это значительное улучшение за весь год. Правда изначально, планировал добавить Диалоговые окна "Настройки", чтобы не копаться внутри ViewColor.lua. Но в процессе ковыряния кода - находил старые глюки, кривости, проводил оптимизации и "случайно" сделал автопоиск слов в Dump в качестве дебага (проверял работу функции распознания слов в тексте), потом подумал: "А что, интересно получилось, может людям тоже нужен автопоиск.. Пусть будет...". Улучшал то тут, то там, и пошло-поехало...
Для диалогового окна "Настройки" теперь нет места (на форуме максимально 260кб) и также в lua достиг предела "60 upvalues".

[Ultrabyte]

Осторожно выкатываю новую версию 0.38

• Исправлен баг раскраски Hex-экрана, если в файле сплошные "00". Теперь всё Ок.
• Доработал "прозрачность" в Hex-экране: теперь в маленьком hex-экране "видится" программой как один большой неразрывный массив (раньше разбивался с каждой строки и соответственно программа не очень понимала как раскрашивать "разбитые из двух полуслов").
• Добавил флажок ColorHexScreen=true - включает "красивости" в Hex-экране:

  

  цветные цифры и фиолетовая вертикальная полоса. Если переключить в "false", то вернет как прежде "голубой на синем фоне"

  Если нужны "красивости", но с другими цветами под себя, то самому найти фразу "ColorHexScreen" в коде и после несложного вдумчивого осмотра - поменять на соответствующие коды-цветов под себя. Если лень копаться в кодах, то проще переключить в false (ColorHexScreen=false) и успокоится =)
• Исправил старый баг, который НЕ показывал окно ProgressBar, если нажать Shift-F7 на много-гиговый файл:

  

  Раньше не показывал ProgressBar, теперь всё Ок.

[Ultrabyte]

Выложена новая версия v0.39.

• досрочный выход новой версии, в связи с тем, что другой скрипт Dialog.ConvertTo16bit.lua конфликтовал с ViewColor.
• оптимизировал часть кода, высвободив где-то 5кб, это позволит в будущем добавить новых фичей (например, "Диалог настройка" ?)
• выделенный блок в просмотрщике - больше не теряются. Но пока до сих пор не ясен вопрос, как посредством стандартной функции получить "пользовательские настройки цветов в FARе для выделенного блока". Я получаю только RGB цветов, а нужны 1-байтовый: от 0x00 до 0xFF (все 16 цветов). Если будет найдено решение, то высвободится ~ 3кб кода.
• Чуть улучшил быстродействие работы с консолями. Хотя этого не требовалось, но возможно, поможет уменьшить утечки памяти, не потребуется много работы "уборщику мусора".
• Оставил временный код "бенчмарк" - вызывается нажатием Shift-F12. Возможно кому-то интересно сравнить/изучать проблему LUA.

=== Бенчмарк ====

В прошлой версии упомянул, что есть какие-то статоры-подлагивания в интерпретаторе LUA.
Решил исследовать, с какого момента начинают "статоры" и от чего. Добавил код "бенчмарк", который показывает статистику: "стрелку вниз" - это минимальное число FPS, и "стрелку вверх" максимальное число FPS. Подсчитывает 10 раз по 5 секунд. Длительность 1 минута.
"И шо вы думаете?"(с) - вопросов стало больше

Попробую изложить краткую суть:

• в каждой версии (v28, v36, v38, v39) добавил идентичный код-бенчмарка, и у каждой своя клавиша вызова.
• запускаю один Far v6388 x64 на готовые четыре версии ViewColor (в папке Script лежат одновременно четыре Lua-файлы)
• открываю просмотрщиком файл NIL (нулевой размер файла), на экране пусто, нажимаю соответствующие клавиши бенчмарки, заскриншотил несколько вариантов:

  

  Действительно, появилась путаница и шатания в цифрах, в верхнем случае - дикие статоры/подлагивания (условно скажем "приуныл"). Несколько раз нажимал (~ 5 раз), вдруг устаканивается в лучшие показатели (почти в 2 раза) по всем показателям, условно назовем "борзый".
• Включил ScrollBar - это заставляет запускать другая часть программного кода для "обхода вертикальной полоски". Другими словами, ViewColor начинает "напрягаться" сильнее, чтобы слова и тексты не разрывались при переходе на следующей строки. И как видим, FPS значительно просел, чуть меньше в 10 раз:

  

  Результаты аналогичны: заметны статоры/подлагивания (разница "сверху" и "снизу"), которые занижают в 2 раза показатели.
• Закрались сомнения насчет правдивости, а нет ли пропуски кадров? Возможно LUA как-то задействовал "Skipped" часть кода, если вводные данные не меняются (экран статичен)? или Windows Console делает Skipped кадров, если "цвета" не меняются?
  После недолгих раздумий, решил добавить в бенчмарке "нажатия стрелки вниз", автоматически пролистает экран вниз. И тут, меня ошеломило, теперь видно глазами какие жуткие статоры: иногда останавливается чуть менее 1 секунды, чаще всего в версии ViewColor_v28. У остальных версии - равномерные тормоза. И вдруг, будто срывается с цепи и мгновенно мелькает перед глазами как ракета, что едва успеваешь зацепиться глазами (скорость возросла в 3 раза).

  

  Проверил по стоп-кадрам - действительно, цветовые раскраски присутствуют, значит "Skipped" не было.
  Интересный момент: в версии v39 никак не удавалось "раздуплится" на максимальную скорость, многократно нажимал на бенчмарк - бесполезно. Перешел на Far x32 и сработало, что и продемонстрировано на скриншоте - скорость в 5 раз выше. Также интересное наблюдение: иногда попеременно то быстро, то медленно - видим большую разницу дельта значении "min" и "max" (18fps и 84fps у v39)
• Пробовал также собрать статистику на просмотр файла ViewColor.lua (достаточно объемный) и требуют значительного ресурса на "знаки комментирования". Или как вариант на просмотр объемного файла Far-Changelog. В итоге - статистика сложилась аналогичной "туда-сюда" разброд и шатания. Не стал добавлять скриншоты, чтобы не засорять лишними цифрами.

Что пробовал сделать:

• разные версии Far 5225, 5787, 6388 (это 18г...24г.) - не влияет.
• разные архитектуры Far x32/x64 - абсолютно другой "рандом", может повезти с первого захода, а может "тугодумить" вечно.
• удалял всё в папке Plugins (кроме LuaMacro) и удалял всё в "Script" (кроме четырёх ViewColor.lua) - не влияет.
• удалял преднастройки Far-Config. Чистый дефолтный Far, оставив только размер консоля 100x35 - не влияет.
• Win10, Terminal, векторный шрифт -vs- Win7, WinConsole, растровый шрифт - не влияет.
• файл ViewColor.lua содержит кодировку Ansi или UTF8 - не влияет
• Добавлял в коде остановку сборщика мусора - заметил как резко возрастает выделенную память Far.exe до 1,6гигабайт и статоры усиливаются.
  Но если удалось с первого захода "раздуплиться" на максимальную скорость (без лагов и статоров), то память достигает скромных значении (начинает рост от 8мб и останавливается до 180мб).
• убрал все слова "local" (сделав переменные/функции глобальными) - особо роли не играют, статоры и лаги остались. Лучше или хуже - не вдавался.

Подвожу итог:

• Никак не удается стабилизировать показатели бенчмарка, т.к. бывают неожиданные статоры (1 секунда в v28) или "ракета".
• Если отсеять "неудачные цифры", то в целом прослеживаются значительные улучшения программного кода по ускорению ViewColor от v28 до v39. В некоторых случаев, возрос в 2 раза по среднему FPS.
• требуется серьезная консультация специалистов по теме лаги/статоры, или обратить внимание разработчикам по этой проблеме.
  В противном случае, весьма трудно получать достоверные данные FPS, при замене какого либо кода, например, что быстрее: работа string.xxx или utf8.xxx или ffi.string? таблица или множество локальных переменных ? функция внутри функции или сделать внешней? "разбивать" ли сложные функции на составные функции? и так далее...

[Shmuel]

Извиняюсь, но что такое статор ?
Википедия говорит

Ста́тор (англ. stator, от лат. sto — стою) — неподвижная часть электрической, лопаточной и другой машины, взаимодействующая с подвижной частью — ротором.

[Ultrabyte]

от лат. sto — стою

Это устоявшиеся жаргон среди игроманов, разве не?
Проверил, действительно, у "английского гугла" не встречаются "stator in game" только "stutter in games" (заикания).

[Shmuel]

Благодарю за пояснение. Игроманом не был, поэтому сразу не понял.

[Shmuel]

например, что быстрее: работа string.xxx или utf8.xxx или ffi.string?

Скорее всего string.xxx быстрее, чем utf8.xxx, но ведь они часто не взаимозаменяемы.
А ffi.string совсем с этими не взаимозаменяема.

таблица или множество локальных переменных ?

Локальные переменные.

функция внутри функции или сделать внешней?

Примерно одно и то же.

"разбивать" ли сложные функции на составные функции? и так далее...

Разбивать в разумных пределах, ориентируясь на читаемость кода, а не на быстродействие.

Однако всё вышесказанное не поможет, пока не будет произведёно профилирование, которое позволит точно определить, на что уходит большая часть времени. Есть разные "профайлеры" для Луа, в том числе встроенный в LuaJIT (https://luajit.org/ext_profiler.html)

[Shmuel]

Добавлю (в общем-то общеизвестное) - часто алгоритм обработки имеет определяющее значение в быстродействии. Какие-то локальные оптимизации могут улучшить быстродействие на 10 процентов, а выбор оптимальных алгоритмов - в разы.

[Ultrabyte]

выбор оптимальных алгоритмов - в разы.

Согласен.
На мой взгляд есть два алгоритма: числовой и "стринговый" (строковый).
Преимущества "стрингового" алгоритма - это связать с RegExp. Однако по моей неопытности, сходу выбран "числовой" алгоритм.
Чтобы переделать в "стринговый" алгоритм, то проще удалить и начать заново "жить", т.е. маловероятный исход. Кому-то хочется на это тратить человеко-часы? Вот и я тоже)
Поэтому исхожу от другой позиции - выбирать по наименьшему сопротивлению:

• Если был выбран "стринговый" (с прицепом на RegExp), то как практика показала, требуется невероятных усилии. Причина: отсутствия наличии такового на форуме и на плагринге (я ждал 10 лет).
• Если выбран "числовой" алгоритм, то на его создания хватило силы одного человека без опыта.

Вывод: числовой алгоритм - значительно проще, чем "стринговый".

update: Вообще насколько быстрее RegExp ?
Судя по всему, при открытии ViewColor.lua через F4-Edit - потребовалось 1 секунду (FarColor + RegExp), то для F3-View - потребовалось 3 секунды по-страничного пролистывания (ViewColor на "числовом" алгоритме).
Но, вводные условия разные: FarColorer откомпилирован на C++ (?), ViewColor работает на "унылом/веселом LUA".

update2: Интересный эксперимент:

• открыл changelog (far 6388) через F4-edit (курсор запомнился в конце файла) - засекал таймер и ждал раскраску и... потребовалось 24,11 секунд. И да, в FarColor у меня добавлена схема раскрасок для обычного текстового файла, весьма похожей той раскраске как в ViewColor.
• Теперь открыл файл F3-View (WordWrap включен) и нажал Shift-F12, чтобы по-бенчмаркнуть до конца файла, и ViewColor постранично достиг конца changeLog за 16,88 секунд (135fps, т.е. "Lua в хорошем настроении").

Проверил еще на тяжелом temp.lua (5,7мб), который состоит из 22 раз копипасты содержимого из viewcolor.lua.

• F4-Edit (FarColor) справился до конца файла за 38 секунд (проверил два раза, одинаково, видимо не кэшируется)
• F3-View (ViewColor, схема -code-) - пролистал до конца за 37 секунд. Второй раз - за 38 секунд. (~ 100fps)

Удивил... теперь не знаю какой алгоритм может дать "в разы".

• А вот когда "Lua приуныл", то печальные показатели: ViewColor "приползла" за 1 мин и 5 сек (~ 60fps), на том же temp.lua.

функция внутри функции или сделать внешней?

Примерно одно и то же.

Вроде как-то случайно обнаружил, что если local function находился внутри еще local function, то у меня замедлялся, вероятнее всего, из-за чистки мусора, который постоянно удалял лишние дочерние "local function" из памяти. И таких вызовов функции 3300 раз (консоль 100x35) за 1 сеанс.
Но сейчас не разберу, то-ли из-за "Lua приуныл", то-ли еще чего...

К сожалению, разобраться с "профайлерами" это слишком глубокие дебри...

to All:
В первом посте, перевыложил "чуть переделанную" ту-же версию v39, а точнее, вернул удаленную функцию DeleteColorProgress().
С этой функцией, всё-же приятнее, нет кратковременных "дребезгов" на экране, когда пользуешься поиском F7.

Хотя это не критично, но всё-же... И да, не получилось таки сэкономить "драгоценные килобайты"

update: чтобы не было путаницы - внутри ViewColor.lua обновил даты: с 11.11.24 на 13.11.24

[Shmuel]

Если был выбран "стринговый" (с прицепом на RegExp), то как практика показала, требуется невероятных усилии. Причина: отсутствия наличии такового на форуме (я ждал 10 лет).

Не очень понятно, что отсутствует на форуме? Чего вы ждали 10 лет?

[Ultrabyte]

раскраску просмотрщика (на форуме и на плагринге)

[Shmuel]

Ну отлично, вы это сделали! Кому-то другому уже не придётся ждать

[Ultrabyte]

так как все таки вытащить из far однобайтовый цвет? )

Color=far.AdvControl("ACTL_GETCOLOR", far.Colors.COL_VIEWERTEXT)

Color должен получить 0x1B, согласно по таблице цветов, а получаю RGB...
Этот вопрос висит с прошлого года... Кто нибудь понимает "в этом вашем интернете"(c) ?