Colorer — гибкая раскраска синтаксиса в редакторе и др.

Здесь можно обсудить ваш любимый плагин.
User avatar
ctapmex
Posts: 1063
Joined: Fri 11 Apr, 2008 07:53
Been thanked: 10 times
Contact:

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by ctapmex »

Far Colorer — плагин подсветки синтаксиса в редакторе, основанный на Colorer Library Игоря Русских.
  • Изначальный автор плагина — Игорь Русских (lomecb, он же cail).
  • После того как плагин портирован на Far 2, поддержкой занимается Алексей Добрунов (ctapmex, он же на форуме ctapmex).
  • Официальная поддержка осуществляется через google-группу colorer_ru (на форуме бывает только ctapmex).
  • Актуальные версии основаны на Colorer Library версии take5.
GitHub | Анонс | Старые домашние страницы библиотеки Colorer и плагина для FAR

Плагин входит в дистрибутив Far Manager с v3.0.2948 (старые версии доступны тут)



Что не разжёвано в документации плагина:
  • Как подключить собственные цветовые стили *.hrd
    Пример: viewtopic.php?p=160386#p160386
  • Как подключить собственную схему:
    • используя пользовательский файл прототипов:
    • используя папку auto:
    • через пользовательский catalog.xml:
  • Как переопределить существующую схему
  • Как правильно "удалить" какую-либо стандартную схему
  • Как использовать относительные пути и переменные окружения
  • Если раскраска неправильна:
  • Неочевидные настройки: maxlinelength (в теме)
  • Тонкая настройка подсветки для отдельной схемы: в теме.

User avatar
ctapmex
Posts: 1063
Joined: Fri 11 Apr, 2008 07:53
Been thanked: 10 times
Contact:

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by ctapmex »

Latest post of the previous page:

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

buniak_a_h
Posts: 1852
Joined: Sat 20 Apr, 2013 00:17
Location: Питер
Has thanked: 116 times
Been thanked: 165 times
Contact:

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by buniak_a_h »

ctapmex wrote:
Fri 25 Jan, 2019 17:55
для этого надо формы перерисовать
Если Трудоёмко, то может в файле, аналогичном hrcsettings.xml (hrcsettings.xml.user)?

BioSpb
Posts: 13
Joined: Thu 13 Jan, 2011 22:18
Has thanked: 2 times

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by BioSpb »

на сегодняшнем билде - больше 30 сек!
если вяло перемещаться по редактору, то больше минуты.

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

Code: Select all

int FarEditor::editorInput(const INPUT_RECORD &Rec)
{
  if (Rec.EventType == KEY_EVENT && Rec.Event.KeyEvent.wVirtualKeyCode == 0) {

    if (baseEditor->haveInvalidLine()) {

      idleCount++;
      if (idleCount > 10) {
        idleCount = 10;
      }
      baseEditor->idleJob(idleCount * 10);
      info->EditorControl(editor_id, ECTL_REDRAW, 0, nullptr);
    }
  } else if (Rec.EventType == KEY_EVENT) {
    idleCount = 0;
  }

  return 0;
}

Code: Select all

#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 секунды. но эта задержка перед открытием жутко бесит.
на многих файлах поменьше задержка в полсекунды тоже заметна.

User avatar
HaRT
Moderator
Posts: 9421
Joined: Tue 30 Aug, 2005 17:21
Location: Санкт-Петербург
Has thanked: 105 times
Been thanked: 219 times

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by HaRT »

ctapmex wrote:
Fri 25 Jan, 2019 17:55
ускорить - вынесу в настройки
Сложно ли сформулировать настройку в пользовательских терминах? Например, как долю времени, отводимую на очередную порцию покраски; или как допустимый уровень использования процессора; и т.п.
Фар есть инструмент, а не нянька. © 2009 DrKnS

BioSpb
Posts: 13
Joined: Thu 13 Jan, 2011 22:18
Has thanked: 2 times

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by BioSpb »

можно за основу взять значение backparse.
например, так:

Code: Select all

int FarEditor::editorInput(const INPUT_RECORD &Rec)
{
  if (Rec.EventType == KEY_EVENT && Rec.Event.KeyEvent.wVirtualKeyCode == 0) {

    if (baseEditor->haveInvalidLine()) {

      idleCount++;
      if (idleCount > 5)
        idleCount = 5;
      baseEditor->idleJob(BackParse*(idleCount+1)/6);
      info->EditorControl(editor_id, ECTL_REDRAW, 0, nullptr);
    }
  } else if (Rec.EventType == KEY_EVENT) {
    idleCount = 0;
  }
  return 0;
}

void BaseEditor::idleJob(int lines)
{
  if (invalidLine < lineCount) {
    if (lines < 500) {
      lines = 500;
    }
    if (lines > INT_MAX) {
      lines = INT_MAX;
    }
    validate(invalidLine + lines, false);
  }

BioSpb
Posts: 13
Joined: Thu 13 Jan, 2011 22:18
Has thanked: 2 times

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by BioSpb »

или просто половину от backparse, но не менее 500.

Code: Select all

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);
  }

User avatar
ctapmex
Posts: 1063
Joined: Fri 11 Apr, 2008 07:53
Been thanked: 10 times
Contact:

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post 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

kobri
Posts: 15
Joined: Fri 15 Nov, 2013 14:42
Been thanked: 1 time

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by kobri »

Я когда-то уже предлагал другой вариант решения проблемы медленной раскраски - можно в самом колорере проверять, с помощью GetNumberOfConsoleInputEvents, активен ли в данный момент пользователь, и просто не отдавать управление фару пока нет никаких событий консоли. Тогда и настроек никаких не понадобится и раскраска будет идти на максимально возможной скорости, пока пользователь ничего не делает.

BioSpb
Posts: 13
Joined: Thu 13 Jan, 2011 22:18
Has thanked: 2 times

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by BioSpb »

безусловно, вы знаете как работает фар и колорер больше меня. и наверняка можете предложить вариант на порядок лучше.
спасибо за пояснение.
я, прежде чем написать, опробовал некоторые изменения.
во-первых, попробовал убрать изменение idlecount, сделав его всегда равным 10. в итоге, раскраска changelog уменьшается совсем немного, но если делать активность в редакторе, то без этого - время полной раскраски становится больше минуты. изменение никакого дискомфорта не создает.
во-вторых, я попробовал уменьшить время таймера в 2 раза. скорость раскраски повысилась, но мне показалось это не правильным, и поиски того, как увеличить кол-во строк за один вызов привели меня в эти функции.
в-третьих, я попровал увеличить кол-во строк за раз до 3000.
и раскрашивание (changelog до конца) сократилось до 3 секунд, даже если что то делать в редакторе!

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

PS вот патчи для colorer.dll x64 от 25.01.19

Code: Select all

;уменьшение таймера примерно в 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
Last edited by BioSpb on Sat 26 Jan, 2019 23:27, edited 2 times in total.

BioSpb
Posts: 13
Joined: Thu 13 Jan, 2011 22:18
Has thanked: 2 times

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by BioSpb »

еще патч для colorer.dll x64 от 25.01.19 - увеличивает кол-во раскрашиваемых строк в 6,4 раза с сохранением плавного набора скорости.

Code: Select all

; 140-500 -> 896-3200
0000000000007603: 8D 89
0000000000007604: 0C C1
0000000000007605: 80 C1
0000000000007606: 03 E1
0000000000007607: C9 06
0000000000007619: 64 80
000000000000761A: 00 02

User avatar
ctapmex
Posts: 1063
Joined: Fri 11 Apr, 2008 07:53
Been thanked: 10 times
Contact:

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by ctapmex »

все эти цифры очень зависят от типа файла и процессора. похоже надо в параметры выносить.

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

User avatar
HaRT
Moderator
Posts: 9421
Joined: Tue 30 Aug, 2005 17:21
Location: Санкт-Петербург
Has thanked: 105 times
Been thanked: 219 times

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by HaRT »

ctapmex wrote:
Sun 27 Jan, 2019 08:45
эти цифры очень зависят от типа файла и процессора. похоже надо в параметры выносить
Раз зависят от типа файла, получается, что добавлять надо в параметры схемы.
И вновь прошу: пусть настройка будет выражена в максимально понятных не-программисту терминах. Я готов поучаствовать в их выработке.
Фар есть инструмент, а не нянька. © 2009 DrKnS

User avatar
Sim
Posts: 405
Joined: Fri 12 Jun, 2009 09:43
Has thanked: 3 times
Been thanked: 1 time
Contact:

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by Sim »

ctapmex, если в файле с длинными строками разбить эти длинные строки переносами на отдельные более короткие строки то раскраска происходит быстро, может действительно сделать разбивку на подстроки по 500 символов например, внося переносы после ; и } например, в зависимости от типа файла, конечно, маркерные символы для разбивки будут разные.
Случайности не случайны.

BioSpb
Posts: 13
Joined: Thu 13 Jan, 2011 22:18
Has thanked: 2 times

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by BioSpb »

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

User avatar
Sim
Posts: 405
Joined: Fri 12 Jun, 2009 09:43
Has thanked: 3 times
Been thanked: 1 time
Contact:

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by Sim »

BioSpb wrote:
Sun 27 Jan, 2019 12:05
и искать парные элементы по всей длине не нужно
без поиска парных элементов теряется смысл раскраски синтаксиса.
А как происходит поиск парных элементов если файл разбит на строки и парные элементы в разных строках находятся? почему это быстрее чем когда все в одну строку? если так работает алгоритм поиска и его не получится легко переделать, то надо делать разбивку на подстроки в памяти.
Случайности не случайны.

User avatar
zg
zero-gravity
Posts: 5817
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 147 times
Contact:

Colorer — гибкая раскраска синтаксиса в редакторе и др.

Post by zg »

ctapmex wrote:
Sun 27 Jan, 2019 08:45
ну и только дошло -проблема длинных строк в том, что поиск регулярного сообщения по такой длинной строке работает дольше, может захватить больше. чем если бы это было разбито на меньшие строки. что с этим делать не понятно. даже если отдельным потоком разбирать это очень долго.
если красить только видимую часть строки — работает быстрее.

Post Reply

Return to “Обсуждение плагинов”