Плагин входит в дистрибутив Far Manager с v3.0.2948 (старые версии доступны тут) Поддержка Windows XP
Начиная с версии FarColorer 1.4.0 в плагине прекращена поддержка Windows XP. Полностью поддерживается и тестируется на Windows 10. Несколько версий Windows назад - по запросу. Но кажется, что всегда должно работать начиная с Windows 2008.
Far Manager 3.0.5797 (2021.05.10) и более новые в дистрибутиве содержат FarColorer версии 1.4.
Поддержка Windows XP осталась только на FarColorer 1.3.x. В данной ветке будут выходить только критичные исправления. Скачать можно на GitHub странице плагина. Последняя версия 1.3.30
Опционально плагин способен отображать текст в RGB режиме, и используя разные стили (bold/italic/underlined).
Этот режим называется TrueMod, для его работы в FAR 3 требуются специальный эмулятор консоли: Conemu.
Скриншоты можно глянуть странице проекта (актуальны только изображения, а описание немного устарело, в частности Console2 больше не поддерживается).
Или подключить пользовательские *.hrd в пользовательском catalog.xml
Внимание: в пользовательском файле цветовых стилей пути вычисляются относительно catalog.xml
В настройках плагина указать путь к файлу: Users file of schemes.
(Структура файла аналогична hrc\proto.hrc)
используя папку auto:
Два варианта:
Cоздать свой аналог proto.hrc и прописать туда прототипы, а в папку types положить сами схемы.
Минимальный (пустой) пример файла прототипов есть в дистрибутиве: auto/empty.hrc.
Внимание:empty.hrc служит для примера, изменять его не рекомендуется, т.к. при обновлении изменения потеряются.
Можно обойтись без отдельного файла прототипов, а разместить схемы непосредственно в папке auto.
Прототип в этом случае должен быть определён в самой схеме после тега <hrc>, без указания location
через пользовательский catalog.xml:
Вместо штатного base/catalog.xml можно использовать свой файл, указав путь к нему в настройках плагина.
В своём каталоге можно указать откуда загружать пользовательские прототипы и схемы.
Чтобы переопределять дистрибутивные схемы собственными надо пользовательский файл прототипов подключать после штатного proto.hrc:
Также в catalog.xml можно добавить пользовательские цветовые стили, см. <hrd-sets>
Как переопределить существующую схему
Для этого достаточно подключить собственную схему с тем же именем (name).
Если требуется изменить только параметры схемы (filename, firstline, parameters), то достаточно прототипа, как он указан в common.zip!hrc/proto.hrc. location схемы при этом нужно указать примерно так (для hrc-файла, находящегося в папке FarColorer\base\auto):
Как правильно "удалить" какую-либо стандартную схему
Чтобы какая-либо из стандартных схем исчезла из меню, надо в пользовательском файле прототипов "переделать" схему в пакет с тем же именем (name), например:
Кроме имени важно также сохранить значение location, потому как даже если эта схема вам не нужна, но от неё могут зависеть другие, нужные вам.
Как использовать относительные пути и переменные окружения
В настройках плагина при указании пути к catalog.xml удобно использовать переменные окружения, такие как %FARHOME%, %FARPROFILE%.
Переменные можно использовать и в самом файле catalog.xml, и в определениях прототипов.
Кроме того поддерживаются относительные пути во всех hrc файлах (путь вычисляется относительно файла, в котором он указан). Внимание: в пользовательском файле цветовых стилей (hrd) пути вычисляются относительно catalog.xml
Если раскраска неправильна:
В первую очередь нужно убедиться что тип файла определён верно (F11/FarColorer/List types).
В случае если определился не тот тип, что требуется, можно выбрать из списка более подходящий.
Или же переопределить типы, подкорректировав "условия срабатывания" схемы, заданные в атрибутах <filename> и/или <firstline>.
Часто достаточно подкорректировать атрибут weight='2', изменив умолчательное значение (2) в ту или иную сторону.
Не рекомендуется редактировать штатные прототипы и схемы, т.к. при обновлении изменения потеряются.
Как правильно переопределить схемы описано в других пунктах данного FAQ
Тонкая настройка подсветки для отдельной схемы: в теме.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Fri 25 Jan, 2019 19:35
by kobri
Latest post of the previous page:
Я когда-то уже предлагал другой вариант решения проблемы медленной раскраски - можно в самом колорере проверять, с помощью GetNumberOfConsoleInputEvents, активен ли в данный момент пользователь, и просто не отдавать управление фару пока нет никаких событий консоли. Тогда и настроек никаких не понадобится и раскраска будет идти на максимально возможной скорости, пока пользователь ничего не делает.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Fri 25 Jan, 2019 23:50
by BioSpb
безусловно, вы знаете как работает фар и колорер больше меня. и наверняка можете предложить вариант на порядок лучше.
спасибо за пояснение.
я, прежде чем написать, опробовал некоторые изменения.
во-первых, попробовал убрать изменение idlecount, сделав его всегда равным 10. в итоге, раскраска changelog уменьшается совсем немного, но если делать активность в редакторе, то без этого - время полной раскраски становится больше минуты. изменение никакого дискомфорта не создает.
во-вторых, я попробовал уменьшить время таймера в 2 раза. скорость раскраски повысилась, но мне показалось это не правильным, и поиски того, как увеличить кол-во строк за один вызов привели меня в эти функции.
в-третьих, я попровал увеличить кол-во строк за раз до 3000.
и раскрашивание (changelog до конца) сократилось до 3 секунд, даже если что то делать в редакторе!
привязку к backparse я предложил потому, что этот параметр уже существует, и он как бы должен быть таким, чтобы открытие среднестатистического файла (без длинных строк и сложной схемы) было незаметно, т.е. меньше половины или даже четверти секунды.
следовательно, если за пол секунды парсить в фоне еще по половине этого кол-ва, то это будет более чем комфортно во всех ситуациях.
в идеале лучше конечно сделать, чтобы колорер отслеживал время парсинга строк, и возвращал управление с каким то интервалом.
т.е. параметром было бы действительно время, а не число строк.
;уменьшение таймера примерно в 2 раза
000031B0: 01 00
000031B8: 01 00
;idlecount всегда равен 10
000075F2: 7E 90
000075F3: 08 90
; увеличение кол-ва строк для парсинга до примерно 3000 за один вызов
00007619: 64 00
0000761A: 00 02
0000761D: 3B 90
0000761E: C1 90
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Sat 26 Jan, 2019 23:26
by BioSpb
еще патч для colorer.dll x64 от 25.01.19 - увеличивает кол-во раскрашиваемых строк в 6,4 раза с сохранением плавного набора скорости.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Sun 27 Jan, 2019 08:45
by ctapmex
все эти цифры очень зависят от типа файла и процессора. похоже надо в параметры выносить.
ну и только дошло -проблема длинных строк в том, что поиск регулярного сообщения по такой длинной строке работает дольше, может захватить больше. чем если бы это было разбито на меньшие строки. что с этим делать не понятно. даже если отдельным потоком разбирать это очень долго.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Sun 27 Jan, 2019 11:38
by HaRT
ctapmex wrote: ↑Sun 27 Jan, 2019 08:45 эти цифры очень зависят от типа файла и процессора. похоже надо в параметры выносить
Раз зависят от типа файла, получается, что добавлять надо в параметры схемы.
И вновь прошу: пусть настройка будет выражена в максимально понятных не-программисту терминах. Я готов поучаствовать в их выработке.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Sun 27 Jan, 2019 12:00
by Sim
ctapmex, если в файле с длинными строками разбить эти длинные строки переносами на отдельные более короткие строки то раскраска происходит быстро, может действительно сделать разбивку на подстроки по 500 символов например, внося переносы после ; и } например, в зависимости от типа файла, конечно, маркерные символы для разбивки будут разные.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Sun 27 Jan, 2019 12:05
by BioSpb
я пошел по пути наименьшего изменения. даже перекомпилировать не пришлось.
поскольку кол-во строк зависит от схемы, файла и процессора, еще раз повторюсь, в идеале - при разборе строк замерять время, и после какого то интервала (задаваемого в настройках), возвращать управление. (парсить по N строк, мерять время и если превысили лимит - выходить)
т.е. нужны два параметра - интервал времени парсинга перед открытием файла, и интервал времени парсинга в фоне.
плавное увеличение, наверное можно оставить, чтобы при бездействии быстрее раскрашивало.
с длинными строками можно попробовать сделать такую штуку. чаще всего это файлы без перевода строк, обычный код, и искать парные элементы по всей длине не нужно. хотя могут быть и исключения, типа json на несколько метров в одну строку.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Sun 27 Jan, 2019 12:13
by Sim
BioSpb wrote: ↑Sun 27 Jan, 2019 12:05
и искать парные элементы по всей длине не нужно
без поиска парных элементов теряется смысл раскраски синтаксиса.
А как происходит поиск парных элементов если файл разбит на строки и парные элементы в разных строках находятся? почему это быстрее чем когда все в одну строку? если так работает алгоритм поиска и его не получится легко переделать, то надо делать разбивку на подстроки в памяти.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Sun 27 Jan, 2019 19:17
by zg
ctapmex wrote: ↑Sun 27 Jan, 2019 08:45ну и только дошло -проблема длинных строк в том, что поиск регулярного сообщения по такой длинной строке работает дольше, может захватить больше. чем если бы это было разбито на меньшие строки. что с этим делать не понятно. даже если отдельным потоком разбирать это очень долго.
если красить только видимую часть строки — работает быстрее.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Sun 27 Jan, 2019 20:02
by BioSpb
zg wrote: ↑Sun 27 Jan, 2019 19:17
если красить только видимую часть строки — работает быстрее.
а если перейти в конец этой строки? все равно нужно ее отпарсить целиком.
ctapmex, можете пояснить, потому так получается, что код, скажем на 1000 строк, парсится быстро. А то же самый код, собранный в одну строку - медленно? ведь колорер не оперирует одной строкой. он находит парные элементы расположенные в разных строках. правильно парсит мультистрочные конструкции и т.п.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Sun 27 Jan, 2019 20:17
by BioSpb
Sim wrote: ↑Sun 27 Jan, 2019 12:13
без поиска парных элементов теряется смысл раскраски синтаксиса.
я имел ввиду, что парные элементы находятся близко, и по всей длине строки искать их не нужно.
Sim wrote: ↑Sun 27 Jan, 2019 12:00
может действительно сделать разбивку на подстроки по 500 символов например, внося переносы после ; и } например, в зависимости от типа файла, конечно, маркерные символы для разбивки будут разные.
да да, меня аналогичная мысль посещала. для json это может быть запятая вне ковычек, и т.п.
но вообще, наверное, стоит подумать над более общим решением. например, парсить не строками, а килобайтами.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Sun 27 Jan, 2019 20:26
by zg
BioSpb wrote: ↑Sun 27 Jan, 2019 20:02а если перейти в конец этой строки? все равно нужно ее отпарсить целиком.
а причём тут парсинг строки? строку в любом случае надо парсить целиком, иначе контекст потеряется. речь о раскраске. читайте внимательно.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Mon 28 Jan, 2019 07:41
by Garrett
BioSpb, пожалуйста, выложите свою патченную colorer.dll x64. Потестирую.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Tue 29 Jan, 2019 06:20
by Garrett
BioSpb, а что означают номера? Какой вариант быстрее в вашем понимании?
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Tue 29 Jan, 2019 11:36
by BioSpb
в первом случае фоновая раскраска всегда постоянная - по 2560 строк каждые полсекунды.
во втором случае - скорость раскраски с плавным изменением увеличена в 6.4 раза до 896-3200. в оригинальным варианте: 140-500. (увеличение происходит каждые полсекунды, если ничего не трогать в редакторе. всего 10 итераций)