Total Commander

Хм. ясно. лучше правда по \n - но модифицировать движок RE для этого надо. А я его не видел вообще

Добавлено спустя 8 минут:

попробуйте написать М.Захарову - автору EControl.ru - можно ли сделать такую модификацию (в смысле может ли он)

Alextp писал(а):Ciber SLasH
Может не выставлено Editor - Optimal fill?

Вот спасибо, а я не вкурил сразу эту опцию.

Alextp писал(а):Хм. ясно. лучше правда по \n - но модифицировать движок RE для этого надо. А я его не видел вообще

Предлагаю, пока будет идти разбирательство с движком, сделать в самом Син прозрачные замены:
- при поиске: \n применять как \n\r?
- при заполнении Искать: заменять \n\r на \n

PS Приношу извинения за небольшую путаницу: правильный Win-вариант не \r\n, а \n\r.
Путаница у меня в голове возникла от того, что мне только в Син пришлось вспоминать про это.

kvichans писал(а):сделать в самом Син прозрачные замены

Пока не хочется- а) не учтен третий вар-т \r, б) все равно неидеально,
\n{2,3} будет понято как \n\r?{2,3} т.е. криво

Добавлено спустя 3 минуты:

-не \r\n, а \n\r.
разве?

Alextp писал(а):

kvichans писал(а):сделать в самом Син прозрачные замены

Пока не хочется- а) не учтен третий вар-т \r, б) все равно неидеально, \n{2,3} будет понято как \n\r?{2,3} т.е. криво

Согласен

Alextp писал(а):-не \r\n, а \n\r.
разве?

:) да

Alextp писал(а):попробуйте написать М.Захарову - автору EControl.ru - можно ли сделать такую модификацию (в смысле может ли он)

Мне этот путь кажется странным. Не потому что я не хочу/могу туда написать. А потому что у меня нет понимания контекста: ведь я не понимаю в каком виде сформулировать обращение к Захарову, как я буду просить для кого-то.

М.З. делает компонент (для Син) и программу. Просить - улучшения движка REGEX, которое позволит и в комп., и в программе делать поиск всех вариантов EOL простым \n. Надо сказать ему что так сделано там-то и тамто.

мою программу упоминать даже не надо

Alextp писал(а):М.З. делает компонент (для Син) и программу. Просить - улучшения движка REGEX, которое позволит и в комп., и в программе делать поиск всех вариантов EOL простым \n. Надо сказать ему что так сделано там-то и тамто.
мою программу упоминать даже не надо

Как-то это не естественно. Не я потребитель его движка. Я не знаю текущего API, не знаю что и как уже настраивается. Прежде, чем начать обращение, мне придется изучить ситуацию, составить представление - на это уйдет время, и не факт, что у меня составится правильная картина. Зачем это? Зачем вам нужен посредник, который выполнит роль испорченного телефона?
Я могу продолжить тестирование Поиска в других редакторах или устроить форум-опрос. Я могу делать только то, что понимаю сам.

На мои письма М.З. почти не отвечает :-\
ладно, напишу ему

Ответ М.З.:
>>Надо использовать "$" или "\Z" (последний включает конец строки в
результат).

Добавлено спустя 2 часа 47 минут:

beta. Многостр. текст подставляется в Find dlg. Правда он специально не ставился раньше- многостр. текст считался областью поиска а не текстом поиска

Alextp писал(а):Ответ М.З.:
>>Надо использовать "$" или "\Z" (последний включает конец строки в результат).

У меня не получается использовать подсказку М.З.
Пробую на файле из двух строк
abc
123
найти c$1. Not found

Обратите внимание на опрос. В нем я, в частности, предлагаю файл (14 байт) для тестирования. Цель: добится, чтобы по одному выражению (пусть даже это не \n как у большинства) в этом файл находились все концы строк.

Alextp писал(а):Многостр. текст подставляется в Find dlg. Правда он специально не ставился раньше- многостр. текст считался областью поиска а не текстом поиска

1. Остался (это я запутал) неправильный порядок символов: в диалоге появляется \r\n, а должно быть \n\r=char(13)+char(10). Но поиску это не мешает - видимо, две неточности компенсировали друг друга.

2. Совпадение строки поиска с диапазоном поиска - неучтенный неприятный эффект - получилась бессмыслица. Попробую повторить довод, приведший к такой ситуации: если выделенный текст можно искать командой СледующееСлово, то естественно ожидать, что перенос выделенного текста в Поиск должен давать такой же результат поиска. Значит из двух опций: reg-exp и in-selection - побеждает reg-exp, а in-selection не должен включатся.
Итого, вот моя рекомендация:
- если в диалоге не включены reg-exp или spec-chars (и в выделенном фрагменте есть конец строки), то нужно автоматом включить in-selection
- если же включены reg-exp или spec-chars, то в переносимом тексте делаются подмены, а in-selection остается выключенным

3. К слову, предлагаю чуть изменить условие включения in-selection.
Сейчас: в выделенном тексте есть конец строки.
Лучше так: после удаления крайних концов строк, в тексте еще есть конец строки.
Это позволит избежать включения in-selection, когда выделен хвост строки - очень частый случай поиска второго такого же хвоста.

kvichans писал(а):не получается использовать подсказку М.З.

Если искать
\w$\s+\w
-находятся все концы.

Добавлено спустя 3 минуты:

kvichans писал(а):а должно быть \n\r=char(13)+char(10)

Хелп в Найти>>
Вы можете использовать специальные символы:
\r - возврат каретки (#13)
\n - перевод строки (#10)

Alextp писал(а):

kvichans писал(а):не получается использовать подсказку М.З.

Если искать
\w$\s+\w
-находятся все концы.

Годится любая реализация. Если при поиске в
abc
123
вместо c\n1 нужно будет писать с\w$\s+\w1 - ну что ж, привыкнем. Но только если такую замену будет делать сам Син при вставке из буфера или переносе из таба. Черт с ней - с переносимостью поискового условия в другие программы.
У меня остается надежда, что здравый смысл победит и \n будет в Син работать как у большинства редакторов.

Alextp писал(а):

kvichans писал(а):а должно быть \n\r=char(13)+char(10)

Хелп в Найти>>
Вы можете использовать специальные символы:
\r - возврат каретки (#13)
\n - перевод строки (#10)

В Хелп написано \r=char(13), но никто кроме Син так не считает. Все используют \r для обозначения char(10). Мелкое недоразумение.

Добавлено спустя 5 минут:

http://ru.wikipedia.org/wiki/Управляющие_символы

Мы учились в разных системах.
В той, где я работал (с 1990) с С++, Java, VB, jscript, FoxPro, принято обозначение \n для char(13) и \r для char(10).
Другие обозначения в википедии - это поразительно и очень интересно. Если бы я сам на них наткнулся, решил бы - опечатка или шутка. Но судя по вашим словам, это уже массовое недоразумение. Печально.

Добавлено спустя 17 минут:

Похоже я сел в лужу - оказалось что это я много лет не правильно понимал обозначения. Забавно, что это не мешало работать - вот с чем еще нужно поразбираться.
Прошу прощения.

Вернемся к поиску. Можно ли еще надеяться, что \n будет как у большинства использоваться в расширенном виде?

Пока не знаю, отпишу Захарову, но он занят