SynWrite (Syn2)
Модераторы: Avada, CaptainFlint, Nik, d-view, Моторокер
- Ciber SLasH
- Сообщения: 209
- Зарегистрирован: Сб авг 20, 2005 21:41
- Откуда: С.-Петербург
Предлагаю, пока будет идти разбирательство с движком, сделать в самом Син прозрачные замены:Alextp писал(а):Хм. ясно. лучше правда по \n - но модифицировать движок RE для этого надо. А я его не видел вообще
- при поиске: \n применять как \n\r?
- при заполнении Искать: заменять \n\r на \n
PS Приношу извинения за небольшую путаницу: правильный Win-вариант не \r\n, а \n\r.
Путаница у меня в голове возникла от того, что мне только в Син пришлось вспоминать про это.
Win7x64(1600x900), TC8.50x32, SynWrite 6.19, CudaText 1.3.14, UV 6.5.0.0
СогласенAlextp писал(а):Пока не хочется- а) не учтен третий вар-т \r, б) все равно неидеально, \n{2,3} будет понято как \n\r?{2,3} т.е. кривоkvichans писал(а):сделать в самом Син прозрачные замены
:) даAlextp писал(а):-не \r\n, а \n\r.
разве?
Мне этот путь кажется странным. Не потому что я не хочу/могу туда написать. А потому что у меня нет понимания контекста: ведь я не понимаю в каком виде сформулировать обращение к Захарову, как я буду просить для кого-то.Alextp писал(а):попробуйте написать М.Захарову - автору EControl.ru - можно ли сделать такую модификацию (в смысле может ли он)
Win7x64(1600x900), TC8.50x32, SynWrite 6.19, CudaText 1.3.14, UV 6.5.0.0
Как-то это не естественно. Не я потребитель его движка. Я не знаю текущего API, не знаю что и как уже настраивается. Прежде, чем начать обращение, мне придется изучить ситуацию, составить представление - на это уйдет время, и не факт, что у меня составится правильная картина. Зачем это? Зачем вам нужен посредник, который выполнит роль испорченного телефона?Alextp писал(а):М.З. делает компонент (для Син) и программу. Просить - улучшения движка REGEX, которое позволит и в комп., и в программе делать поиск всех вариантов EOL простым \n. Надо сказать ему что так сделано там-то и тамто.
мою программу упоминать даже не надо
Я могу продолжить тестирование Поиска в других редакторах или устроить форум-опрос. Я могу делать только то, что понимаю сам.
Win7x64(1600x900), TC8.50x32, SynWrite 6.19, CudaText 1.3.14, UV 6.5.0.0
На мои письма М.З. почти не отвечает :-\
ладно, напишу ему
ладно, напишу ему
Последний раз редактировалось Alextp Вт май 01, 2012 13:23, всего редактировалось 1 раз.
У меня не получается использовать подсказку М.З.Alextp писал(а):Ответ М.З.:
>>Надо использовать "$" или "\Z" (последний включает конец строки в результат).
Пробую на файле из двух строк
abc
123
найти c$1. Not found
Обратите внимание на опрос. В нем я, в частности, предлагаю файл (14 байт) для тестирования. Цель: добится, чтобы по одному выражению (пусть даже это не \n как у большинства) в этом файл находились все концы строк.
1. Остался (это я запутал) неправильный порядок символов: в диалоге появляется \r\n, а должно быть \n\r=char(13)+char(10). Но поиску это не мешает - видимо, две неточности компенсировали друг друга.Alextp писал(а):Многостр. текст подставляется в Find dlg. Правда он специально не ставился раньше- многостр. текст считался областью поиска а не текстом поиска
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, когда выделен хвост строки - очень частый случай поиска второго такого же хвоста.
Win7x64(1600x900), TC8.50x32, SynWrite 6.19, CudaText 1.3.14, UV 6.5.0.0
Годится любая реализация. Если при поиске вAlextp писал(а):Если искатьkvichans писал(а):не получается использовать подсказку М.З.
\w$\s+\w
-находятся все концы.
abc
123
вместо c\n1 нужно будет писать с\w$\s+\w1 - ну что ж, привыкнем. Но только если такую замену будет делать сам Син при вставке из буфера или переносе из таба. Черт с ней - с переносимостью поискового условия в другие программы.
У меня остается надежда, что здравый смысл победит и \n будет в Син работать как у большинства редакторов.
В Хелп написано \r=char(13), но никто кроме Син так не считает. Все используют \r для обозначения char(10). Мелкое недоразумение.Alextp писал(а):Хелп в Найти>>kvichans писал(а):а должно быть \n\r=char(13)+char(10)
Вы можете использовать специальные символы:
\r - возврат каретки (#13)
\n - перевод строки (#10)
Win7x64(1600x900), TC8.50x32, SynWrite 6.19, CudaText 1.3.14, UV 6.5.0.0
Мы учились в разных системах.
В той, где я работал (с 1990) с С++, Java, VB, jscript, FoxPro, принято обозначение \n для char(13) и \r для char(10).
Другие обозначения в википедии - это поразительно и очень интересно. Если бы я сам на них наткнулся, решил бы - опечатка или шутка. Но судя по вашим словам, это уже массовое недоразумение. Печально.
Добавлено спустя 17 минут:
Похоже я сел в лужу - оказалось что это я много лет не правильно понимал обозначения. Забавно, что это не мешало работать - вот с чем еще нужно поразбираться.
Прошу прощения.
Вернемся к поиску. Можно ли еще надеяться, что \n будет как у большинства использоваться в расширенном виде?
В той, где я работал (с 1990) с С++, Java, VB, jscript, FoxPro, принято обозначение \n для char(13) и \r для char(10).
Другие обозначения в википедии - это поразительно и очень интересно. Если бы я сам на них наткнулся, решил бы - опечатка или шутка. Но судя по вашим словам, это уже массовое недоразумение. Печально.
Добавлено спустя 17 минут:
Похоже я сел в лужу - оказалось что это я много лет не правильно понимал обозначения. Забавно, что это не мешало работать - вот с чем еще нужно поразбираться.
Прошу прощения.
Вернемся к поиску. Можно ли еще надеяться, что \n будет как у большинства использоваться в расширенном виде?
Win7x64(1600x900), TC8.50x32, SynWrite 6.19, CudaText 1.3.14, UV 6.5.0.0