Total Commander

Пожелание:
Можно ли как-то упростить изменение цвета подсветки синтакиса?
Допустим, я хочу изменить цвет comment/string/integer, для всех языков на зеленый.

1. Баг с отображением имени файла в титуле Син - вместо имени отображается (Untitled)
Стабильного повторения нет, но проявляется часто.
Баг проявляется при некоторых сочетаниях следующих действий
- Изменение текста в табе
- Переключение на другое приложение
- Переключение на Син - в этот момент появляется ошибка в титуле

790 писал(а):включается авто-подчёркивание

Опции- Правописание- [ ] галка

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

keiran_green
Пока не планируется, сорри,надо настроить каждый лекс.

Добавлено спустя 22 минуты:
Kvichans
Чтото не повторить.. пришлите UVF (Syn.ini ваш есть)

1. Буду запоминать, как повторить
2. Пожелание. В диалогах Найти/Заменить есть внутренняя статус-строка, в которой сейчас появляется только "String was not found...".
Желательно в нее же помещать информацию при успешных поисках: "найдено NN фрагментов", "заменено NN раз" и пр. Можно просто дублировать статус-строку Син.
Это повысит комфорт, а то сейчас нужно отвлекаться, чтобы найти глазами и прочитать нижнюю статус-строку.

2. ОК, разумно.

beta
+ Find/Replace dialog: Ctrl+V in edit field escapes special chars in multi-line text
(when "Regex" or "Special chars" option on)
+ keys "Tree - select next/previous tree node"

Alextp писал(а):+ Find/Replace dialog: Ctrl+V in edit field escapes special chars in multi-line text
(when "Regex" or "Special chars" option on)

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

Кроме того теперь обострилась проблема с концами строк при поиске.
Есть такой рудимент, как три варианта оформления концов строк в текстовых файлах: \n \r\n \r (которые применялись когда-то в стародавние времена в Unix, в Win и в Mac). В настоящее время и редакторы, и прочее ПО (за редким исключением) позволяют пользователям не обращать внимания этот рудимент. Син в этом месте не последователен.
- Син позволяет работать со всеми вариантами одновременно и однообразно почти всегда.
- Но как только дело доходит до поиска, пользователю приходится ломать голову: как заполнять reg-exp (или spec-chars), так как Син при поиск требует точного написания варианта.
- Во-первых, нужно до начала поиска выяснять какой из вариантов применим к текущему файлу.
- Во-вторых, условие поиска нужно приспосабливать к следующему файлу.
- В-третьих, новая функция Син буквально работает с текстом из буфера, а значит и после нее нужно проверять соответствие и поправлять.
Предлагаю упростить пользователю жизнь, как это сделано во многих программах (всех, из тех с которыми мне приходилось работать).
Нужно сделать так, чтобы \n воспринимался как любой из допустимых вариантов.

Alextp писал(а):+ keys "Tree - select next/previous tree node"

То, что нужно.
Было бы значительно удобнее, если бы новое позиционирование каретки следовало тем же принципам, что и при поиске:
- если новая позиция уже есть на экране, то экран не меняется, происходит только перемещение каретки
- если же нужно показать ту строку, которая еще не видна, то эта строка ставится (по возможности) в центр
Конечно, это же относится и выполнению Ввод на Дереве.

kvichans писал(а):пожелание на еще одну похожую функцию: перемещать из таба в диалоги Найти/Заменить фрагмент текста

это не поможет с поиском фрагмента в др. табе. Вы же для этого (для поиска в др, табе) хотите перенос в Поиск? Копирование-вставка в поиск не решает это?

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

-Предлагаю упростить пользователю жизнь, как это сделано во многих программах (всех, из тех с которыми мне приходилось работать

как же там сделано? \n означает 13 и 10? а \r что означает? Предлагаете модифицировать REGEX движок?

Alextp писал(а):

kvichans писал(а):пожелание на еще одну похожую функцию: перемещать из таба в диалоги Найти/Заменить фрагмент текста

это не поможет с поиском фрагмента в др. табе. Вы же для этого (для поиска в др, табе) хотите перенос в Поиск? Копирование-вставка в поиск не решает это?

Да - копирование выделенного фрагмента перед вызовом Найти и вставка его же поверх перенесенного в поле Искать - решает задачу, но это громозко и портит буфер.
Пожелание "при переносе в Искать делать замены" вызвано прежде всего следующей нелогичностью текущей ситуации:
- Выделив в табе фрагмент, захватывающий конец строки, пользователь может найти следующий такой же командой СледующееСлово
- Но вызвав диалог Найти - не может, хотя подходящий для этого вариант заполнения Искать Сину легко построить.

Про "это не поможет с поиском фрагмента в др. табе" не понял. Почему не поможет?

Alextp писал(а):

kvichans писал(а):Предлагаю упростить пользователю жизнь, как это сделано во многих программах (всех, из тех с которыми мне приходилось работать

как же там сделано? \n означает 13 и 10? а \r что означает? Предлагаете модифицировать REGEX движок?

Не представляю как это сделано, но могу предложить рабочий вариант, который не требует переделки в REGEX движке.
Перед применением рег.выражения заменять в нем \n на что-то, что подходит под все варианты.
Очевидно, что \r?\n покрывает только два варианта.
Возможно \r?\n|\r выражает все три варианта, но могу ошибаться, так как мои знания reg-exp поверхностны. Надеюсь, что все варианты можно покрыть, но даже если получится только два (через \r?\n) - это значительно облегчит жизнь (у меня одна половина файлов с \n, другая с \r\n).

Если дать глобальную настройку (не в Найти, а в Настройки): "\n для всех вариантов" - то новая функциональность не будет мешать тем, кто привык к прежней.
Если предложение будет принято, то при вставке из буфера в Искать нужно будет заменять \r\n и \r на \n

1. ОК, перенос в Найти будет.
2. REGEX: может лучше сделать новый символ \N - который будет расширяться в
(\r\n | \r | \n)

не надо делать опцию- можно всегда расширять

Исправьте баг пожалуйста: в "Tab mode" выставлено "Tab character", но при автоотступе вставляются пробелы:

PS: SynWrite 3.4.1030

Ciber SLasH
Может не выставлено Editor - Optimal fill?

Alextp писал(а):REGEX: может лучше сделать новый символ \N - который будет расширяться в (\r\n | \r | \n)
не надо делать опцию- можно всегда расширять

1. Замена \n на (\r\n|\r|\n) на мой взгляд некорректна, так как меняет распознавание подгрупп.
2. А как без опции Син будет делать замены при вставке из буфера в Искать? Как он поймет, что применять: \r\n или \N?
3. С новым символом исчезнет переносимость поисковых выражений. В других программах его не поймут

1. да, правда- как тогда быть? Еще раз - с новым символом \N
2. я бы всегда при вставке заменял концы на \N

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

3. да.. тоже проблема

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

Проверьте, как в др. программах- там \n значит все 3 конца, или что?

Alextp писал(а):Проверьте, как в др. программах- там \n значит все 3 конца, или что?

Вот что мне пока удалось проверить на редакторах, в поиске которых есть reg-exp:
TextPad: по \n находит все варианты
Sublime Text 2: по \n находит все варианты
Eclipse: по \n находит только \r (это удивительно, мб я что-то не донастроил, так как у меня крайне малый опыт работы с Eclipse)
WinMerge: по \n находит все варианты
Если этого не достаточно, то может быть устроить форум-опрос?