ahk.coder: add per-argument highlighting
Drugoy opened this issue · comments
Я пытаюсь сделать из акелпада нечто максимально приближённое к "IDE" (умной среде разработки) с помощью возможностей coder-плагина.
Однажды меня посетила идея, что:
а. надо как-то визуально отображать ошибки в коде, которые связанны с некорректным синтаксисом.
б. надо визуально дифференцировать не только типы комманд, но и типы их аргументов, чтобы пользователь по стилю подсветки каждого аргумента понимал какой тип аргумента ожидается (этот аргумент требует указать переменную для чтения? просит ввести имя новой переменной куда что-то сохранится? ожидает текст? ожидает выражение? ожидает wintitle? и т.п.)
в. надо визуально дифференцировать обязательность аргументов (является ли аргумент обязательным или его можно пропустить?)
И всего этого можно добиться даже с текущими возможностями .coder-плагина.
Для этого надо сделать 2 вещи:
- убрать text color у всех слов из секции Words (но оставить их ради того, чтоб работало автозавершение слов).
- приделать довольно сложные правила раскраски для QuotesRE секции. И приделать потребуется много: прям на каждую команду и функцию.
И вот теперь вся штука в том, что благодаря помощи на форуме - я научился создавать QuotesRE-правила с индивидуальной подсветкой каждого атрибута.
После этого я взял список всех команд ahk и разделил их на группы по количеству и типу (обязательный vs необязательный) атрибутов.
А потом составил почти для каждого из них (пока только для команд, кроме пары сложных случаев) по правилу для QuotesRE секции.
Оно работает. Работает вроде хорошо, но, к сожалению, не очень быстро:
вместе с правилом для подсветки текста в кавычках - у меня на данный момент получилось 235 правил и переключение между вкладками, а также быстрая прокрутка - заметно притормаживают прорисовку.
Во-первых, прошу Вас проверить сильно ли будет притормаживать оно у Вас.
Во-вторых, я пока не закончил с этими правилами и тут мне снова нужна Ваша помощь: сейчас правила используют подсветку в основном не по цвету текста, а по цвету фона. Я тут быстро попробовал везде убрать цветной фон на 0 - и вроде после этого прорисовка значительно ускорилась.
Соответственно, нужно сначала выработать некую конвенцию о том как и что подсвечивать, чтобы добиться всех вышеобозначенных целей.
Ну, и в третьих, главный вопрос: что делать если правила всё равно будут заметно притормаживать прорисовку?
а. Отказаться от них совсем.
б. Распространять закомментированными.
в. Распространять их нормально, и реагировать лишь в случае если будут жалобы пользователей.
г. Частично или полностью пожертвовать дифференциацией типов аргументов (при этом дифференциация обязательности аргументов остаётся), сгруппировав команды так, что на 1 группу будет приходиться 1 правило. При полном исключении дифференциации типов аргументов, текущие 234 команды вроде как можно сгруппировать до 35 правил.
Параллельно с этим можно попинговать тов. Instructor'а на предмет возможных оптимизаций с целью ускорения прорисовки.
Собственно, вот правила, которые я написал.
Про прорисовку там про параметр paintoptions в Akelpad.ini идёт обсуждение.
Чтобы проверить притормаживание, дайте мне, пожалуйста, какой-нибудь тестовый файл ahk с разными употреблениями функций.
Чуть погонял. При моих текущих настройках, да, есть подтормаживание.
Не понравился красный фон. Заменил на ${CodeFold_PanelNormalNodeOpenBkColor}, для зелёного и синего надо будет ещё найти. По-иоему лучше из стандартных Codefold_ или LineBoard_ секций для задних фонов (…BkColor).
https://gist.github.com/Lenchik/8194252 - там файл, на котором тестил, модифицированный QuotesRE и мой Coder.ini, чтобы смотреть как это выглядит в разных темах подсветки.
Про цвета - это понятно, это я для тестов их такими сделал (т.к. при 3 ярких фонах сразу видно правильно ли окрасились аргументы или нет), естественно их надо адаптировать и скорей всего отказаться от подсветки фона в пользу подсветки текста.
У себя, я с paintoptions=1 не заметил особой разницы в скорости прорисовки.
А файлы для тестов можно взять в моём репозитории, например вот этот
А нельзя сократить число правил, группируя имеющиеся 235 ещё и как-то так: ^(.*::)?\s*(#ErrorStdOut|#InstallKeybdHook|#InstallMouseHook)(\s+;.*$)?$ \1=(2,${STR},0) \2=(2,${OP},0) \3=(3,${COMM},0)?
Я это и имел в виду, когда говорил про группировку 234 правил до 35:
https://gist.github.com/Drugoy/8208180
почти не лагает (лагает только на длинных строках).
Тогда после исправления красного, синего и зелёного фонов, стоит это всё добавить в кодер-файл, как мне кажется.
Тесты показали, что даже с 35-ью правилами появляются адские лаги на длинных строках вроде
msgbox % "Process.Caption: '" Process.Caption "'`nProcess.CommandLine: '" Process.CommandLine "'`nProcess.CreationClassName: '" Process.CreationClassName "'`nProcess.CreationDate: '" Process.CreationDate "'`nProcess.CSCreationClassName: '" Process.CSCreationClassName "'`nProcess.CSName: '" Process.CSName "'`nProcess.Description: '" Process.Description "'`nProcess.ExecutablePath: '" Process.ExecutablePath "'`nProcess.ExecutionState: '" Process.ExecutionState "'`nProcess.Handle: '" Process.Handle "'`nProcess.HandleCount: '" Process.HandleCount "'`nProcess.InstallDate: '" Process.InstallDate "'`nProcess.KernelModeTime: '" Process.KernelModeTime "'`nProcess.MaximumWorkingSetSize: '" Process.MaximumWorkingSetSize "'`nProcess.MinimumWorkingSetSize: '" Process.MinimumWorkingSetSize "'`nProcess.Name: '" Process.Name "'`nProcess.OSCreationClassName: '" Process.OSCreationClassName "'`nProcess.OSName: '" Process.OSName "'`nProcess.OtherOperationCount: '" Process.OtherOperationCount "'`nProcess.OtherTransferCount: '" Process.OtherTransferCount "'`nProcess.PageFaults: '" Process.PageFaults "'`nProcess.PageFileUsage: '" Process.PageFileUsage "'`nProcess.ParentProcessId: '" Process.ParentProcessId "'`nProcess.PeakPageFileUsage: '" Process.PeakPageFileUsage "'`nProcess.PeakVirtualSize: '" Process.PeakVirtualSize "'`nProcess.PeakWorkingSetSize: '" Process.PeakWorkingSetSize "'`nProcess.Priority: '" Process.Priority "'`nProcess.PrivatePageCount: '" Process.PrivatePageCount "'`nProcess.ProcessId: '" Process.ProcessId "'`nProcess.QuotaNonPagedPoolUsage: '" Process.QuotaNonPagedPoolUsage "'`nProcess.QuotaPagedPoolUsage: '" Process.QuotaPagedPoolUsage "'`nProcess.QuotaPeakNonPagedPoolUsage: '" Process.QuotaPeakNonPagedPoolUsage "'`nProcess.QuotaPeakPagedPoolUsage: '" Process.QuotaPeakPagedPoolUsage "'`nProcess.ReadOperationCount: '" Process.ReadOperationCount "'`nProcess.ReadTransferCount: '" Process.ReadTransferCount "'`nProcess.SessionId: '" Process.SessionId "'`nProcess.Status: '" Process.Status "'`nProcess.TerminationDate: '" Process.TerminationDate "'`nProcess.ThreadCount: '" Process.ThreadCount "'`nProcess.UserModeTime: '" Process.UserModeTime "'`nProcess.VirtualSize: '" Process.VirtualSize "'`nProcess.WindowsVersion: '" Process.WindowsVersion "'`nProcess.WorkingSetSize: '" Process.WorkingSetSize "'`nProcess.WriteOperationCount: '" Process.WriteOperation "'`nCountProcess.WriteTransferCount: '" CountProcess.WriteTransferCount "'`nTime: '" A_Now "'"
Откатите этот коммит, пожалуйста.
В связи с появлением новой тестовой версии АкелПада, в которой ничего не тормозит даже с 235 правилами - предлагаю доделать и выпустить их.
235 правил поддерживать разве проще?
а чё их поддерживать? ahk обновляется довольно редко. тут весь гемор будет лишь в первоначальной настройке подсвечивания аргументов. Пока это остаётся тоже проблемой.
Если выигрыша ни в чём другом нет, то по-моему проще возиться с 35 строками, чем с 235. Какие бы скрипты замены не помогали потом править.
В тестовой версии AkelPad я не заметил разницы между 35 и 235: тормозов совсем нет. Поэтому, пока не вижу смысла "экономить" на количестве правил (кроме соображения, что составить меньшее кол-во проще).
А выигрыш от большего кол-ва правил надо пока оценить: если по стилю текста будет виден тип аргумента - это немного упрощает кодинг.
Но пока надо доделать и получше пощупать варианты, оценить преимущества.
Есть, например, же всякие мелкие нюансы вроде такого:
GuiControl, Sub-command, ControlID [, Param3]
у этой команды вроде как 2 обязательных и 1 опциональный аргумент, но в документации прописан один из вариантов употребления этой команды, когда первый аргумент опущен, но обязательно должен присутствовать третий.
Соответственно, это ещё +1 правило или к 35 или к 235.
Хорошо бы в комментариях отразить нюансы работы каждого правила, чтобы желающие могли утянуть в свои подсветки — если всё удастся это же будет находка, позволяющая подсказывать код как в полноценных узкозаточенных IDE.
Ну, обсуждение всего этого было на форуме.
А вообще, для более полноценного универсального IDE из coder'а ему не хватает конечно
а). поддержки фраз в автозавершении (сейчас поддерживается только 1 слово, мы используем лишь хак с непробельным символом, визуально выглядящим как пробел (хотя, он даже при его выделении двойным кликом ведёт себя иначе)).
б). поддержки вариантов значений для аргументов. Например:
WinGet, OutputVar [, Cmd, WinTitle, WinText, ExcludeTitle, ExcludeText]
у WinGet значений аргумента Cmd может быть ровно 15 (ID, IDLast, PID, ProcessName, ProcessPath, Count, List, MinMax, ControlList, ControlListHwnd, Transparent, TransColor, Style, ExStyle или пустота) и ничего кроме этих 15 вариантов там быть не может.
Я и первое и второе уже просил Instructor'а приделать, но он никак не отреагировал. Видимо, как и многие другие разработчики - он вряд ли будет приделывать то, что лично ему не очень хочется, пока об этом не попросит какая-то критическая масса пользователей.
На данный момент, активных форумчан не так много, а потому и для достижения критической массы, возможно, потребуется не так много желающих этого нововведения пользователей.
Пока что, за такое нововведение - высказался только я один (предложив его), от остальных (включая Instructor'а) не последовало никакой реакции (ни позитивной, ни негативной).
В связи с этим, я призываю Вас и присоединившегося к нам @Skif-off высказаться на форуме по этому поводу.
Эти высказывания, думаю, точно так же попадают на полочку "для заметок" и всё.
Потому, по-моему, перспективней использовать по-максимуму то, что уже есть. Чтобы и другие этим проникались и переносили к себе, а там, глядишь, и реализация в более продвинутом виде подоспеет.
Я не знаю, пользуется ли кто-то нашими подсветками. кроме нас самих, но если пользуются, то лучше уж пусть и пользователей будутподсветки с постепенно расширяющимся функционалом уже сейчас, нежели мегаклёвые, но непонятно когда.
Тоже верные рассуждения.
И нет, я не против кому-то рассказать, если спросят как устроены составленные мной правила, просто, на мой взгляд, инициатива должна бы исходить от жаждущих помощи.
Во-первых, всё обсуждение, пока я составлял свои правила - шло публично на форуме. Сами правила - не спрятаны. Да и про синтаксисы других языков я мало знаю и не уверен переносимы ли эти правила так просто и на них.
Но всё это не отменяет и моего призыва высказаться перед Instructor'ом, что мы все хотим одного и того же нововведения - глядишь, прислушается и приделает.
А правила вносить пока всё равно рано: тестовая версия AkelPad не перешла в основную ветку, а без неё адски тормозят и 36 правил.
Я завершил создание правил, проверил всё довольно тщательно несколько раз, сделал некоторые правила более узко кастомизированными (перечислив допустимые аргументы там, где кроме них ничего не может быть), учёл всевозможные варианты употребления каждой из команд… в общем всё готово к приземлению, но встал вопрос:
т.к. подсветка QuotesRE правил перебивает остальные подсветки, то получается, что вся секция "Words" в принципе нужна только как словарь, чтобы у юзера работало автозавершение слов.
Поэтому, в своём рабочем файле ahk.coder я полностью обнулил у них цвета и ничего при этом не потерял.
Также, я обнулил цвета и у всего в секции Delimiters, потому что там ~20 правил, а они собой занимают аж 2 цвета, это при том, что разделителям достаточно и 1 дефолтного цвета (т.е. цвет 0: то ли это всегда белый, то ли это определяется темой) и потому, что я не понимаю как вообще работает Delimiters и для чего оно нужно.
[#] У вас есть возражения против обнуления цветов у слов из секции Words? Они больше нигде не применяются, а сколько-то места да занимают.
Из секции Words цвет можно оставить только у правила
3 0 ${NUM} 0 "0123456789"
т.к. белые цифры пока не очень смотрятся (они белые только в выражениях, а над выражениями ещё предстоит поработать: хотя бы все математические операции разукрасить, а как это будет сделано - то, может и это правило не понадобится)
но оно спокойно заменяется правилом для QuotesRE:
0 `(\d)` `\1=(0,${NUM},0)`
[#] Может вы знаете для чего нужна секция Delimiters? Я заметил, что код с белыми (цветом=0) скобками и запятыми - смотрится лучше, а обнуление цвета в этой секции высвободит 1-2 цвета (которых хотелось бы иметь больше, но пока этого нет, приходится выкручиваться тем, что есть).
Возражений нет. Надо воплотить, а потом будет возможность перепавить - гитхаб сохранит же.
Только 0 - это не белый цвет, а "Обычный текст" :) Долго доходило о чем речь, т.к. не пользуюсь темными темами.
В Delimiters отдельно указываются разделители слов для подсветки (кроме QuotesRE, в ней используются разделители из настроек самого AkelPad (Параметры/Редактор 2)).
Проще всего понять на примере:
"парам-пам-пам" - это одно слово, но если в Delimiters добавить "-", то получим уже три слова
"парам"-"пам"-"пам".
- разделители можно попутно подсветить.
По поводу цвета - я так и подозревал, но поленился на светлой теме проверить.
Разделители, значит, пускай пока будут, но без цветов (по-хорошему, надо сначала насоздавать ещё QuotesRE правил разукрасив максимум возможных вариантов именно ими.
Сам себе баг репорт: наткнулся на код с валидными Expressions'ами содержащими неэкранированные запятые - они ломают подсветку.
Return SubStr(Hex, StrLen(Hex) - Len + 1)
Кое-где это можно довольно просто исправить, но есть же и команды у которых выражения допускаются для какого-нибудь аргумента в середине, надо выяснить допустимы ли и там неэкранированные запятые.
Наткнулся на такое замечание:
Note: Commas that appear within the last parameter of a command do not need to be escaped because the program knows to treat them literally. The same is true for all parameters of MsgBox because it has smart comma handling.
Над будет хотя бы это подправить.
http://plasmon.rghost.ru/52516612/image.png
Так и было задумано?
Я сейчас патч отправил с самыми последними локальными наработками.
Практически всё, что я мог - я сделал.
Осталось несколько проблем, нужна помощь. Скоро опишу их в отдельных issue, этот баг закрываю (но спокойно переоткрывайте его в случае, если считаете нужным).