Это в диалоге поиска. Если пользоваться быстрым - такой опции нет.kvichans писал(а):[х]Wrap search
Пожелания для SynWrite
Модераторы: Avada, CaptainFlint, Nik, d-view, Моторокер
- keiran_green
- Сообщения: 130
- Зарегистрирован: Пт ноя 18, 2011 03:20
- Откуда: Хабаровск
Это кардинально важный пункт - пока остается надежда лучше не буду его трогатьAlextp писал(а):-Разрешить в Клавишах несколько последовательных сочетаний
Это полу-красным :)
Еще в Результатах нет. Идея: добавлять сочетание не в элемент меню, а в текст в виде "New tab (Ctrl+T)"Alextp писал(а):-В контекстных меню тоже показывать сочетания
это серым(в конт.меню табов не сделано т.к. привело к глюку)
Win7x64(1600x900), TC8.50x32, SynWrite 6.19, CudaText 1.3.14, UV 6.5.0.0
Дать опцию для объединения Историй поиска в разных контекстах: в табе без диалога, в табе с диалогом, по файлам, в Дереве, в Результатах. Сейчас уже объединены истории Поиска/Замены и ПоискаПоФайлам. Сейчас у поиска без диалога нет истории. Цели:
- после начала поиска в одном контексте, иметь возможность продолжить поиск такого же фрагмента (или чуть измененного) в другом контексте
- иметь историю поиска без диалога
- после начала поиска в одном контексте, иметь возможность продолжить поиск такого же фрагмента (или чуть измененного) в другом контексте
- иметь историю поиска без диалога
Win7x64(1600x900), TC8.50x32, SynWrite 6.19, CudaText 1.3.14, UV 6.5.0.0
Неправильно распознается метод ResorceManager класса MyClass (Лексер C#, Экранная форма Неверная идентификация метода.bmp)
Может быть, пусть локальные переменные метода определенные в одной строке включаются таким же образом (вместе) и в дерево (Лексер C#, Нету локальных переменных.bmp).
Сейчас в лексере C# в Tree для классов включается всё что находится в строке где объявляется имя класса (экранная форма Всё включено.bmp).
Нельзя ли останавливаться, например, на символе { и знаке начала комментария.
Отдельные части лексера, например только шаблоны, не экспортируються.
Лексер экспортируэться только целиком.
Не открываетя session (сессия) из пункта меню File:Sessions:RecentSessions
Экранные формы высылаю по адресу указанному в About.
Извините, написал не совсем в ту тему. Продублирую в теме SynWrite (Syn 2)
Может быть, пусть локальные переменные метода определенные в одной строке
Код: Выделить всё
String Title, AuthorСейчас в лексере C# в Tree для классов включается всё что находится в строке где объявляется имя класса (экранная форма Всё включено.bmp).
Нельзя ли останавливаться, например, на символе { и знаке начала комментария.
Отдельные части лексера, например только шаблоны, не экспортируються.
Лексер экспортируэться только целиком.
Не открываетя session (сессия) из пункта меню File:Sessions:RecentSessions
Экранные формы высылаю по адресу указанному в About.
Извините, написал не совсем в ту тему. Продублирую в теме SynWrite (Syn 2)
Последний раз редактировалось orod Пн май 28, 2012 15:49, всего редактировалось 1 раз.
1. Хранить историю изменений для NTFS-файлов после их закрытия.
Известно, что в NTFS кроме основного тела файла можно иметь доп.потоки, в которых хранить произвольные данные. Тотал хранит там пользовательские свойства файла.
Предлагаю хранить там данные для выполнения команды UNDO. Для пользователя это может выглядеть так:
- В настройках Син появляется галка [x]"Очищать историю изменений при закрытии файла"
- Если эта галка не включена, то Син при открытии файла загружает эти данные
- В результате пользователь может (в принципе) ходить по истории от самого первого сохранения файла до текущего состояния.
Замечания
- Это альтернатива для создания *.bak и подобных заплаток
- Лучше бы галку отнести не к Син, а к свойствам файла. Есть отдельные файлы, про которые нужна длинная история.
- Основная цель: избавиться от восклицания: "Ой, я файл сохранил и закрыл! Теперь руками придется восстанавливать прошлое состояние"
Пояснение. Идея не моя, а Артемия Лебедева (aka Тема).
Известно, что в NTFS кроме основного тела файла можно иметь доп.потоки, в которых хранить произвольные данные. Тотал хранит там пользовательские свойства файла.
Предлагаю хранить там данные для выполнения команды UNDO. Для пользователя это может выглядеть так:
- В настройках Син появляется галка [x]"Очищать историю изменений при закрытии файла"
- Если эта галка не включена, то Син при открытии файла загружает эти данные
- В результате пользователь может (в принципе) ходить по истории от самого первого сохранения файла до текущего состояния.
Замечания
- Это альтернатива для создания *.bak и подобных заплаток
- Лучше бы галку отнести не к Син, а к свойствам файла. Есть отдельные файлы, про которые нужна длинная история.
- Основная цель: избавиться от восклицания: "Ой, я файл сохранил и закрыл! Теперь руками придется восстанавливать прошлое состояние"
Пояснение. Идея не моя, а Артемия Лебедева (aka Тема).
Win7x64(1600x900), TC8.50x32, SynWrite 6.19, CudaText 1.3.14, UV 6.5.0.0
Добавьте
http://forum.wincmd.ru/viewpost.php?p=92902
Добавлено спустя 3 минуты:
NTFS Streams: может позже сделаю...не уверен. не знаю как реализовать.
http://forum.wincmd.ru/viewpost.php?p=92902
Добавлено спустя 3 минуты:
NTFS Streams: может позже сделаю...не уверен. не знаю как реализовать.
- keiran_green
- Сообщения: 130
- Зарегистрирован: Пт ноя 18, 2011 03:20
- Откуда: Хабаровск
1. Пожелание про маркеры. Когда-то давно (в начале апреля) я сравнивал эту систему: Drop(Alt+Home), Collect(Alt+End) и пр - со стеком и обратил внимание, что в этой системе не хватает общепринятой команды: получить голову, не удаляя ее из коллекции. Сейчас начал пользоваться шаблонами и заценил удобство заранее расставленных маркеров. Но сейчас есть единственный способ перейти к маркеру - это уничтожить его. Можно ли добавить команду "перейти и сохранить"?
2. Пожелание. У команды поиска парного символа непоследовательное поведение: то она работает, если каретка за символом, то не работает. Предлагаю сделать такую логику:
- при выделении более одного символа - ничего не искать
- если есть выделение ровно одного символа, то искать пару к нему
- если нет выделения и рядом с кареткой только один символ, для которого существует пара, то искать эту пару (под этот случай как раз попадают ситуации "каретка за скобкой")
- если нет выделения и оба символа рядом с кареткой "парные", то искать пару для того, который после каретки (как сейчас)
2. Пожелание. У команды поиска парного символа непоследовательное поведение: то она работает, если каретка за символом, то не работает. Предлагаю сделать такую логику:
- при выделении более одного символа - ничего не искать
- если есть выделение ровно одного символа, то искать пару к нему
- если нет выделения и рядом с кареткой только один символ, для которого существует пара, то искать эту пару (под этот случай как раз попадают ситуации "каретка за скобкой")
- если нет выделения и оба символа рядом с кареткой "парные", то искать пару для того, который после каретки (как сейчас)
Win7x64(1600x900), TC8.50x32, SynWrite 6.19, CudaText 1.3.14, UV 6.5.0.0
1 При заменах с [x]in selection: не терять выделение. Основания:
- Это выделение информационно - "тут" были изменения
- Оно может быть использовано для следующей замены
Сейчас для следующей замены приходится восстанавливать его руками.
- Это выделение информационно - "тут" были изменения
- Оно может быть использовано для следующей замены
Сейчас для следующей замены приходится восстанавливать его руками.
Win7x64(1600x900), TC8.50x32, SynWrite 6.19, CudaText 1.3.14, UV 6.5.0.0
1. Уточнения про Историю поисков. Нужно не забыть про поиск из буфера и диалог БыстрыйПоиск.
Попробую описать ситуацию. В Син сейчас есть следующие контексты поиска:
- СЛВ: слово/выделение в табе
- ПоПоПо: повторить последний поиск в табе
- ДиБыст: диалог БыстрыйПоиск в табе
- ДиПоЗа: диалог Поиск/Замена в табе
- ДиПоФа: диалог ПоФайлам
- ДиДер: диалог в Дереве
- ПоДер: повторить последний поиск в Дереве
- ДиРез: диалог в Результатах
- ПоРез: повторить последний поиск в Результатах
- БУФ: из буфера
Вот что требуется от общей Истории
- Накапливать последние поисковые строки от: СЛВ, ДиПоЗа, ДиБыст, ДиПоФа, ДиДер, ДиРез, БУФ
- Предоставлять список Историю для: ДиПоЗа, ДиПоФа, ДиДер, ДиРез
- Предоставлять голову Истории для: ПоПоПо, ДиБыст, ПоДер, ПоРез
При создании общей Истории возникает проблема с учетом спец.разметки в поисковых строках.
Начну с общих наблюдений
- В Быстром, Дереве и Результатах нет RegExp. Сейчас нет. Потом могут появиться.
- Поиски СЛВ и БУФ не нуждаются в спец.разметке - они всегда ищут буквальное совпадение.
- Буквальный поиск и RE-поиск по "поправленной" (доп. \) строке дают одинаковые результаты
У меня есть два варианта решения проблемы: кардинальный и терпимый(=консервативный).
Сначала кардинальный. Предлагаю в Истории хранить обе строки: и исходную и поправленную. В каждый контекст передавать подходящий вариант. Например, при [х]RE после поиска из буфера в ДиБыст, ДиДер, ДиРез появится исходная строка, а в ДиПоЗа, ДиПоФа - поправленная. Если когда-нибудь какой-то диалог получит возможность обрабатывать RE, в него станет передаваться поправленная.
Из всех контекстов поиска сохранить сразу две подходящие строки не получится только в тех случаях, когда исходная строка только с разметкой - это в ДиПоЗа и ДиПоФа. Не вижу другого выхода: сохранять строку поиска и как исходную и как поправленную. Конечно контексты без RE не смогут повторить такой поиск. Это меньшая из потерь (надеюсь временная).
Теперь терпимый. Хранить только поправленные строки. Это создаст больше неудобств в ДиБыст, в Дереве, в Результатах. Повтор последнего поиска в табе (ПоПоПо) можно продолжать улучшать, чтобы он на *** корректно реагировал.
Попробую описать ситуацию. В Син сейчас есть следующие контексты поиска:
- СЛВ: слово/выделение в табе
- ПоПоПо: повторить последний поиск в табе
- ДиБыст: диалог БыстрыйПоиск в табе
- ДиПоЗа: диалог Поиск/Замена в табе
- ДиПоФа: диалог ПоФайлам
- ДиДер: диалог в Дереве
- ПоДер: повторить последний поиск в Дереве
- ДиРез: диалог в Результатах
- ПоРез: повторить последний поиск в Результатах
- БУФ: из буфера
Вот что требуется от общей Истории
- Накапливать последние поисковые строки от: СЛВ, ДиПоЗа, ДиБыст, ДиПоФа, ДиДер, ДиРез, БУФ
- Предоставлять список Историю для: ДиПоЗа, ДиПоФа, ДиДер, ДиРез
- Предоставлять голову Истории для: ПоПоПо, ДиБыст, ПоДер, ПоРез
При создании общей Истории возникает проблема с учетом спец.разметки в поисковых строках.
Начну с общих наблюдений
- В Быстром, Дереве и Результатах нет RegExp. Сейчас нет. Потом могут появиться.
- Поиски СЛВ и БУФ не нуждаются в спец.разметке - они всегда ищут буквальное совпадение.
- Буквальный поиск и RE-поиск по "поправленной" (доп. \) строке дают одинаковые результаты
У меня есть два варианта решения проблемы: кардинальный и терпимый(=консервативный).
Сначала кардинальный. Предлагаю в Истории хранить обе строки: и исходную и поправленную. В каждый контекст передавать подходящий вариант. Например, при [х]RE после поиска из буфера в ДиБыст, ДиДер, ДиРез появится исходная строка, а в ДиПоЗа, ДиПоФа - поправленная. Если когда-нибудь какой-то диалог получит возможность обрабатывать RE, в него станет передаваться поправленная.
Из всех контекстов поиска сохранить сразу две подходящие строки не получится только в тех случаях, когда исходная строка только с разметкой - это в ДиПоЗа и ДиПоФа. Не вижу другого выхода: сохранять строку поиска и как исходную и как поправленную. Конечно контексты без RE не смогут повторить такой поиск. Это меньшая из потерь (надеюсь временная).
Теперь терпимый. Хранить только поправленные строки. Это создаст больше неудобств в ДиБыст, в Дереве, в Результатах. Повтор последнего поиска в табе (ПоПоПо) можно продолжать улучшать, чтобы он на *** корректно реагировал.
Win7x64(1600x900), TC8.50x32, SynWrite 6.19, CudaText 1.3.14, UV 6.5.0.0