Drugmix wrote:По-моему, все проблемы связанные с жадностью - исчезли бы, если была бы добавлена поддержка настройки U (ungreedy), которую можно было бы в шаблоне включать и отключать многократно, в нужных местах шаблона.
1. У каждого есть право на собственное мнение.
2. Не вижу особых преимуществ у "U" перед уже имеющимся "?". Тем самым не понимаю, почему бы это введение еще одного регулятора нежадности могло вдруг решить "все проблемы связанные с жадностью".
1. У Вас есть право хранить молчание!
2. Так можно было бы их комбинировать:
haystack: aaabbbcccaaabbbccc a.*c matches aaabbbcccaaabbbccc a.*?c matches aaabbbcccaaabbbc U)a.*c matches aaabbbc U)a.*?c matches abbbc
Это я просто в качестве примера привёл (даже вероятно, что довольно мало продуманного).
Ведь удобней же, когда правила можно более удобно (и более гибкие) создавать.
Drugmix wrote:По-моему, все проблемы связанные с жадностью - исчезли бы, если была бы добавлена поддержка настройки U (ungreedy), которую можно было бы в шаблоне включать и отключать многократно, в нужных местах шаблона.
1. У каждого есть право на собственное мнение.
2. Не вижу особых преимуществ у "U" перед уже имеющимся "?". Тем самым не понимаю, почему бы это введение еще одного регулятора нежадности могло вдруг решить "все проблемы связанные с жадностью".
1. У Вас есть право хранить молчание!
2. Так можно было бы их комбинировать:
haystack: aaabbbcccaaabbbccc a.*c matches aaabbbcccaaabbbccc a.*?c matches aaabbbcccaaabbbc U)a.*c matches aaabbbc U)a.*?c matches abbbc
Это я просто в качестве примера привёл (даже вероятно, что довольно мало продуманного).
Ведь удобней же, когда правила можно более удобно (и более гибкие) создавать.
1. Во-первых, не нужно хамить, ироничный Вы наш.
2. Во-вторых, вы меня опять не поняли.
3. В-третьих, не ясно на чем проверялись ваши примеры (они проверялись?). Думается, (2)и(4) не корректны.
opk44 wrote:1. Во-первых, не нужно хамить, ироничный Вы наш.
2. Во-вторых, вы меня опять не поняли.
3. В-третьих, не ясно на чем проверялись ваши примеры (они проверялись?). Думается, (2)и(4) не корректны.
Какое хамство? Я и не думал хамить. Просто не понятно к чему Вы написали, что каждый имеет право на своё мнение - это же и так всем понятно. И я тут делюсь своими соображениями тоже в виде высказывания лишь своего мнения. А на утверждение очевидного я всегда отвечаю аналогичным утверждением, это не хамство.
2. И Вы даже не расскажете в чём я Вас не понял?
3. Они не проверялись, но они не могут быть некорректными: сейчас товарищ Instructor переделывает парсинг шаблонов регулярных выражений в акелпаде. Переделать он его может так, как захочет, а я лишь предложил ещё один вариант как это сделать. Мой вариант может не нравиться или показаться непродуманным кому-либо, но он не может быть некорректным т.к. это лишь идея и пока она не реализована в коде - то и проверять-то нечего.
Или в предлагаемом мной варианте должна быть какая-то логическая ошибка, которая делает мой вариант невозможным для реализации. Если Вы заметили такую ошибку - то, пожалуйста, укажите на неё и поясните почему Вы считаете, что это не будет работать.
YuS wrote:Ну, не знаю... а в чем слабость? Неудобность - больше дело привычки, наверное.
Ну, я начал юзать регулярки на платформе .NET, под которую в основном и пишу - и вот там они довольно сильные: с поддержкой Юникода, именованных ссылок и т.п. (MSDN) - сильнее, чем JS... Но Акел сейчас и до нее не дотягивает. Слаб и неудобен в первую очередь из-за неполной поддержки модификаторов жадности и неоднозначности некоторых моментов (регулярки ж что формулы - тут точность важна), а во-вторых из-за нехватки терпимости к неоптимальным шаблонам. А привыкнуть к несколько отличному набору правил-то можно, конечно, лишь бы он был достаточно целостным, гармоничным и точным.
Instructor
будут ли ещё какие-то изменения в работе RegEx или уже можно рассчитывать на то, что текущая тестовая версия станет релизной?
Мне важно это знать, т.к. я бы тогда начал правила создавать для .coder-файла, их потребуется добавить много, а если работа RegEx из тестовой версии ещё под вопросом - то я пока не стал бы начинать этого делать.
то левая часть в кавычках - не окрашивается. Причём если скопировать этот текст, открыть новую вкладку и вставить его - то левая часть окрасится (до тех пор, пока пользователь не начнёт дальше что-то печатать):
В тексте есть теги [aaa]...[/aaa], нужно заменить их на [bbb]...[/bbb].
Найти: \[(/?)aaa\]
Заменить: [\1bbb]
Регулярные выражения включены
Если менять поштучно кнопкой Replace, то обрабатывает корректно (точнее как задумано), а если нажать Replace All, то во все теги проставляет слэши [/bbb]...[/bbb]. В EmEditor то же выражение обрабатывается корректно в обоих случаях. Если ошибка в выражении, прошу подсказать почему (хотя бы кратко).
Instructor
4.8.5 (простите сразу не сказал). Только что воспроизвёл на новом файле (правда частично). Текст:
[aaa]ccc[/aaa]
ccc [aaa]ccc[/aaa] [aaa]ccc[/aaa]
Если сразу нажать Replace All, то заменяет корректно. Если нажать Replace 2 раза и потом (при выделенном [aaa]) Replace All, то первое [aaa] заменится на [/bbb], а остальные корректно. Если нужно могу выслать фрагмент текста, где у меня во всех тегах слэши проставились.
все пробелы после "a" - тоже окрашиваются до тех пор, пока не поставить запятую, а судя по RegExp-у, насколько я понимаю, - не должно бы.
2. совсем забыл про комментарии:
/*
winget, это многострочный комментарий, но он раскрашивается как код, что есть ошибка и чего не происходит в текущей стабильной версии акелпада
*/
Внутристрочные начинаются с \s+; (т.е. любого положительного кол-ва "пробельных символов" и следующей за ними точкой с запятой), а заканчиваются символом новой строки или символом конца документа.
Многострочные комментарии начинаются с ^\s*/\* - т.е. с новой строки, затем может идти любое кол-во "пробельных символов" (можно и 0), а затем должно идти /*
а заканчиваются многострочные комментарии на ^\s*\*/ - т.е. с новой строки, затем может идти любое кол-во "пробельных символов" (можно и 0), а затем должно идти */