Да, похоже, поторопился... Но и с вновь скачанной беда:
Code: Select all
^[^d]\S+(?!.*\=)
Ага! К проблеме приводит ещё
Code: Select all
^[^\d]+(?!.*\=)
Code: Select all
^[^d]\S+(?!.*\=)
Code: Select all
^[^\d]+(?!.*\=)
Исправлено:Drugmix wrote: эээ, Смещение происходит только если в вышеобозначенной конструкции использовать \1, я же использовал \2 и \3 для окраски, как раз чтобы разделить их.
Значит где-то допущена ошибка.Drugmix wrote:блин, а на последней версии перестали подкрашиваться строки, начинающиеся с MButton:: :-/
вот жеж я неудачный пример придумал видимо ))Drugmix wrote:DrakonHaSh
а по какому признаку отделять регулярку в строке от строки без регулярки?
По Вашей регулярке похоже, что она скорей для каких-то присваиваний, типа var == 9.
DrakonHaSh wrote: привычное ^.*==.*$ и ^.*?==.*?$ не работает
Code: Select all
^[^\n]*?==[^\n]*?$
В массив возможных вариантов добавьте все возможные варианты.Drugmix wrote: там, где подсвечивается MButton:: значит не подсвечиваются либо строки с ` без запятой после неё, либо с аргументом из двух слов, либо с комментарием в конце строки, либо с Else,Try.
Согласен, но однако, написать регулярку для раскраски незнакомого синтаксиса без тестового массива ещё невозможнее.Drugmix wrote: но вообще, написать тесты совсем на все случаи жизни - невозможно
В данном случае, проблема даже не в этом, тут проблема в слишком вольном синтаксисе - судя по тестовому массиву, мало того, что разделителем аргументов может быть и пробел, и запятая, так ещё и разделителем частей аргументов могут быть те же самые символы, а это уже перебор.Drugmix wrote: , т.к. там где в аргументе используется `, или `n - подразумевается, что их может быть сколь угодно много и в любом сочетании с прочим текстом в этом аргументе.
Code: Select all
0 "^\s*(?:(Else)(?:\s*,\s*|\s+)|(Try)(?:\s*,\s*|\s+)|([^:]{1,38}(?=::))::)*\s*(#IfWinActive\b)\s*?,?\s*?([^;,`\s]+(?!`.)|[^`,\s;]+`.)*\s*?,?\s*?([^;,`\s]+(?!`.)|[^`,\s;]+`.)*\s*?,?\s*?(\s+;.*)?$" `\1=(4,${OP},0) \2=(4,${IF},0) \3=(2,${STR},0) \4=(2,${TYPE},0) \5=(2,${ATTR},#ff0000) \6=(2,${ATTR},#00ff00) \7=(3,${COMM},0)`
Так это может в корне поменять подход к написанию регулярки. Если я правильно понял, то пробел не может являться разделителем самих аргументов? Если так, то в массиве с валидными строками это правило нарушено...Drugmix wrote:По правилам синтаксиса ahk:
1. Только первый аргумент можно писать через пробел от команды, пропустив запятую.
Этот момент учтен, там вообще любой экранированный символ считается частью аргумента.Drugmix wrote: 2. Каждая экранированная запятая - не считается разделителем.
Этот момент зависит от ответа на вопрос о валидных разделителях аргументов, т.е. можно попытаться исправить ситуацию, но при условии более строгого синтаксиса в отношении разделителей.Drugmix wrote: Ваше правило всем хорошо, кроме того, что
а. ломается на пробеле в 1 из аргументов (а если это исправить, то поломаются строки с комментарием в конце.
Это я оговорил - на первый взгляд эту проблему трудновато обойти, но попытаться можно...Drugmix wrote: б. ломается на двух идущих подряд экранированных символах
Если символ экранирования "`" присутствует в конце аргумента, то значит последующий символ экранируется и является частью аргумента, т.е. при наличии комментария в строке, последующий комментарий не выдерживает условия наличия пробела перед ";", так что всё правильно, а в случае отсутствия комментария - ничего не ломается. Или таки символ экранирования может принимать другие значения, кроме, собственно, экранирования? Если да, то такую неоднозначность трудно обработать, если вообще возможно...Drugmix wrote: в. при наличии ` без в конце аргумента.
Ну, не совсем так. Движок по регуляркам, пока достаточно точно соответствует PCRE, за исключением некоторых особенностей, но это скорее необходимость, чем прихоть. Единственный момент - очень не хватает поиска по условию, с ним было бы гораздо проще в написании регулярок...Drugmix wrote: Что ж, вот он и предел, до тех пор, пока Instructor не изменит парсер RegEx на более соответствующие PCRE.