Регулярные выражения

[Drugmix]

Instructor
а Вы бы не могли, пожалуйста, прикрутить работу вот таких выражений:

Code: Select all

([^;,]|(?<=`),)*

так же, как они срабатывают на regex101.com?
regex101.com:

а в akelpad'е не срабатывает вот эта часть

Code: Select all

|(?<=`),

из вышеприведённого правила и получается вот так:

[YuS]

прикрутить работу вот таких выражений:

Code: Select all

([^;,]|(?<=`),)*

А что в AP с ними не так?

а в akelpad'е не срабатывает вот эта часть

Code: Select all

|(?<=`),

Не совсем понятно, почему она должна сработать?
"|" - метасимвол со значением "или", т.е. найдено может быть что-то одно, так что всё логично.
Тут надо уточнить регулярку, для того, чтобы находилось именно то, что требуется...

ЗЫ А вот реализация поиска по условию очень бы пригодилась в AP не lookahead и lookbehind, а именно поиск по условию:
(?(...)...) - условие [если, то]
(?(...)...|...) - условие [если, то, а иначе]

Добавлено:
ЗЗЫ А, понял о чем речь... выше ведь этот вопрос задавался. В AP захваченный символ повторно уже не просматривается, т.е. не срабатывает именно Positive Lookbehind. По идее, да, лучше, чтобы была такая возможность просмотра, но тут ведь поиск может вестись в режиме немедленной замены, поэтому совпадения с исходным текстом уже может не быть ... наверное, оптимальным выходом была бы опция, если это вообще возможно.

[Drugmix]

YuS
всё дело в том, что хочется научить акелпад правильно окрашивать аргументы у команд, с учётом того, что аргументы могут содержать экранированные символы разделителей команд.
Вот взять AutoHotkey: там аргументы у команд разделяются запятой

Code: Select all

Команда, аргумент1, аргумент2, аргумент3, …, аргументN

но если запятая "экранирована", то она перестаёт быть разделителем и становится частью аргумента:

Code: Select all

Команда, аргумент1, аргумент2_часть1`,аргумент2_часть2, аргумент 3

И получается, что сейчас нельзя составить правило для QuotesRE так, чтобы подсветка на этом примере не поломалась и раскрасила бы строку как команду с тремя аргументами, а не четырьмя

[Serge Yolkin]

Drugmix
Не знаю AutoHotkey, но, если синтаксис [запятая][\s*][слово][запятая] всегда соответствует аргументу, то в чём проблема?

Здесь выделял js регулярку с учетом возможного экранирования \/

[Drugmix]

Serge Yolkin
в том, что аргументы бывают разных типов и вся задумка в том, чтобы подсветить их по типу. Для каждого аргумента каждой команды.
И да, [запятая] в конце - опциональна, а [слово] может содержать экранированную запятую.

[Serge Yolkin]

Drugmix
А что-нибудь типа (?<=\,).*[^`](?=(\,|$)) работать не будет?

[Drugmix]

Serge Yolkin
во-первых, запятые - не экранируемые символы.
во-вторых, мне надо, чтобы всё это захватилось, а значит должно быть в (), но

В AP захваченный символ повторно уже не просматривается, т.е. не срабатывает именно Positive Lookbehind

в-третьих, я всё же проверил в своём правиле и оно стало приводить к краху АкелПада

Code: Select all

0	"^\s*(((Try)|(Else))(?:\s*,\s*|\s+)|(.{1,38}(?=::))(?:::))?\s*(#IfWinActive\b)(?:\s*,\s*?)?((?<=,).*[^`](?=(,|$)))*?)?(\s+;.*$)?((?<=,).*[^`](?=(,|$)))?(\s+;.*)?$" `\3=(4,${OP},0) \4=(4,${IF},0) \5=(2,${STR},0) \6=(2,${OP},0) \8=(2,${ATTR},0) \9=(3,${COMM},0) \11=(2,${ATTR},0) \12=(3,${COMM},0)`

[Serge Yolkin]

Drugmix
1. Где как... с экраном везде работает.
2-3. Я идею предложил, а не реализацию. А идея заключалась в том, чтобы команду захватывать отдельно, а в следующем правиле разбирать аргументы. Вот под это второе правило я болванку и предложил, без подсветок (скобок). Do You speak RegExp?

[Drugmix]

Serge Yolkin
няня, я у них поел.
Вы предлагаете использовать 2 правила вместо одного? Вы же сами выступали против моего предложения добавить каскадную работу правилам! Без этого одно правило будет просто перебивать другое.
Can you into logics?

[Serge Yolkin]

Без этого одно правило будет просто перебивать другое.

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

[YuS]

И да, [запятая] в конце - опциональна, а [слово] может содержать экранированную запятую.

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

[YuS]

готов офигеть от положительного ответа

Если я правильно понял, тут вся трудность в том, как объяснить регулярке (в реализации AP), что такое разделитель "," и экранированный разделитель "`,", причем с учетом того, что захваченный символ никаким lookahead и lookbehind уже никак не просмотреть.

[Serge Yolkin]

YuS
Экранирование я в своём примере объяснил...

[Serge Yolkin]

Instructor, DV, удалось грохнуть и тестовую:

Code: Select all

\S+\s))

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

[YuS]

во-вторых, мне надо, чтобы всё это захватилось, а значит должно быть в (), но

В AP захваченный символ повторно уже не просматривается, т.е. не срабатывает именно Positive Lookbehind

Можно попытаться как-то так соорудить шаблон:

Code: Select all

([^;,`]*(?!`,)|[^,;]*?`,[^,;`]*?)*