| View previous topic :: View next topic |
| Author |
Message |
Andrey_A_A
Joined: 03 Jun 2010
Posts: 665
Location: Сочи, Хоста
|
 Posted: Thu Nov 08, 2012 2:52 pm Post subject: |
 |
|
заменить $1
оставляет только 111 и там и там
| Quote: | | .*\\(.*)\\.*\\.*(\\)+[^\\].* |
заменить $1
оставляет только 02 и там и там
а надо по разному  |
|
| Back to top |
|
 |
Xephon
Joined: 03 Jun 2008
Posts: 124
|
| Posted: Thu Nov 08, 2012 3:19 pm Post subject: |
|
|
Что ^.+\\(.+)\\.+\\.+\\?$
Чем $1
[v] Regular expressions
[v] Multiline |
|
| Back to top |
|
|
Andrey_A_A
Joined: 03 Jun 2010
Posts: 665
Location: Сочи, Хоста
|
| Posted: Thu Nov 08, 2012 3:31 pm Post subject: |
|
|
Xephon
Большое спасибо , у меня отработало отлично
.+\\(.+)\\.+\\.+\\?
$1
/p./s.отдыхать надо иногда)) |
|
| Back to top |
|
|
Infocatcher
Joined: 06 Aug 2007
Posts: 1767
|
| Posted: Thu Nov 08, 2012 4:01 pm Post subject: |
|
|
Andrey_A_A
В чем сакральный смысл получения одним выражением? 
| Code: | var paths = [
"C:\\02\\111\\папка\\",
"C:\\_02\\111\\папка\\файл.txt",
"C:\\02\\111\\",
"C:\\02\\",
"C:\\02"
];
for(var i = 0, l = paths.length; i < l; ++i) {
var p = paths[i];
paths[i] = p + " => " + getGrandparent(p);
}
WScript.Echo(paths.join("\n"));
function getGrandparent(path) {
if(/([^\\\/]+)([\\\/]+[^\\\/]+){2}[\\\/]*$/.test(path))
return RegExp.$1;
return undefined;
} |
[Upd]
Ай, не заметил еще одну страницу.
Видимо, я не понимаю смысла таких замен. |
|
| Back to top |
|
|
Andrey_A_A
Joined: 03 Jun 2010
Posts: 665
Location: Сочи, Хоста
|
| Posted: Thu Nov 08, 2012 4:12 pm Post subject: |
|
|
Infocatcher
| Quote: | | В чем сакральный смысл получения одним выражением? |
Спасибо всем за отклик... секрет
Пишу скрипт с большим функционалом (перемещение, переименование, копирование...) в параметрах вводятся рег. выраж. - тестирую. |
|
| Back to top |
|
|
DV
Joined: 16 Nov 2006
Posts: 1015
Location: Kyiv, Ukraine
|
| Posted: Thu Aug 25, 2016 8:09 pm Post subject: |
|
|
Замечено в AkelPad 4.9.8, хотя, возможно, было и раньше.
Поиск с регулярными выражениями вверх (назад) работает значительно медленнее, чем поиск вперёд (вниз). При этом даже необязательно, чтобы строка поиска содержала метасимвол!
Пример:
1) пусть у нас есть текстовый файл размером 50 МБ;
2) в конец этого файла добавляем строки:
| Code: | line 1
line 2
line 3
line 4 |
3) переходим к строке "line 1", ищем текст "line" вниз с установленной галочкой "Регулярные выражения". Продолжение поиска находит "line" в строках "line 2", "line 3" и "line 4" мгновенно.
4) на строке "line 4" ищем текст "line" вверх с установленной галочкой "Регулярные выражения". Каждое продолжение поиска происходит с ощутимой задержкой. |
|
| Back to top |
|
|
YuS
Joined: 15 Sep 2013
Posts: 434
|
| Posted: Fri Aug 26, 2016 5:38 pm Post subject: |
|
|
| DV wrote: | | Поиск с регулярными выражениями вверх (назад) работает значительно медленнее, чем поиск вперёд (вниз). |
А это потому, что фактически, поиск происходит не назад, а с начала и вперед... только совпадение ищется ближайшее перед курсором, далее ближайшее перед найденным и т.д. |
|
| Back to top |
|
|
DV
Joined: 16 Nov 2006
Posts: 1015
Location: Kyiv, Ukraine
|
| Posted: Sat Aug 27, 2016 8:39 pm Post subject: |
|
|
| YuS wrote: | | DV wrote: | | Поиск с регулярными выражениями вверх (назад) работает значительно медленнее, чем поиск вперёд (вниз). |
А это потому, что фактически, поиск происходит не назад, а с начала и вперед... только совпадение ищется ближайшее перед курсором, далее ближайшее перед найденным и т.д. |
Такой подход имеет смысл только когда регулярное выражение может совпасть с многострочным текстом, причём количество строк заранее неизвестно. На мой взгляд, такая ситуация возникает лишь при выполнении следующих двух условий одновременно:
1. Регулярное выражение содержит + или *
2. Настройка ". захватывает новую строку" включена.
В моём случае не то что оба, а ни одно из этих условий не выполняется. И поиск вхолостую пробегает по всему файлу.
P.S.
Отмечу, что в случаях, когда метасимволы \n или \r присутствуют явно, само наличие этих метасимволов позволяет подсчитать количество строк искомого текста. То есть в таких ситуациях, когда + или * не используются и ". захватывает новую строку" не включена, при поиске назад следует также выполнять обычный проход снизу вверх, а не с начала документа. |
|
| Back to top |
|
|
DV
Joined: 16 Nov 2006
Posts: 1015
Location: Kyiv, Ukraine
|
| Posted: Sun Aug 28, 2016 5:18 pm Post subject: |
|
|
В общем, полагаю, нам нужно что-то вроде такого:
| Code: | if (IsVariableMultiLineRegEx(regEx))
{
// ищем от начала файла - как сейчас
}
else
{
// ищем назад (снизу вверх)
} |
|
|
| Back to top |
|
|
Instructor
Site Admin
Joined: 06 Jul 2006
Posts: 6250
|
| Posted: Mon Aug 29, 2016 5:12 am Post subject: |
|
|
DV
Поиск с регулярными выражениями вверх не реализован, поэтому поиск вверх работает так как описал YuS. |
|
| Back to top |
|
|
DV
Joined: 16 Nov 2006
Posts: 1015
Location: Kyiv, Ukraine
|
| Posted: Mon Aug 29, 2016 8:58 am Post subject: |
|
|
| Instructor wrote: | DV
Поиск с регулярными выражениями вверх не реализован, поэтому поиск вверх работает так как описал YuS. |
Но ведь поиск вверх - это тот же самый цикл, только не от начала к концу, а от конца в начало. Утрируя, что-то вроде:
| Code: | for (nLine = bSearchUp ? nLinesCount - 1 : 0; bSearchUp ? nLine >= 0 : nLine < nLinesCount; bSearchUp ? --nLine : ++nLine)
{ ... } |
А тело цикла теоретически будет одинаковым что для поиска вниз, что вверх. Хотя практически, скорее всего, в теле цикла потребуются некоторые уточнения в зависимости от значения bSearchUp.
В случае явно присутствующих в регулярном выражении символов \n и \r при поиске назад будет не
| Code: | | nLine = bSearchUp ? nLinesCount - 1 : 0 |
а
| Code: | | nLine = bSearchUp ? nLinesCount - nNewLineCharCount - 1 : 0 |
Доказательством того, что это не просто теоретические выкладки, является цикл из функции doFindTextExW в QSearchFindEx.c (реализация поиска со спец. символами):
| Code: | | while ( bSearchUp ? (nLine >= nLinesToCheck - 1) : (nLine <= nEditMaxLine) ) |
Хотя, признаюсь, обобщение алгоритма для поиска вверх и вниз далось мне нелегко. |
|
| Back to top |
|
|
Instructor
Site Admin
Joined: 06 Jul 2006
Posts: 6250
|
| Posted: Mon Aug 29, 2016 10:04 am Post subject: |
|
|
DV
Сложность не в определении области цикла, а в самом механизме сравнения. Поиск назад с регулярными выражениями - это почти полностью свой код, отличный от поиска вперёд. См. RegExpFunc.h. |
|
| Back to top |
|
|
DV
Joined: 16 Nov 2006
Posts: 1015
Location: Kyiv, Ukraine
|
| Posted: Mon Aug 29, 2016 2:39 pm Post subject: |
|
|
| Instructor wrote: | DV
Сложность не в определении области цикла, а в самом механизме сравнения. |
Разве функция AE_FindText в AkelEdit.c не содержит тот самый цикл, о котором я говорю? Если модифицировать ciCount и ciCountEnd внутри while-цикла так, чтобы вначале диапазон поиска был в районе последней строки, затем предпоследней строки и т.д., разве мы не получим нужное поведение?
Поясняю на примере: пусть в документе 10 строк, а регулярное выражение мы идентифицировали как совпадающее с 2 строками текста (например, потому, что оно содержит 1 метасимвол \n и не содержит спец.символов + или *). Тогда при поиске снизу вверх первый вызов AE_PatExec проверяет строки 9-10 (при этом реализация поиска внутри самого AE_PatExec работает сверху вниз), второй вызов AE_PatExec проверяет строки 8-9, третий вызов AE_PatExec проверяет строки 7-8 и т.д. |
|
| Back to top |
|
|
YuS
Joined: 15 Sep 2013
Posts: 434
|
| Posted: Mon Aug 29, 2016 4:42 pm Post subject: |
|
|
DV
Вы не поняли...
Шаблоны регулярных выражений сравниваются не целиком с подстрокой, а посимвольно, причем с возвратами и поисками лучшего совпадения. Но, в любом случае, сравнение не работает в обратном направлении шаблона именно (от последнего символа шаблона к первому), т.е. сравнение всегда идет с первым символом шаблона, затем получает точку невозврата, далее идет уже сравнение со вторым и т.д. - с учётом этого, как осуществить такое сравнение в обратном направлении текста? Т.е. где парсер будет ставить точки невозврата? Текст ведь будет сравниваться с шаблоном в направлении обратном поиску, а там точка невозврата уже стоит... тупик.
Или, чтобы было нагляднее, допустим есть шаблон:
текст:
при поиске в обратном направлении, первым будет найдено совпадение во втором слоге "па", при дальнейшем сравнении шаблона, общего совпадения не будет найдено, т.к. в шаблоне есть "-\1" и тогда перед этим вторым слогом необходимо проставить точку невозврата, ок ставим её и начинаем просмотр сначала... находим первый слог "па", далее пытаемся сравнивать оставшуюся часть шаблона и натыкаемся на точку невозврата, опять неудача. Итог - совпадения не будет найдено вовсе, хотя необходимая подстрока там и присутствует. |
|
| Back to top |
|
|
DV
Joined: 16 Nov 2006
Posts: 1015
Location: Kyiv, Ukraine
|
| Posted: Mon Aug 29, 2016 5:30 pm Post subject: |
|
|
| YuS wrote: | DV
Вы не поняли... |
Поясняю свою мысль картинкой:
Search.png |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
