Re[9]: Нормальный редактор для C++ - существует ли?
От:
Аноним
Дата:
27.03.12 10:10
Оценка:
Здравствуйте, SleepyDrago, Вы писали:
SD>Это уже интересно А расскажите-ка пожалуйста простым пользователям VS чего у них нет. Так сказать на личных примерах.
Visual Assist — глючная поделка, не умеет корректно парсить плюсовый код. Элементарных вещей уже несколько лет не могут доработать.
Не умеет делать overload resolution для элементарных случаев:
Почему оно мне предлагает выбор, если тут однозначно определяется какая именно из перегруженных функций вызывается? Компилятор об этом меня не спрашивает же.
Не умеет поиск references для конструкторов:
Пытался найти references для Foo(int), а оно вывалило что попало и пропустило конструктор foo(1) в списке инициализации. Т.е. такой фичи вообще нет в VA.
Не умеет искать references для перегруженных операторов:
Попытка поискать references для Vec::operator-=, нет такой фичи.
Не умеет переходить к определению перегруженного оператора:
Опять какой-то левый выбор вариантов предлагает, хотя все однозначно в коде.
Даже completion, для которого у VA похоже куча эвристик (вместо нормального семантического анализа кода), работает криво:
Откуда у boost::sub_match взялась функция find?
Re[12]: Нормальный редактор для C++ - существует ли?
Здравствуйте, PSV100, Вы писали:
PSV>По поводу переходов/поиска определений элементов. Можно забабахать макросы в таком стиле: клацнули клавишу, определяем имя элемента (согласно выделенному тексту или положению курсора, можно также и запросить через ввод), выполнили поиск в проекте стандартными средствами редактора (они вполне мощные), если результат не один, то выводим в спец-окна/панель/буфер, где можно всё наглядно оценить, часто даже и переходить на нужное место и не понадобится.
"Вполне мощные" стандартные средства редактора ничего не знают про семантику кода, поэтому будут искать тупо текст и выдавать кучу левых, не относящихся к конкретному элементу результатов. Т.е. find-grep — это слишком примитивно и не удобно для навигации по коду.
PSV>Уверен, что для вима/эмакса таких готовых скриптов можно найти не мало, возможно и для Sublime уже наваяли. Также не мало всяких помогалок в стиле переключений из хедера на реализацию и наоборот, фактически это уже "стандартный" набор.
Костылей уже немало наваяли для этих редакторов, а адекватную модель кода для корректной навигации по нему ничего из этих костылей не умеет.
PSV>И так далее в таком стиле. При этом нет дикого расхода оперативки (можно запускать рядом IDE, она всё сожрёт), нет затыков, всё летает.
Так никаких удобств при работе с исходным кодом нет, его то за обычный текст считают, то пытаются парсить кривыми парсерами на regexp, которые о семантике понятия не имеют. Вот оно и "летает".
Re[7]: Нормальный редактор для C++ - существует ли?
Здравствуйте, Аноним, Вы писали:
А>Навигация по исходникам, которые используют boost (всякие там spirit/phoenix/multi_index), ни в одной IDE нормально не работает.
Netbeans пробовали? У меня работает. Хотя spirit и т.п. напрямую не использовал. )
Re[13]: Нормальный редактор для C++ - существует ли?
Здравствуйте, kamre, Вы писали:
K>Здравствуйте, Kswapd, Вы писали:
K>>Но вот отсутствие в Eclipse возможности задать простой клавиатурный макрос — очень удивило.
K>Частично есть в виде плагина: http://sourceforge.net/projects/practicalmacro/files/ Но до удобства клавиатурных макросов в Emacs этому плагину далеко.
Как я понимаю, основной посыл был в том, что такие базовые необходимые функциональные вещи отсутствуют изначально, из коробки. И сама идеология системы заставляет создавать полноценные проекты как монстро-плагины для IDE на каждый чих. К сожалению, таковы "современные эмаксы".
Re[8]: Нормальный редактор для C++ - существует ли?
Здравствуйте, kamre, Вы писали:
K>Здравствуйте, PSV100, Вы писали:
PSV>>По поводу переходов/поиска определений элементов. Можно забабахать макросы в таком стиле: клацнули клавишу, определяем имя элемента (согласно выделенному тексту или положению курсора, можно также и запросить через ввод), выполнили поиск в проекте стандартными средствами редактора (они вполне мощные), если результат не один, то выводим в спец-окна/панель/буфер, где можно всё наглядно оценить, часто даже и переходить на нужное место и не понадобится.
K>"Вполне мощные" стандартные средства редактора ничего не знают про семантику кода, поэтому будут искать тупо текст и выдавать кучу левых, не относящихся к конкретному элементу результатов. Т.е. find-grep — это слишком примитивно и не удобно для навигации по коду.
PSV>>Уверен, что для вима/эмакса таких готовых скриптов можно найти не мало, возможно и для Sublime уже наваяли. Также не мало всяких помогалок в стиле переключений из хедера на реализацию и наоборот, фактически это уже "стандартный" набор.
K>Костылей уже немало наваяли для этих редакторов, а адекватную модель кода для корректной навигации по нему ничего из этих костылей не умеет.
PSV>>И так далее в таком стиле. При этом нет дикого расхода оперативки (можно запускать рядом IDE, она всё сожрёт), нет затыков, всё летает.
K>Так никаких удобств при работе с исходным кодом нет, его то за обычный текст считают, то пытаются парсить кривыми парсерами на regexp, которые о семантике понятия не имеют. Вот оно и "летает".
Я сам мечтаю иметь хороший редактор и удобную среду, при этом иметь прелести адекватного IDE-помощника. А некоторым интузиастам и для C++ нафиг не нужен и автокомплит, например.
В моём случае, редактор часто используется для своего DSL, который специально спроектирован для простой работы. В начале был прицел, чтобы реализовать полноценный парсер для работы в редакторе, в т.ч. и со всякой семантикой (в JEdit есть полноценная система для своих парсеров, чем-то похоже на механизмы в Эклипсе). Но потом обломались, настроили стандартные универсальные средства, которые могут хотя бы подсказать о виде литерала (это комментарий, или строка, или это внутри "другого языка" и пр.), ваяем свои макросы — вроде ничего, удобно. И действительно летает.
Re[8]: Нормальный редактор для C++ - существует ли?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, PSV100, Вы писали:
PSV>>Я всё-таки рекомендую получше присмотреться к Sublime.
_>Кстати, смотрю сейчас на новую версию Notepad++ — там появилась "карта документа". Вроде бы это была одна из заметных уникальных фич Sublime... )))
Да всяких minimap-ов наваяли для многих редакторов/IDE. Возможно в Sublime это появилось первым, я не в курсе. По мне, так это просто, прежде всего, привлекалово юзеров, но иногда действительно приятная и как-то подмогнёт.
Кстати, здесь рядом рекомендовали HippoEdit — неплохая штука, давно на него смотрел, тогда он был в какой-то бете и был неюзабельный, но внимание привлёк. Сейчас руки всё никак не доходят посмотреть.
Re[9]: Нормальный редактор для C++ - существует ли?
Здравствуйте, PSV100, Вы писали:
PSV>Я сам мечтаю иметь хороший редактор и удобную среду, при этом иметь прелести адекватного IDE-помощника.
Мне тоже хватало бы Emacs как редактора плюсового кода, если бы там нормально навигация по исходникам работала. И ведь принципиально ничего не мешает эту функциональность добавить вместо той кучи костылей, которая сейчас предлагается. Просто сообщество — неосиляторы какие-то, самое лучшее для плюсов было в проприетарном xrefactory, который к сожалению загнулся. Может быть когда-нибудь прикрутят c++ front-end от clang.
PSV> А некоторым интузиастам и для C++ нафиг не нужен и автокомплит, например.
Лично мне корректный семантический автокомплит не шибко критичен, меня в большинстве случаев устроит и тупой словарный из Emacs. А вот проверка корректности кода по мере набора и до компиляции для меня важна, также как и удобная навигация по всему коду в проекте. Только вот эти вещи посложнее кучи костылей с эвристиками для автокомплита.
PSV>В моём случае, редактор часто используется для своего DSL, который специально спроектирован для простой работы. В начале был прицел, чтобы реализовать полноценный парсер для работы в редакторе, в т.ч. и со всякой семантикой (в JEdit есть полноценная система для своих парсеров, чем-то похоже на механизмы в Эклипсе).
Если так много кода нужно писать и поддерживать на своем DSL, то можно попробовать на фреймворке Xtext написать.
Re[10]: Нормальный редактор для C++ - существует ли?
Здравствуйте, kamre, Вы писали:
K>Здравствуйте, PSV100, Вы писали:
PSV>>Я сам мечтаю иметь хороший редактор и удобную среду, при этом иметь прелести адекватного IDE-помощника.
K>Мне тоже хватало бы Emacs как редактора плюсового кода, если бы там нормально навигация по исходникам работала. И ведь принципиально ничего не мешает эту функциональность добавить вместо той кучи костылей, которая сейчас предлагается. Просто сообщество — неосиляторы какие-то, самое лучшее для плюсов было в проприетарном xrefactory, который к сожалению загнулся. Может быть когда-нибудь прикрутят c++ front-end от clang.
Всё-таки неосиляторы для плюсов не от хорошей жизни. Я вспоминаю дебаты вокруг JEdit, когда оценивали шансы отодрать парсер от Нетбинса. Даже если бы и получилось это сделать как разовая операция, то потом поддерживать/развивать тоже очень непросто, мало кто хочет с этим возиться. При этом для ряда популярных языков как Джава, Питон, Руби, Haxe и пр. свои парсеры есть.
PSV>> А некоторым интузиастам и для C++ нафиг не нужен и автокомплит, например. K>Лично мне корректный семантический автокомплит не шибко критичен, меня в большинстве случаев устроит и тупой словарный из Emacs. А вот проверка корректности кода по мере набора и до компиляции для меня важна, также как и удобная навигация по всему коду в проекте. Только вот эти вещи посложнее кучи костылей с эвристиками для автокомплита.
Да, тут вы правы. Жаба, как промышленное явление, в своё время конкретно подсадила на иглу всю отрасль.
PSV>>В моём случае, редактор часто используется для своего DSL, который специально спроектирован для простой работы. В начале был прицел, чтобы реализовать полноценный парсер для работы в редакторе, в т.ч. и со всякой семантикой (в JEdit есть полноценная система для своих парсеров, чем-то похоже на механизмы в Эклипсе).
K>Если так много кода нужно писать и поддерживать на своем DSL, то можно попробовать на фреймворке Xtext написать.
Спасибо, про Xtext я в курсе, как и про MPS от Jetbrains. В своё время я смотрел эти системы, как-то там не всё просто и однозначно, нужно детально разбираться. В любом случае, их функционал для наших задачи не подходит. А у нас как раз всё заточено на то, чтобы кроме текстового редактора больше ничем не нагибать. С кодом работают разные люди, программисты в различных областях и с различной квалификацией, а также и не совсем программисты, например, администраторы. Многим даже и раскраска кода особо не нужна.
Re[7]: Нормальный редактор для C++ - существует ли?
Здравствуйте, alex_public, Вы писали:
_>Ммм, ну относительно специфично. Всё же doxygen это: C++, C, Java, Objective-C, Python, IDL , Fortran, VHDL, PHP, C#, D.
Ну все же специфично А делать как плагин или встраивать в базовую функциональность, для пользователя какая разница? Главное чтоб работало
K>>Еще можно добавить Context Help item прямо в проект. Тогда его шоткат перекроет шоткат контекстной справки языка. _>Только что бы не перекрывал, а что бы искал в нём первом и если в нём нет, то шёл к системным chm...
Ну, это как сконфигурируешь. Можно решить разными путями. Если искать по набору chm, то просто поставить chm проекта первым.
_>В общем я могу сказать как у нас сделано — как сделать это же в вашем редакторе максимально удобно не знаю пока. У нас все построения работают из командной строки (т.е. принципе нам даже не обязательно для этого IDE — просто мелкое удобство). Все команды одиного типа: scons release, scons debug, scons tests, scons help, scons installer и т.д. И всего таких штук 10 на обычный проект.
Понятно. В принципе у меня идея есть как это сделать, чтоб было как надо Надо добавить возможность создания наборов user variables. Выпадающий список все же будет нужен в тулбаре, для переключения этих конфигураций.
Я себе записал, если будете пользоваться, и будет надобность — добавим.
_>О, кстати, забыл написать об этом в прошлый раз. У вас тут минус нашёлся, который я правда преодолел своими силами, но всё же... В общем scons — это под виндой bat файл коротенький, который запускает реальный python скрипт. Так вот у вас почему-то не перехватывается его вывод (т.е. возникает отдельное окно терминала а в вашем output пустота). Эклипс и Нетбинс работает без проблем. Ну я исправил это поставив в командную строку инструмента не scons, a собственно тот вызов питона. Но в целом это не дело. А если бы тот bat файл был большим и сложным? )
A Capture Output флаг был включен в настройка Tool? Ну и Output Type должен быть "Output Window". Если все стоит и все рано не ловит — может баг. Должно работать. Пишите баг репорт разберемся
1.50 это major beta, так что могло что-то поломаться. 1.49 — стабильная. Но новые фичи посмотреть / добавить лучше в 1.50.
Re[9]: Нормальный редактор для C++ - существует ли?
Здравствуйте, PSV100, Вы писали:
PSV>Кстати, здесь рядом рекомендовали HippoEdit — неплохая штука, давно на него смотрел, тогда он был в какой-то бете и был неюзабельный, но внимание привлёк. Сейчас руки всё никак не доходят посмотреть.
Посмотрите еще раз Но в этот раз я тоже дал ссылку на major beta 1.50
Здравствуйте, Kefir, Вы писали:
K>Понятно. В принципе у меня идея есть как это сделать, чтоб было как надо Надо добавить возможность создания наборов user variables. Выпадающий список все же будет нужен в тулбаре, для переключения этих конфигураций. K>Я себе записал, если будете пользоваться, и будет надобность — добавим.
Я тут посмотрел... Оно оказывается добавляет инструменты проекта ещё и в окошко project explorer — это в принципе может быть нормальной заменой того выпадающего списка.
Хотя идея с конфигурациями как в нетбинсе всё же эффективнее потому как там же не 1 команда, а сразу несколько от конфига зависят: построить, очистить, выполнить. А тут тогда 3хN tools заводить — перебор уже точно. )))
K>A Capture Output флаг был включен в настройка Tool? Ну и Output Type должен быть "Output Window". Если все стоит и все рано не ловит — может баг. Должно работать. Пишите баг репорт разберемся
Не, на самом деле это я ошибся. Не заметил что оно почему то само переключает Capture Output в зависимости от команды. Т.е. когда там python стоит — одно (флаг стоит), а когда меняю на scons.bat флаг автоматом убирается (надо потом вручную снова поставить). Из-за этого ошибся. )
Re[9]: Нормальный редактор для C++ - существует ли?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Kefir, Вы писали:
_>Я тут посмотрел... Оно оказывается добавляет инструменты проекта ещё и в окошко project explorer — это в принципе может быть нормальной заменой того выпадающего списка. _>Хотя идея с конфигурациями как в нетбинсе всё же эффективнее потому как там же не 1 команда, а сразу несколько от конфига зависят: построить, очистить, выполнить. А тут тогда 3хN tools заводить — перебор уже точно. )))
Инструменты добавляются в проект, можно как из главного меню, как и контекстно — кликая по дереву проекта. Просто когда из меню не понятно в какой нод вставляется (если окно Project Explorer скрыто). Но по правилам все команды должны быть доступны из меню. Вот оно там и есть.
А с конфигурациями да — удобней. Ну и более интуитивно. User Variables есть как также на уровне проекта, так что все получиться логично.
K>>A Capture Output флаг был включен в настройка Tool? Ну и Output Type должен быть "Output Window". Если все стоит и все рано не ловит — может баг. Должно работать. Пишите баг репорт разберемся _>Не, на самом деле это я ошибся. Не заметил что оно почему то само переключает Capture Output в зависимости от команды. Т.е. когда там python стоит — одно (флаг стоит), а когда меняю на scons.bat флаг автоматом убирается (надо потом вручную снова поставить). Из-за этого ошибся. )
Надо посмотреть. Оно меняет состояния флага (Enabled/Disabled) в зависимости если консоль поддерживается. И должна выключать+дисайблить флаг если не поддерживаеться, но не похоже не должна включать автоматом...
Re[10]: Нормальный редактор для C++ - существует ли?
Здравствуйте, Kefir, Вы писали:
K>Здравствуйте, PSV100, Вы писали:
PSV>>Кстати, здесь рядом рекомендовали HippoEdit — неплохая штука, давно на него смотрел, тогда он был в какой-то бете и был неюзабельный, но внимание привлёк. Сейчас руки всё никак не доходят посмотреть. K>Посмотрите еще раз Но в этот раз я тоже дал ссылку на major beta 1.50
Я давненько здесь на форуме (скорее в С/С++) как-то заметил тему, где Вы пытались что-то обсудить для своего редактора (вроде что-то по буферам текста), и посмотрел ваш проект. Тогда им пользоваться было невозможно (краши, зависания), и была якобы рабочая версия, но вкусности были именно в нерабочей бете. Редактор оставил приятные впечатления, но пришлось тогда работать с NotePad++. Затем я использовал вим/эмакс (и сейчас изредка), а сегодня больше работаю в JEdit (кроме всяких разных IDE). Инфа о вашем редакторе на глаза как-то не попадалась, и как-то он подзабылся. И вот приятно удивлён, что проект имеет свою жизнь. У меня у самого есть кое-какой опыт создания редакторов/IDE, но далеко не с пустого листа (проект SynEdit для Delphi/FreePascal), так что я имею представление, какая проделана работа, причём сразу видно, что с пониманием дела.
Поэтому, мои небольшие поздравления с успехом...
Но, к сожалению, лично я воспользоваться редактором для работы вряд ли смогу. Для меня желательна кроссплатформа (хотя работаю в основном под виндой), да и есть уже наработанные решения в других редакторах. Также не позволит совесть использовать ваш редактор бесплатно в кое-каких коммерческих разработках (согласно лицензии). К тому же, я уже "прикипел" к тем принципам, подходам в интерфейсе и управлении средой, которые есть в вим/эмакс/JEdit/Sublime, а также к их идеологии тотального "программирования редактора", везде и во всём. Ваш редактор очевидно рассчитан на тех, кто привык к Visual Studio. Даже если у Вас есть какие-то тайные желания в каком-то развитии, то, имхо, есть немало технических проблем, с той же кроссплатформой. К тому же понятно, что проект редактора — это не основная сфера вашей деятельности, и много времени ему уделять нет возможности.
В общем, интерфейс и управление средой — это отдельная немалая тема. И в вашем редакторе есть отличный функциональный потенциал составить достойную конкуренцию многим проектам, включая и ныне самый гламурно раскручиваемый (но, имхо, не на пустом месте) Sublime. Даже, в какой-то степени, и для эмакс: у вас есть возможность использовать разные шрифты и размер для текста, осталось добавить вывод картинок, эмуляцию кнопок, чекбоксов, таблиц, деревьев и пр., и можно реализовать принцип эмакса — со всем можно работать как с текстом, что дает огромным потенциал.
А так, конечно, в жизни всё ещё может пригодиться, и рекомендовать другим ваш редактор можно смело, без страха получить ответный фингал .
Я немного повертел редактор, у меня скопились всякие мысли по этому поводу, могу поделиться, вдруг, что-то пригодится. Возможно здесь будут некоторые "придирки", что ли, но откровенно говоря, когда работаешь в какой-нибудь IDE на много чего не обращаешь внимания, но когда в удобном редакторе — уже стараешься "выжать" всё для своего же блага. Итак, попробую.
— несколько портит картину о лёгковестности вариант поставки с pdb, особенно неподготовленного человека. Я вроде в этой бете особых глюков/крашей не заметил. Может есть смысл сделать вариант сборки и без pdb, а уже постоянные пользователи, кто помогает в тестировании, смогут взять себе с pdb.
— Я так понимаю, что нет возможности указывать длинные шорткаты из нескольких нажатий, вида "Ctrl-E, Ctrl-A". Жаль. Не мешало бы иметь некие виртуальные шорткаты, типа каких-то Meta, например, "Ctrl-E, g h" -> "Ctrl-K, g h", т.е. Ctrl-E и Ctrl-K — одно и то же. Полезно иметь глобальные переназначения клавиш, типа Ctrl перебросил на CapsLock. В идеале, хотелось бы иметь в редакторе обработку клавиш на уровне scan-кодов, чтобы не влиял текущий язык (en|ru).
— нет глубокой настройки базовых операций. Например, кому-то нужно, чтобы перемещение по словам работало чуть иначе: нажал Ctrl+вправо и курсор прыгнул не в начало следующего слова, а на конец текущего слова. Или, например, когда постоянно жмёшь влево не нужен переход на верхнюю строку, когда уперлись в начало.
Или, например, мне удобно, когда курсор не доходит до самого конца/начала экрана, а за строчек 5 начинается прокрутка. Сейчас в редакторе вроде за 1 строку начинается прокрутка, но при этом есть какая-то задерганность на экране — выделение текущей строки прыгает туда-сюда. И сам индикатор курсора при работе в редакторе как-то бывает иногда задерганным, мельтешит в глазах.
А плавная прокрутка, кстати, у вас сделана приятно, и вроде даже отключаема (что полезно).
— вроде заявлена фича для автоматического обрамления скобками, но как-то не до конца проработанная. Например, не всегда работают кавычки (скорее, это где-то настраивается, чем обрамлять). Если я передумал обрамление и нажал undo, то отменяется одна скобка, а не две. Или нажал "(", получил "()", затем нажал backspace, но удалил только левую скобку, без правой. Одним словом, посмотрите на Sublime, там это хорошо отработано.
— чуток бы поудобнее автокомплит. Например, когда вставляется в код функция неплохо курсор переносить во внутрь скобок, когда есть параметры, или за скобки, когда их нет.
— также не заметил фактически сегодняшнего "стандарта" — сниппетов или шаблонов по мотивам TextMate, которые есть в том же Sublime. Весьма полезны.
— частенько во всяких хинтах, где выводится код, например, при подсказке списка параметров функции, рисуются квадратики. Это не убираются переводы строк: char 10 и 13.
— заметил глюк: иногда после undo индикатор цвета слева в панели с текстом, что указывает на измененность строк, не сбрасывается, т.е. показывает, что строка изменена.
— там же слева, где номера строк, неплохо подсвечивать область вместе с выделением скобочек. т.е. когда выделяются парные скобки (или другие элементы) и они на разных строках, то слева светится индикатор, как это делает JEdit. И само выделение парных элементов иногда лучше обрамлять рамочкой, вместо цвета или подчёркивания — так они лучше выделяются, особенно когда рядом есть другие фоновые цвета или подчёркивания.
И неплохо выделять синтаксическую область слева, по мотивам Эклипса.
Также неплохо слева выделять область для текущей строки, когда она в режиме wordwrap и виртуально расползается на несколько строк на экране, как это делает Sublime.
— Пробелы, концы строк, табы можно выделять через точечки, но не по средине строки, а внизу, как обычные точки, только дать им другие цвета, как это делает jedit. Тогда эти символы будут не бросаться в глаза, при этом можно включить их постоянный вывод и смотреть на них не только при выделении текста.
— не хватает опции, чтобы концевые пробелы обрубались сразу по ходу дела, а не только при сохранении.
— не хватает опции, чтобы внутри выделения тоже рисовалась раскраска кода.
— очень не хватает множественного выделения, как это сделано в jedit (лучший вариант) или в Sublime. Я так понимаю, что ввести его очень проблематично, ибо требуется переделка многого функционала, который работает с выделением. Для некоторых случаев можно реализовать режим для группового изменения, как это сделано в Lazarus, например: выделили блок, нажали клавишу или пиктограмму слева от текста, включился режим спец-редактирования, таб-ом выбрали нужное слово, редактируем и все такие же слова одинаково изменяются, нажили esc — закончили. Как это выглядит, можно глянуть здесь.
— вроде для выделений есть режимы Reset/Restore, но как-то они не так работают. Посмотрите опять же на Sublime.
И ещё по выделению. Вроде заявлен способ перемещения через выделение, когда, например, выделили блок, курсор на его правой границе, нажали влево — перелетели на его начало, но нажатие вверх почему то работает как обычно.
— у вас вроде неплохой набор функций вокруг буфера обмена. В JEdit-е есть ещё неплохая штука — он хранит историю удаленных элементов, которые не кидались в буфер обмена, и можно делать вставки оттуда. Также в редакторах есть работа с буферами-регистрами по мотивам эмакса, но лично я уже отошёл от их использования. Они полезны для всяких макросов/скриптов, но если есть нормальный API, то и там можно на них забить.
— глюк в окне закладок: после перегрузки редактора там появились какие-то пустые строки в начале списка. При нажатии "перейти" на закладке нет переключения на нужное окно с файлом. Также не хватает позиции столбца (кроме строки). В JEdit-е есть ещё удобный способ работы с именованными метками, но у вас есть Anchor, в принципе, наверно его достаточно. Не хватает типовой функции выделения текста от Anchor до текущего положения курсора.
— в редакторе весьма гибкий поиск, но вроде нет возможности искать/заменять многострочные выражения. В jedit-е есть классная штука: замена текста на результат работы макро-кода. Удобно, иногда избавляет от написания макроса или внешнего скрипта/утилиты.
— глюк в инкрементном поиске: жму F3 — переход на следующее найденное значение, жму Shift-F3 — инкрементный поиск сбрасывается и ищется пред. значение из обычного поиска.
— не очень улобная работа с фолдингом. Нет понятия уровней, не ясно, можно ли делать произвольные свёртки. Не хватает виртуального вырезания кода, т.е. временного отбрасывания лишнего, как механизм Narrow в JEdit.
— не понятно, как работать с буферами, или файлами: если делать split в окне, то там показывается только этот же файл, причём всегда синхронно (если слева-справа). Если расположить два MDI-окна рядом с одним и тем же файлом, то не ясно как синхронизировать при необходимости.
— в полноэкранном режиме редактор не перекрывает весь экран — видна виндовская панель задач. В Sublime есть ещё один приятный режим — Distraction Mode.
— не понял, как работают макросы. Скорее, чего-то не хватает в поставке. Я предполагаю, что будет задействован стандартный майкрософтский ActiveX для скриптинга (не помню как он обзывается), и скрипты можно будет ваять на JavaScript.
В общем, всего вспомнить уже не могу. Не стоит "принимать всё близко к сердцу", но может быть что-то полезное я указал. Также хотелось бы предложить для редактора такие фичи:
— список ошибок. Сейчас в редакторе ошибки светятся чёрточками справа от текстовой панели. Не мешало бы их вывести отдельным списком, да и внутри кода подчеркнуть при необходимости. Но, возможно есть проблема, что парсеры в редакторе не дают подробного описания ошибки и не объясняют, чем им "красное" место не нравится.
Также полезен вывод ошибок при обработке результатов внешних тулсов (я пока не в курсе, как работает их запуск, примерно увидел, что чего-то есть).
— всякие разные списки своих заметок и определенных элементов, типа TODO-метки.
— модные ныне minimap-ы. В основном, баловство, но иногда приятны, особенно когда можно чуть увеличить и видны всякие подчёркивания и выделения. Им не хватает какого-нибудь hint-а: под мышкой чтобы вылазило окошко с увеличенной информацией.
— diff-сравнивалки. B JEdit-е есть простой, но хороший diff. Удобно, когда сразу внутри редактора можно всё править по месту, пользуясь всеми его функциями, вместо запуска внешних тулсов.
В общем, я думаю, что Вы всякие хотелки знаете побольше меня.
И есть пару вопросов:
— я не увидел фичи, как делать поиск по chm-файлам, о которой тут на форуме была речь;
— что может выводить Overview Bar (только чёрточки типа для ошибок ?);
— что может вытворять Smart Navigate (Alt+G) ?
— можно пару слов про Nesting Level (хотя вроде понятно), Alternative Mode (ну вроде тоже), Virtual Space, Inactive Code.
Спасибо.
Re[11]: Нормальный редактор для C++ - существует ли?
Отвечу за автора на пару вопросов. )))
PSV>- я не увидел фичи, как делать поиск по chm-файлам, о которой тут на форуме была речь;
Настраивается в меню Help->Syntax Help->Manage Help. Использовать логичнее всего по клавиатурной комбинации. Правда пока для каждого chm надо отдельную создавать, что не удобно. Хотя по языкам оно само разделяет — уже хорошо. Но у меня для одного C++ штук 5 будет. )))
PSV>- что может вытворять Smart Navigate (Alt+G) ?
Ну для C++ оно частично (в рамках файла) заменяет Go to Difinition из больших IDE. На мой взгляд в рамках одного файла работает очень не плохо.
Re[10]: Нормальный редактор для C++ - существует ли?
У меня тут ещё вопрос возник. Я там заметил команду форматирования... А где-то есть настройки этого форматирования? ) Я что-то не нашёл. А ведь расстановка скобочек, переносов и пробелов — это же почти религиозный вопрос. ))) В том же Нетбинсе настройке форматирования посвящено окошко с приблизительно миллионом опций. )))
Re[11]: Нормальный редактор для C++ - существует ли?
Здравствуйте, PSV100, Вы писали:
PSV>Наконец-то посмотрел на ваш бегемотик. Кстати, прикольный логотип, чувствуется рука дизайнера.
Это жена Жена — художник (не дизайнер). По поводу иконки, если честно (ну и названия) — мнения не однозначные.
Спасибо за огромный (и дельный) отзыв. Но думаю, не все осилят его до конца Но для меня — очень полезно.
В общем о редакторе: это Windows решение, мульти-платформенность я не планирую. С одной стороны сейчас уже будет много работы с рефакторингом и тд, а с другой стороны работа под одну платформу дает свои преимущества по оптимизации и UI.
HippoEDIT это не emacs/vim альтернатива, и в принципе я не хочу сильно развиваться в эту сторону. Перетянуть пользователей emacs/vim на GUI платформу трудно (из-за разности мировозрения) а развиться до их уровня и больше не реально (хотя бы из-за платности). Идея была создать GUI редактор который бы с одной стороны был интуитивен и легок в освоении а с другой стороны обладал продвинутой функциональностью необходимой опытным пользователям. Позволял глубокую настройку, но не засорял интерфейс. Ну и чтоб работал "as expected but not as designed"
Кое что получилось, кое что не очень. Редактор уже стал достаточно сложным в освоении и перегружённым функциями и настройками. С множественными кастомизациями требуемыми пользователями, я борюсь использованием XML настроек, изменять которые можно только прямым редактированием файлов установок (например сколько линий оставлять до границы окна до начала прокручивания при навигации — ваш вопрос). Ну конечно если это что то распространенное то переноситься в UI.
С новыми функциями, как то языково специфичные расширения или какие нибудь функции форматирования — решение было плагины (появилось в 1.50). Пришлось очень много переделать, чтоб плагины органично вписались в архитектуру и были не только способом внешних расширений, но и направлением внутреннего развития. Сейчас поддерживаются два вида плагинов: бинарные (dll, COM based но без регистрации) — для критических расчетов, как то наложение стилей (Spell Checker), функциональных панелей (Bookmark Manager, File and Project Explorer), auto compelete (в проекте), Debuging (в проекте) и тд; и скриптовые (Active Scripting) — для не критических расчетов и расширений, как то дополнительные команды, тулбары, меню, диалоги, индикаторы статус бара, шаблоны кода и тд. Идея была чтоб функционально скриптовые плагины были сравнимы по функционалу с бинарными. Они резиденты, кешируются, поддерживают инклуды, смешанные языки, динамические события, инлайновые функции, закладки свойств и тд. Все на базе Active Scripting, но сделано максимально удобно для использования и очень много API открыто (правда пока не документировано). Плагины имеют "бесшовную" интеграцию и не отличимы от оригинальной, встроенной функциональности. Примеры можно глянуть здесь.
Ну и дальше по тексту...
PSV>Поэтому, мои небольшие поздравления с успехом...
Спасибо.
PSV>Но, к сожалению, лично я воспользоваться редактором для работы вряд ли смогу. Для меня желательна кроссплатформа (хотя работаю в основном под виндой), да и есть уже наработанные решения в других редакторах. Также не позволит совесть использовать ваш редактор бесплатно в кое-каких коммерческих разработках (согласно лицензии). К тому же, я уже "прикипел" к тем принципам, подходам в интерфейсе и управлении средой, которые есть в вим/эмакс/JEdit/Sublime, а также к их идеологии тотального "программирования редактора", везде и во всём. Ваш редактор очевидно рассчитан на тех, кто привык к Visual Studio. Даже если у Вас есть какие-то тайные желания в каком-то развитии, то, имхо, есть немало технических проблем, с той же кроссплатформой. К тому же понятно, что проект редактора — это не основная сфера вашей деятельности, и много времени ему уделять нет возможности.
Каждый выбирает то что ему больше подходит — это понятно. Sublime реально неплохой редактор, там много чего уникального и приятного. Как то множественное выделение, предосмотр файлов и go to anywhere (или че-то похожее). MiniMap — красиво но я не уверен в ее необходимости. Я думаю Overview Bar более функциональна. То же Distraction Mode — я не делал его не потому что не смог , а просто не захотел (бенефиты/затраты меня не устроили). Был еще неплохой редактор такого плана Intype, но он умер. Jedit мне не понравился — тяжеловат, но интеграция плагинов сделана хорошо. EmEditor хорош, для простого текста.
PSV>В общем, интерфейс и управление средой — это отдельная немалая тема. И в вашем редакторе есть отличный функциональный потенциал составить достойную конкуренцию многим проектам, включая и ныне самый гламурно раскручиваемый (но, имхо, не на пустом месте) Sublime. Даже, в какой-то степени, и для эмакс: у вас есть возможность использовать разные шрифты и размер для текста, осталось добавить вывод картинок, эмуляцию кнопок, чекбоксов, таблиц, деревьев и пр., и можно реализовать принцип эмакса — со всем можно работать как с текстом, что дает огромным потенциал.
Нет — это не наш путь. См выше. Я предпочитаю бесшовное расширение существующего интерфейса, но не хочу уходить в текстовый режим. И картинки в тексте — тоже планирую. У меня есть поддержка скриптовых нативных диалогов (таблицы и дерева пока нет, но можно добавить), я думаю это для HippoEDIT перспективнее.
PSV>- несколько портит картину о лёгковестности вариант поставки с pdb, особенно неподготовленного человека. Я вроде в этой бете особых глюков/крашей не заметил. Может есть смысл сделать вариант сборки и без pdb, а уже постоянные пользователи, кто помогает в тестировании, смогут взять себе с pdb.
У меня выложено 6 версий инсталляторов: для 3х технологий, с pdb и без. Просто для тестирования я всегда даю ссылки на версии с pdb — при падении, редактор отсылает crash report, где в в дополнении к дампу лежит errorlog с callstack. Для коррекного формирования callstack на клиенте нужны pdb. Часто бывает у меня уже pdb нет, а callstack посмотреть можно.
Но при желании всегда можно скасать версию без pdb (убрать _pdb в конце файла). Ну и на сайте (не на форуме) везде версии без pdb.
PSV>- Я так понимаю, что нет возможности указывать длинные шорткаты из нескольких нажатий, вида "Ctrl-E, Ctrl-A". Жаль.
Есть. Можно задавать композитные шоткаты как "Ctrl-E, Ctrl-A". Но только двух компонентные. "Ctrl-E, Ctrl-A, B" — нельзя. Можно несколько шоткатов на команду. плюс шоткаты перекрываются языково или проекто специфичными.
Можно делать Alt + Menu Accelerators. Есть Command Hints (View->Command Hints).
PSV>- Не мешало бы иметь некие виртуальные шорткаты, типа каких-то Meta, например, "Ctrl-E, g h" -> "Ctrl-K, g h", т.е. Ctrl-E и Ctrl-K — одно и то же.
Не понял.
PSV> — Полезно иметь глобальные переназначения клавиш, типа Ctrl перебросил на CapsLock.
Ну не знаю. Можно, но пока никто не просил
PSV> В идеале, хотелось бы иметь в редакторе обработку клавиш на уровне scan-кодов, чтобы не влиял текущий язык (en|ru).
Да, это так Хотелось бы — пока нет. Себе запишу.
PSV>- нет глубокой настройки базовых операций. Например, кому-то нужно, чтобы перемещение по словам работало чуть иначе: нажал Ctrl+вправо и курсор прыгнул не в начало следующего слова, а на конец текущего слова. Или, например, когда постоянно жмёшь влево не нужен переход на верхнюю строку, когда уперлись в начало.
Ну да это можно — но опять, никто не просил. А усложнять без надобности — неблагодарное дело. Основной массе людей это будет не нужно, и не известно (в UI это конечно выносить не надо).
PSV>Или, например, мне удобно, когда курсор не доходит до самого конца/начала экрана, а за строчек 5 начинается прокрутка. Сейчас в редакторе вроде за 1 строку начинается прокрутка, но при этом есть какая-то задерганность на экране — выделение текущей строки прыгает туда-сюда. И сам индикатор курсора при работе в редакторе как-то бывает иногда задерганным, мельтешит в глазах.
Это настраиваемо — через XML. В UI нет. Чтоб меньше прыгал можно попробовать "Double rate on key repeat" -> Tools -> Options -> Formatting -> Smart Helpers.
PSV>- вроде заявлена фича для автоматического обрамления скобками, но как-то не до конца проработанная. Например, не всегда работают кавычки (скорее, это где-то настраивается, чем обрамлять).
Да это языково, контекстно зависимо. PSV>Если я передумал обрамление и нажал undo, то отменяется одна скобка, а не две.
Это баг. PSV>Или нажал "(", получил "()", затем нажал backspace, но удалил только левую скобку, без правой. Одним словом, посмотрите на Sublime, там это хорошо отработано.
Удаляет сразу две скобки, если стоять справа от (). Но да, можно сделать лучше.
PSV>- чуток бы поудобнее автокомплит. Например, когда вставляется в код функция неплохо курсор переносить во внутрь скобок, когда есть параметры, или за скобки, когда их нет.
Редактор не знает ничего о языке. Есть только схема (куча xml файлов в data folder) и динамический общий парсер, autocomplete основан на его результатах, разборе меток, шаблонов кода и статистики использования.
Функция, не функция — ему едино. Так что здесь нужно специализированное решение в виде плагина.
PSV>- также не заметил фактически сегодняшнего "стандарта" — сниппетов или шаблонов по мотивам TextMate, которые есть в том же Sublime. Весьма полезны.
Оно есть — называется Code Templates. Языково (синтакс) специфично. Можно поискать в Tools->Options.
PSV>- частенько во всяких хинтах, где выводится код, например, при подсказке списка параметров функции, рисуются квадратики. Это не убираются переводы строк: char 10 и 13.
Это баг. Если можно, пошлите пример воспроизведения. Никогда раньше не видел.
PSV>- заметил глюк: иногда после undo индикатор цвета слева в панели с текстом, что указывает на измененность строк, не сбрасывается, т.е. показывает, что строка изменена.
Скорее всего не все отменили. Посмотрите историю Undo (popup окно под кнопкой undo).
PSV>- там же слева, где номера строк, неплохо подсвечивать область вместе с выделением скобочек. т.е. когда выделяются парные скобки (или другие элементы) и они на разных строках, то слева светится индикатор, как это делает JEdit.
Да можно, но будет конфликтовать с подсветкой текущей области видимости. Я подумаю, может есть какой вариант, но большой надобности не вижу.
PSV>И само выделение парных элементов иногда лучше обрамлять рамочкой, вместо цвета или подчёркивания — так они лучше выделяются, особенно когда рядом есть другие фоновые цвета или подчёркивания.
Это поддерживается. Надо просто задать соответствующий аттрибут стиля активных элементов. Я пока не менял, потому как это подразумевает изменение схемы, а схемы у меня едины для всех версий. Не будет видно в старых версиях.
Стиль не виден в настройках но можно задать в XML.
PSV>И неплохо выделять синтаксическую область слева, по мотивам Эклипса.
Оно есть. Присмотритесь к Outlining. Show Current Scope. Можно сделать ярче при желании в настройках цветов.
PSV>Также неплохо слева выделять область для текущей строки, когда она в режиме wordwrap и виртуально расползается на несколько строк на экране, как это делает Sublime.
Не знаю. Можно конечно — не сложно. Но это видно и так если включить номера строк. Посмотрел, похоже в разреженном режиме строк здесь тоже баг. Надо рисочки для перенсенных линий не показывать. Но слева то индикатор все равно есть.
PSV>- Пробелы, концы строк, табы можно выделять через точечки, но не по средине строки, а внизу, как обычные точки, только дать им другие цвета, как это делает jedit. Тогда эти символы будут не бросаться в глаза, при этом можно включить их постоянный вывод и смотреть на них не только при выделении текста.
Ну их можно и так включить View->Editor->White Space + Trailing White Space (поискать в Options), и задать для них то цвет что хочешь (или увеличить прозрачность). Только надо обратить внимание на установки Contrast Ratio (options -> search "contrast"), они могут не позволить не контрастные сочетания.
PSV>- не хватает опции, чтобы концевые пробелы обрубались сразу по ходу дела, а не только при сохранении.
Ну не знаю. Плагин?
PSV>- не хватает опции, чтобы внутри выделения тоже рисовалась раскраска кода.
Оно есть, просто по умолчанию так. Просто в настройках стиля выделения надо установить прозрачный цвет текста.
PSV>- очень не хватает множественного выделения, как это сделано в jedit (лучший вариант) или в Sublime. Я так понимаю, что ввести его очень проблематично, ибо требуется переделка многого функционала, который работает с выделением. Для некоторых случаев можно реализовать режим для группового изменения, как это сделано в Lazarus, например: выделили блок, нажали клавишу или пиктограмму слева от текста, включился режим спец-редактирования, таб-ом выбрали нужное слово, редактируем и все такие же слова одинаково изменяются, нажили esc — закончили. Как это выглядит, можно глянуть здесь.
Да, не хватает. У меня запланировано. Но я думал лучшая имплементация у Sublime. У меня даже больше не проблема переделки функционала а проблема Usability: как начинать множественное выделение, клик с Ctrl зарезервирован под выделение слова (ну и вообще Ctrl везде связан с работой со словами). Вариант со спец режимом, я предпочитаю как дополнение, а не альтернативу.
PSV>- вроде для выделений есть режимы Reset/Restore, но как-то они не так работают. Посмотрите опять же на Sublime.
Ну не знаю. Режимом пользуются не часто, но нареканий не было. Я гляну.
PSV>И ещё по выделению. Вроде заявлен способ перемещения через выделение, когда, например, выделили блок, курсор на его правой границе, нажали влево — перелетели на его начало, но нажатие вверх почему то работает как обычно.
Не, вроде не заявлен Или я че-то что запрограммировал забыл
PSV>- у вас вроде неплохой набор функций вокруг буфера обмена. В JEdit-е есть ещё неплохая штука — он хранит историю удаленных элементов, которые не кидались в буфер обмена, и можно делать вставки оттуда.
Записал себе. Хотя в не убежден в надобности подобной функции. на крайняк можно сделать поиском через Undo больших, удаленных кусков. Чтоб новое хранилище не заводить.
PSV>Также в редакторах есть работа с буферами-регистрами по мотивам эмакса, но лично я уже отошёл от их использования. Они полезны для всяких макросов/скриптов, но если есть нормальный API, то и там можно на них забить.
Да, у меня уже в планах есть.
PSV>- глюк в окне закладок: после перегрузки редактора там появились какие-то пустые строки в начале списка. При нажатии "перейти" на закладке нет переключения на нужное окно с файлом. Также не хватает позиции столбца (кроме строки). В JEdit-е есть ещё удобный способ работы с именованными метками, но у вас есть Anchor, в принципе, наверно его достаточно.
С пустой строкой в начале списка — похоже на баг, но воспроизвести не смог. С переходом — это новый баг. Поправлю. Букмарки, базированны на линиях. Можно конечно добавить и колонку, но похоже народу это не надо.
PSV>Не хватает типовой функции выделения текста от Anchor до текущего положения курсора.
Оно есть. Edit->Selection->Select from Anchor.
PSV>- в редакторе весьма гибкий поиск, но вроде нет возможности искать/заменять многострочные выражения.
Поиск с регулярными выражениями. Просто вставьте многострочный текст в диалоге поиска Ctrl + F (не поддерживается в QuickSearch Bar -> Ctrl + Q).
PSV>В jedit-е есть классная штука: замена текста на результат работы макро-кода. Удобно, иногда избавляет от написания макроса или внешнего скрипта/утилиты.
Думаю это усложнение. Можно написать стандартный скрипт для всех.
PSV>- глюк в инкрементном поиске: жму F3 — переход на следующее найденное значение, жму Shift-F3 — инкрементный поиск сбрасывается и ищется пред. значение из обычного поиска.
Даже не помню как оно должно было быть Поправлю.
PSV>- не очень улобная работа с фолдингом. Нет понятия уровней, не ясно, можно ли делать произвольные свёртки.
Уровни не хотел — они засоряют UI. Хотя когда то в планах было.
Если произвольные свертки подразумевают, выделить мышкой произвольный кусок и свернуть — то пока нет, но запланировано.
Есть поддержка регионов — те можно для любого синтаксиса задавать области для свертки в тегах форматирования (в принципе в комментариях чтоб не тревожить компилятор).
PSV>Не хватает виртуального вырезания кода, т.е. временного отбрасывания лишнего, как механизм Narrow в JEdit.
Не уверен что оно надо. У меня есть другие идеи на этот счет, так что я скорее всего пойду в другом направлении.
PSV>- не понятно, как работать с буферами, или файлами: если делать split в окне, то там показывается только этот же файл, причём всегда синхронно (если слева-справа). Если расположить два MDI-окна рядом с одним и тем же файлом, то не ясно как синхронизировать при необходимости.
Синхронизации скролинга пока нет.
PSV>- в полноэкранном режиме редактор не перекрывает весь экран — видна виндовская панель задач. В Sublime есть ещё один приятный режим — Distraction Mode.
Distraction Mode — я не фанат. "видна виндовская панель задач" — это по дизайну. Можно конечно добавить кофигурационный флаг.
PSV>- не понял, как работают макросы. Скорее, чего-то не хватает в поставке. Я предполагаю, что будет задействован стандартный майкрософтский ActiveX для скриптинга (не помню как он обзывается), и скрипты можно будет ваять на JavaScript.
В HippoEDIT есть как макро последовательности, так и поддержка скриптинга на базе Active Scripting (см выше). Зачем надо было и то и другое здесь.
PSV>В общем, всего вспомнить уже не могу. Не стоит "принимать всё близко к сердцу", но может быть что-то полезное я указал.
И на том спасибо. Честно скажу — отвечаю уже 3й час
PSV>Также хотелось бы предложить для редактора такие фичи: PSV>- список ошибок. Сейчас в редакторе ошибки светятся чёрточками справа от текстовой панели. Не мешало бы их вывести отдельным списком, да и внутри кода подчеркнуть при необходимости. Но, возможно есть проблема, что парсеры в редакторе не дают подробного описания ошибки и не объясняют, чем им "красное" место не нравится.
Да парсер не знает что он показывает Обычно это просто ошибки, определенные на основе схемы (не закрытые скобки, scopes и тд). Думаю что подсветка на Overview Bar достаточна. А детальные сообщения можно отдать внешним инструментам и плагинам.
PSV>Также полезен вывод ошибок при обработке результатов внешних тулсов (я пока не в курсе, как работает их запуск, примерно увидел, что чего-то есть).
Все выводиться в Output панели (можно иметь много).
PSV>- всякие разные списки своих заметок и определенных элементов, типа TODO-метки.
Да это запланировано. Как плагины. Тем более TODO из кода уже сейчас показываются на Overview bar.
PSV>- модные ныне minimap-ы. В основном, баловство, но иногда приятны, особенно когда можно чуть увеличить и видны всякие подчёркивания и выделения. Им не хватает какого-нибудь hint-а: под мышкой чтобы вылазило окошко с увеличенной информацией.
Ну может быть. Как плагин. Народ просит, но я пока не убежден
PSV>- diff-сравнивалки. B JEdit-е есть простой, но хороший diff. Удобно, когда сразу внутри редактора можно всё править по месту, пользуясь всеми его функциями, вместо запуска внешних тулсов.
Да. Запланировано.
PSV>В общем, я думаю, что Вы всякие хотелки знаете побольше меня.
Да — у меня их уже килограммы Но всегда полезен взгляд со стороны, для развития старых идей либо получение новых.
PSV>И есть пару вопросов:
PSV>- я не увидел фичи, как делать поиск по chm-файлам, о которой тут на форуме была речь;
Ну вам уже ответили Кроме как для языка, можно добавить еще проектную контекстную справку.
С поиском по нескольким chm по одной команде я уже добавил, но версию еще не обновил. Может на следующей неделе выложу — поправлю что вы зарепортили
PSV>- что может выводить Overview Bar (только чёрточки типа для ошибок ?); Он много что показывает.
PSV>- что может вытворять Smart Navigate (Alt+G) ?
Зависит от контекста Скопировал из кода:
// here we would try to understand what user wants
// the result would depend from position where we are now
// what can kind of result can be:
// ------------------------------------------------------
// N | Object under cursor | Result
// 1 | Any type of brace | go to pair brace
// 2 | Scope Tag | go to pair tag or other depending on modifier keys
// 3 | name equal to label | go to definition of the label
// 4 | File | open file in IDE
// 5 | Directory | Open explorer with this directory as current
// 6 | mail | open default mail client with this address in To field
// 7 | Url | navigate to Url in IDE
// 8 | executable | execute file under cursor
// 9 | FirstOccurrence | first occurrence of the word in document/scope
Сейчас метки (метки, это части кода определенные по регулярным выражениям описанным в схеме, в частности может быть определение функции) ищуться и по открытым документам а не только в текущем. Дальше еще руки не дошли.
PSV>- можно пару слов про Nesting Level (хотя вроде понятно):
Уровень вложенности областей видимости. Дает некое представление о сложности куска кода.
PSV>Alternative Mode (ну вроде тоже)
Просто через строчная раскраска — удобна для работы с табличными данными
PSV>Virtual Space
Если хочется писать где хочешь, а не только в границах строки.
PSV>Inactive Code.
Используется в основном в документах со смешанными языками. "Тушит" неактивные синтаксисы. Например если вы редактируете скриптовую часть (позиция курсора) в HTML документе, раскраска HTML, CSS и прочее будет притушена.
PSV>Спасибо.
И вам большое спасибо за отзыв!
P.S: слава богу, это конец
Re[11]: Нормальный редактор для C++ - существует ли?
Здравствуйте, alex_public, Вы писали:
_>У меня тут ещё вопрос возник. Я там заметил команду форматирования... А где-то есть настройки этого форматирования? ) Я что-то не нашёл. А ведь расстановка скобочек, переносов и пробелов — это же почти религиозный вопрос. ))) В том же Нетбинсе настройке форматирования посвящено окошко с приблизительно миллионом опций. )))
Не найдете Я когда то давно, начал копать в эту сторону, пытаясь задавать правила форматирования в схеме, можно глянуть пример в файле cbase_spec.xml:
но потом — забил. Форматирование специфично для каждого синтаксиса, стандартные установки всех не устроят, надо будет вводить UI а сделать его подходящим для всех языков будет либо сложным, либо не удобным.
Сейчас форматирует базируясь на областях видимости (scopes), корректируя кое где базируясь на правилах из схем (см выше), и корректируя keyword case (где можно, для case sensitive языков нельзя) базируясь на Options->Formating->Case Correction.
Правильно будет писать свой плагин (скрипт или бинарный), перехватывать команду форматирования и делать как хошь.