Плагин входит в дистрибутив 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: Thu 24 Jan, 2019 14:36
by 2useven10
Latest post of the previous page:
grnt666 wrote: ↑Thu 24 Jan, 2019 14:32
Можно ли узнать подробности, в чем же было дело?
А читать не пробовали? В теме всё есть.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Thu 24 Jan, 2019 14:47
by grnt666
2useven10 wrote: ↑Thu 24 Jan, 2019 14:36
А читать не пробовали? В теме всё есть.
В теме - суть исправлений размыта. Автор закоммитил несколько багов одновременно. А та ошибка, о которой я написал (и писали до меня), как оказалось, давно исправлена, а автор просто не знал, что она не включена в релиз! Этой ошибке в FAR 3 как минимум 3 года, она некоторое время прожила и во втором фаре. Поэтому интересно узнать подробности.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Thu 24 Jan, 2019 15:29
by 2useven10
grnt666 wrote: ↑Thu 24 Jan, 2019 14:47 А та ошибка, о которой я написал (и писали до меня), как оказалось, давно исправлена, а автор просто не знал, что она не включена в релиз!
нет.
grnt666 wrote: ↑Thu 24 Jan, 2019 14:47 Этой ошибке в FAR 3 как минимум 3 года
да.
grnt666 wrote: ↑Thu 24 Jan, 2019 14:47 она некоторое время прожила и во втором фаре
нет.
Читайте ещё раз.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
ctapmex wrote: ↑Thu 24 Jan, 2019 05:46
попробую с таймером. но разницы с точки зрения "неубиваемо" не будет. EditorSet - общий класс, уничтожается только при выгрузке плагина/остановке фара.
в 2015 году в far отключили генерацию пустых событий, за счет которых colorer брал управление для прокраски в фоне. исправление - генерация этих событий внутри colorer
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Fri 25 Jan, 2019 10:14
by John Doe
Баг. В списке типов не работает F1.
В справке соответствующий раздел предусмотрен: @filetypechoose
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Fri 25 Jan, 2019 10:31
by Sim
сейчас, в Far 3.0.5356 Colorer раскрашивает файлы с длинными строками, но редактировать такой файл не возможно, любое нажатие клавиши, которое вносит изменение в код, вызывает алгоритм раскраски и фар замирает пока colorer не раскрасит все заново, это очень плохо.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Fri 25 Jan, 2019 11:01
by ctapmex
John Doe wrote: ↑Fri 25 Jan, 2019 10:14
Баг. В списке типов не работает F1.
В справке соответствующий раздел предусмотрен: @filetypechoose
работает, проверь еще раз. может макросы или что еще
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Fri 25 Jan, 2019 13:20
by John Doe
ctapmex wrote: ↑Fri 25 Jan, 2019 11:01
работает, проверь еще раз. может макросы или что еще
Проверил, действительно работает.
Не знаю что за глюк был.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Fri 25 Jan, 2019 15:06
by BioSpb
ура, фоновая раскраска заработала!
но только оооочень медленно.
changelog раскрашивается до конца за 24 секунды!
FAR2 делает это за 8 секунд.
можно как то это ускорить?
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Fri 25 Jan, 2019 17:55
by ctapmex
ускорить - вынесу в настройки. но для этого надо формы перерисовать, уже вставлять параметры некуда
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Fri 25 Jan, 2019 18:14
by buniak_a_h
ctapmex wrote: ↑Fri 25 Jan, 2019 17:55
для этого надо формы перерисовать
Если Трудоёмко, то может в файле, аналогичном hrcsettings.xml (hrcsettings.xml.user)?
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Fri 25 Jan, 2019 18:14
by BioSpb
на сегодняшнем билде - больше 30 сек!
если вяло перемещаться по редактору, то больше минуты.
я могу ошибаться, но мне кажется решение проблемы кроется в этих двух местах:
#define IDLE_PARSE(time) (100+time*4)
void BaseEditor::idleJob(int time)
{
if (invalidLine < lineCount) {
if (time < 0) {
time = 0;
}
if (time > 100) {
time = 100;
}
validate(invalidLine + IDLE_PARSE(time), false);
}
}
максимально передается число 100 - дальше оно пребразуется в 500. почему то считается, что это время, и возможно поэтому в queuetimer тоже используется 500 (мс). наверно просто совпадение).
но по факту: 500 - это число строк, которое за раз парсит колорер.
32000 строк, минус 6000, разделить на 500 - 52 вызова через полсекунды - это 26 секунд, не учитывая плавный набор. с ним больше 30.
использование idleCount=10 уменьшает время только если одновременно что то делать в редакторе.
наверное стоит поправить в libcolorer ограничение или просто умножить на 10. ну или вынести это в конфиг.
это позволит сократить время раскрашивания changelog до 3 - 3,5 сек.
при отключенном backparse, он раскрашивается за 2,5 секунды. но эта задержка перед открытием жутко бесит.
на многих файлах поменьше задержка в полсекунды тоже заметна.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Сложно ли сформулировать настройку в пользовательских терминах? Например, как долю времени, отводимую на очередную порцию покраски; или как допустимый уровень использования процессора; и т.п.
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Fri 25 Jan, 2019 18:54
by BioSpb
можно за основу взять значение backparse.
например, так:
int FarEditor::editorInput(const INPUT_RECORD &Rec)
{
if (Rec.EventType == KEY_EVENT && Rec.Event.KeyEvent.wVirtualKeyCode == 0) {
if (baseEditor->haveInvalidLine()) {
baseEditor->idleJob(BackParse/2);
info->EditorControl(editor_id, ECTL_REDRAW, 0, nullptr);
}
}
return 0;
}
void BaseEditor::idleJob(int lines)
{
if (invalidLine < lineCount) {
if (lines < 500) {
lines = 500;
}
validate(invalidLine + lines, false);
}
Colorer — гибкая раскраска синтаксиса в редакторе и др.
Posted: Fri 25 Jan, 2019 19:23
by ctapmex
так, мы с вами почти в равных условиях. Вы код почти не видели, а я видел давно и все забыл -)
давайте разбираться, и прояснять разные моменты. Мне для памяти, вам для понимания что и как
на текущий момент есть 2 "потока" разбора.
Первый - это фоновый. Изначально он работал от событий фара. То "ускорение" в коде idleCount++ сделано специально, что скорость разбора, или иначе тормоза gui, надо наращивать постепенно. Вдруг пользователь печатает текст. Мы же в редакторе всё таки.
Второй - это разбор во время события раскраски экрана. Нам важно разобрать что на экране. И это быстро и легко, если мы в начале файла. А если в конце, то ждать можно долго.
для этого и задумывался параметр backparse. работает это так (не так как я вижу у вас в описаниях)
если (номер_строки_для_отображения - номер_последней_нераскрашенной_строки > backparse )
то не разбираем файл, не красим сейчас. оставляем для фона.
иначе пытаемся разобрать все до номер_строки_для_отображения
что мы имеем, если файл 1000 строк, backparse 100.
1. файл открывается на первой странице, нам видны первые 25 строк.
при открытии мы будем красить вторым потоком до конца экрана, потом перейдем в фон. если строки длинные, то будет подвисание. т.к. событие раскраски срабатывает до того как отобразился текст
2. файл открывается на 10 странице, текущая строка 250 - последняя 275.
файл открывается сразу, т.к. во втором потоке срабатывает параметр backparse. текст мы видим. разбор идет фоном раз в N мск.
если мы через некоторое время нажмем клавиши, то очень вероятно , что backparse не будет уже работать и экран быстро раскрасится
3. файл открываем в самом конце
ситуация как в пункте 2, только ждать раскраски экране дольше
если мы увеличиваем backparse до 500
1. не изменится
2. ждать дольше
3. ждать меньше
если мы увеличиваем backparse до 2000
1. не изменится
2. не изменится относительно предыдущего теста. но на строках после 500 будет медленнее
3. ждать дольше. будет медленнее работать
если мы уменьшаем backparse в плоть до 0
1. не изменится
2. будет быстрее разбираться, но открытие файла дольше. разбираем сразу 250 строк
3. будет быстрее разбраться, но открытие файла дольше. разбираем сразу 1000 строк
получается, скорость разбора зависит от того, где в файле мы находимся и значения backparse.
касательно примеров кода выше. Если мы увеличим число строк для разбора за один раз, то это негативно скажется на скорости реакции фара при изменении текста.Мы ведь в редакторе, и это критично. Но мы точно можем отказаться от постепенного наращивания idleCount++ , сделав его константой. Т.к. сейчас функция вызывается через известные равные таймауты.
кстати, для длинных строк не забываем про maxlinelength. надо будет его уменьшить по умолчанию до 500. будет легче.
как итог, получается надо обеспечить
а. быстрое открытие файла, пусть и не раскрашенного
б. учет положения в файле при работе с backparse