Re[12]: Нормальный редактор для C++ - существует ли?
От: alex_public  
Дата: 29.03.12 01:21
Оценка:
Здравствуйте, Kefir, Вы писали:

K>Не найдете


Ммм, жаль) Хотя для своих кодов я такую функцию никогда и не использовал. А вот чужие привести в привычный вид одним нажатием в Нетбинсе бывало удобно.

Да, а мне тут баг встретился — не хочет назначать ассоциации файлов. Ставлю галочки, нажимаю update — окно молча закрывается, но в проводнике никаких изменений... Это потому что бета или нет? )
Re[12]: Нормальный редактор для C++ - существует ли?
От: PSV100  
Дата: 29.03.12 17:51
Оценка:
Здравствуйте, Kefir, Вы писали:

Вступление: предлагаю сразу на "ты", на форумах так проще...

PSV>>В общем, всего вспомнить уже не могу. Не стоит "принимать всё близко к сердцу", но может быть что-то полезное я указал.

K>И на том спасибо. Честно скажу — отвечаю уже 3й час

Сорри, сам писал не меньше, благо было время. Сейчас постараюсь поменьше, да и сильно разогнаться не могу.

Почему так получилось. Я когда-то разрабатывал типа встроенной IDE для продукта (бизнес-система), поверх SynEdit для Delphi (имхо, ты в курсе). После этого у меня в голове постоянно мысли как сделать нормальный удобный редактор, и есть тайные желания забабахать свой проект (какой же нормальный программист не мечтает о своём языке программирования (и языки приходилось делать) и о своём редакторе ? ). А тут и тема форума такая привлекла, и ты "за живое" задел...

PSV>>Наконец-то посмотрел на ваш бегемотик. Кстати, прикольный логотип, чувствуется рука дизайнера.

K>Это жена Жена — художник (не дизайнер). По поводу иконки, если честно (ну и названия) — мнения не однозначные.

Ну почему же, у меня язык не поворачивается назвать "бегемот", как раз "бегемотик", и иконка в тему. Имхо, и "буржуи" вполне адекватны.

K>В общем о редакторе: это Windows решение, мульти-платформенность я не планирую. С одной стороны сейчас уже будет много работы с рефакторингом и тд, а с другой стороны работа под одну платформу дает свои преимущества по оптимизации и UI.

K>HippoEDIT это не emacs/vim альтернатива, и в принципе я не хочу сильно развиваться в эту сторону. Перетянуть пользователей emacs/vim на GUI [...]

Да, мульти-платформенность это конкретная проблема и большое западло для С++, как минимум, в рамках GUI для всех платформ. Ребята из Sublime явно мучаются...
Я прекрасно понимаю сущность твоего редактора, на кого он рассчитан, и полностью поддерживаю правильное для тебя направление. И отлично понимаю, что большинство проблем/фич, которые мы затронули, мало кому нужны из твоих имеющихся пользователей. Я раньше сам многого не знал/не понимал нафига всякое оно нужно. Ну, имхо, определиться в чём-то для себя, как хозяину дела, лишний раз не помешает, конкуренция ведь растёт и растёт...

Здесь я много говорил о JEdit, ибо его "вкурил", и о Sublime. Я не фанат ни всяких редакторов/IDE, ни языков программирования и пр. JEdit имеет GUI-направленность, но по духу близок к эмакс, с хорошим функционалом. В Sublime, как у потомка TextMate, хорошая функциональность для операций с текстом, что сейчас пытаются перетянуть во многие редакторы, включая и в вим/эмакс. К тому же, у него есть неплохие попытки найти компромисс между GUI/Text-направленностью, работа без модальных диалогов (что уже начинают применять и всякие IDE, типа QtCreator), конфигурация только на основе текста (кстати JSON вместо XML), и пр. Я думаю, что ты сам всё прекрасно знаешь и меня правильно понимаешь.

K>...Был еще неплохой редактор такого плана Intype, но он умер.

Есть ещё "E-Editor", но Sublime всех задавил.

K>...Jedit мне не понравился — тяжеловат, но интеграция плагинов сделана хорошо.

Да, те, кому больше NotePad++ и не нужно, на него и не посмотрят. Сама жаба всех отпугивает, особенно на фоне эклипсов/нетбинсов/идеи. Но работает он шустро, по умолчанию он настроен для работы с памятью чуть с запасом (но гораздо меньше всяких хромов с лисами). Я экспериментировал с настройками и заставлял бегать под несколькими десятками мб, и ничего, нормально, GC чаще срабатывает конечно, но тормозов нет, это не сервер приложений. Есть возможность запустить "сервер" как в эмаксе, файлы из фара по Alt-F4 открываются мгновенно. Причём огромные файлы (например, лог) даже с подсветкой JEdit открывает быстрее всех.
Кстати, я обратил внимание, что в его декларациях для всяких правил разбора далеко не всегда указываются регулярные выражения, в отличие от многих редакторов, где всё на сплошных регулярках. Например, указывают типа так: это ключевое слово должно быть только со значимого начала строки, т.е. игнорируем все ведущие пробелы и пр. Скорее всего, это тоже сказывается на перфомансе.

И ещё про JEdit. У него есть ряд концепций, которые могут нормально вписаться в твой редактор, тем более, как я понимаю, уже ведётся неслабый рефакторинг в проекте:

— да, у него хорошо сделана работа с плагинами и макросами, что-то удобнее и не нужно. Нормальная логика в организации меню: удобно, когда всё, что касается плагинов, находится в одном месте — пункт "Plugins" в главном меню (и Macros ещё), остальные пункты — типа стандартные функции редактора. Так проще и быстрее разобраться в функционале. Кому нужно, можно организовать изменяющееся меню в зависимости от текущего языка (или mode, т.е. синтаксиса), больше это актуально для popup-меню внутри панели с текстом. Я, например, добавил себе в главное меню (т.е. в самый верхний уровень) всяких своих пунктов — повыносил себе нужные мне действия — так быстрее было освоить состав функционала. Самим меню пользуюсь редко, и всякие тулбары с кнопками поотключал.

— есть виртуальное понятие команд: Action. У тебя вроде тоже есть какие-то команды. Но они у тебя не удобно показываются. Лучше CamelCase светить так: "Very Long Command", особенно в каких-то списках. Так делает Sublime. В jedit также есть возможность с ними работать в эмакс-стиле, т.е. как с лисп-идентификаторами: very-long-command.

— есть удобная запускалка команд. Не помешала бы она в дополнение к твоим всяким вылетающим хинтам по командам и клавишам (кстати, здесь CamelCase лучше из-за множества столбцов). Есть команд-бар: клацнул — вылезла панелька типа твоего Quick Search, набрал пару букв, можно tab клацнуть — автодополнение (но в jedit нормального дополнения здесь не хватает), короче ввёл команду или имя макроса (!) — enter и выполнили. А если набираешь не буквы, а цифры — значит будем повторять действия, например, ввел 16 и клацнул пробел — вставили 16 пробелов, ввел 18 и left — перелетели на 18 левее.
Это удобно и избавляет от многих шорткатов.

— есть возможность на основе XML создать свои простые диалоги, без программирования. Например, сделать форму для настройки параметров перед запуском какой-нибудь тулсы (это плагин Console). Я так понимаю, ты работаешь сейчас над этим вопросом.

Есть ещё моменты в плане удобного интерфейса, грамотной работы с буферами и пр., но, скорее всего, в твоем редакторе они уже неприменимы, как минимум, без тотальных переделок. Но это уже не будет "маленькая студия".

K>У меня выложено 6 версий инсталляторов: для 3х технологий, с pdb и без. Просто для тестирования я всегда даю ссылки на версии с pdb — при падении, редактор отсылает crash report, где в в дополнении к дампу лежит errorlog с callstack. Для коррекного формирования callstack на клиенте нужны pdb. Часто бывает у меня уже pdb нет, а callstack посмотреть можно.

K>Но при желании всегда можно скасать версию без pdb (убрать _pdb в конце файла). Ну и на сайте (не на форуме) везде версии без pdb.
Понятно, сайт я не смотрел. А с pdb понятно зачем, ведь незря CrashReport.exe притянут.

PSV>>- Я так понимаю, что нет возможности указывать длинные шорткаты из нескольких нажатий, вида "Ctrl-E, Ctrl-A". Жаль.

K>... Но только двух компонентные. "Ctrl-E, Ctrl-A, B" — нельзя.
Имхо, любителям VS большего и не нужно.

PSV>>- Не мешало бы иметь некие виртуальные шорткаты, типа каких-то Meta, например, "Ctrl-E, g h" -> "Ctrl-K, g h", т.е. Ctrl-E и Ctrl-K — одно и то же.

K>Не понял.
Сейчас в эмаксе бывшую клавишу Meta эмулируют обычно через Alt или Esc.
А я имел в виду следующее. Заводим виртуальную клавишу, скажем, Ext. Определяем, что ее можно эмулировать так: "Ctrl+E" или "Ctrl-K". Назначаем шорткаты для команд вида: "Ext a s", "Ext i p". Теперь я могу вызвать команду так: "Ctrl+E", затем "a" и "s" или "Ctrl+K, a, s" — запустится та же команда. Но мне удобнее Ctrl жать правой, а "E" и клавиши с ней рядом — левой. Когда нужно клацать в районе "K" — удобнее правой это делать, соответственно Ctrl в это время удобнее клацать левой. Поэтому, когда хочу, жму Ctrl+E плюс остальное, а хочу — жму Ctrl+K плюс это же остальное. Думаю, что понятно.
При этом такая схема вместе с шорткатами вида "Ctrl+E A S" позволяют создавать много шорткатов (причём с логикой) и удобных, вместо неудобных для меня Ctrl+Alt, или когда пальцы можно сломать от четырёх одновременных нажатий, а то и более.

PSV>> — Полезно иметь глобальные переназначения клавиш, типа Ctrl перебросил на CapsLock.

K>Ну не знаю. Можно, но пока никто не просил
Имхо, и не попросят. Так, например, любят делать любители вима: при их способе работы им удобнее не тянуться мизинцем к Ctrl, а клацать CapsLock. Часто и к Esc не тянутся, жмут Ctrl/CapsLock + [.
Если будет эмулятор вима (а ведь могут потребовать после Sublime ), может пригодиться.

PSV>> В идеале, хотелось бы иметь в редакторе обработку клавиш на уровне scan-кодов, чтобы не влиял текущий язык (en|ru).

K>Да, это так Хотелось бы — пока нет. Себе запишу.
Причём это болезнь у всех поголовно. Если Ctrl+A, Ctrl+C работает всегда, то как раз всякие "Ctrl+E A S" — хрен там. Причём теоретически проблема решаема даже на уровне кроссплатформы — ведь браузеры позволяют всяким JavaScript-ам работать на уровне scan-кодов. Но конечно, это конкретный гемор в реализации.

PSV>>- нет глубокой настройки базовых операций. Например, кому-то нужно, чтобы перемещение по словам работало чуть иначе: нажал Ctrl+вправо и курсор прыгнул не в начало следующего слова, а на конец текущего слова. Или, например, когда постоянно жмёшь влево не нужен переход на верхнюю строку, когда уперлись в начало.

K>Ну да это можно — но опять, никто не просил. А усложнять без надобности — неблагодарное дело. Основной массе людей это будет не нужно, и не известно (в UI это конечно выносить не надо).
Да, для твоего редактора так оно и есть.

K>Это настраиваемо — через XML. В UI нет. Чтоб меньше прыгал можно попробовать "Double rate on key repeat" -> Tools -> Options -> Formatting -> Smart Helpers.

Как-то не помогает, но это не важно.

PSV>>- вроде заявлена фича для автоматического обрамления скобками, но как-то не до конца проработанная. Например, не всегда работают кавычки (скорее, это где-то настраивается, чем обрамлять).

K>Да это языково, контекстно зависимо.
Я так и думал. Для txt можно вместе с одинарными кавычками добавить и двойные по умолчанию.

PSV>>Или нажал "(", получил "()", затем нажал backspace, но удалил только левую скобку, без правой. Одним словом, посмотрите на Sublime, там это хорошо отработано.

K>Удаляет сразу две скобки, если стоять справа от ().
Ух-ты, так даже сам о великий Sublime из коробки не делает

PSV>>- чуток бы поудобнее автокомплит. Например, когда вставляется в код функция неплохо курсор переносить во внутрь скобок, когда есть параметры, или за скобки, когда их нет.

K> Редактор не знает ничего о языке. Есть только схема (куча xml файлов в data folder) и динамический общий парсер, autocomplete основан на его результатах, разборе меток, шаблонов кода и статистики использования.
K>Функция, не функция — ему едино. Так что здесь нужно специализированное решение в виде плагина.
Можно попробовать просто вставлять курсор внутри скобок, если они есть. Хотя, это мелочи.

PSV>>- также не заметил фактически сегодняшнего "стандарта" — сниппетов или шаблонов по мотивам TextMate, которые есть в том же Sublime. Весьма полезны.

K>Оно есть — называется Code Templates. Языково (синтакс) специфично. Можно поискать в Tools->Options.
Я как-то не заметил, есть ли там позиции/переменные, где можно быстро прыгать по tab, групповой ввод и пр., т.е. всё то, что вытворяет Sublime, например. Реально удобно.

PSV>>- частенько во всяких хинтах, где выводится код, например, при подсказке списка параметров функции, рисуются квадратики. Это не убираются переводы строк: char 10 и 13.

K>Это баг. Если можно, пошлите пример воспроизведения. Никогда раньше не видел.
Я немного приврал: это не частенько. Специально воспроизвести не удалось. Я не помню, было ли это точно внутри самого редактора, т.е. из панели с текстом. Но было точно в каком-то модальном диалоге, возможно с какими-то настройками, там тоже вылазили хинты. Имхо, там это несмертельно, его может никто и не увидит толком.

PSV>>- заметил глюк: иногда после undo индикатор цвета слева в панели с текстом, что указывает на измененность строк, не сбрасывается, т.е. показывает, что строка изменена.

K>Скорее всего не все отменили. Посмотрите историю Undo (popup окно под кнопкой undo).
Возможно так оно и есть. Специально не получилось сделать.

Кстати, а историю undo я даже не заметил: ее нет в главном меню, а на всякие кнопки я по привычке уже не смотрю (хотя сам когда-то такие же undo-кнопки делал). Имхо, важный момент...

PSV>>- там же слева, где номера строк, неплохо подсвечивать область вместе с выделением скобочек. т.е. когда выделяются парные скобки (или другие элементы) и они на разных строках, то слева светится индикатор, как это делает JEdit.

K>Да можно, но будет конфликтовать с подсветкой текущей области видимости. Я подумаю, может есть какой вариант, но большой надобности не вижу.
Это действительно не супер-важно. Просто, наверное, я к нему привык. Иногда помогает, когда сразу не видно, где светится парный элемент.
А вообще-то, в jedit сделано так, что он там никому не мешает. У тебя, кстати, удобно хинт светится для подсказки конца блока.
И по поводу выделений слева. Конечно хорошо, когда можно много чего выделять. В jedit есть ещё фича для закладок выделять номера строк вместо иконок, а также выделять номера через определенные позиции, и пр. Но как всё удобно сделать — я сам не знаю.

PSV>>- Пробелы, концы строк, табы можно выделять через точечки, но не по средине строки, а внизу, как обычные точки, только дать им другие цвета, как это делает jedit. Тогда эти символы будут не бросаться в глаза, при этом можно включить их постоянный вывод и смотреть на них не только при выделении текста.

K>Ну их можно и так включить View->Editor->White Space + Trailing White Space (поискать в Options), и задать для них то цвет что хочешь (или увеличить прозрачность). Только надо обратить внимание на установки Contrast Ratio (options -> search "contrast"), они могут не позволить не контрастные сочетания.
Понятно. Только вот эти параграфы, или как эти символы обзываются для конца строк а-ля Word (это очень распространено), как-то громоздки. В jedit светится точечка в конце строк, обычно оранжевая по умолчанию, она и в глаза не бросается, и заметна, когда специально посмотришь.

PSV>>- не хватает опции, чтобы концевые пробелы обрубались сразу по ходу дела, а не только при сохранении.

K>Ну не знаю. Плагин?
Ну я не в курсе, плагин или нет. Многие IDE для паскаля, как Delphi, делают это всегда по умолчанию, и вроде всё нормально, удобно. А вот во многих редакторах/IDE, особенно тех, кто под впечатлением от VS, этого нет. Почему — хз. Но это неважно.

PSV>>- очень не хватает множественного выделения, как это сделано в jedit (лучший вариант) или в Sublime. Я так понимаю, что ввести его очень проблематично, ибо требуется переделка многого функционала, который работает с выделением. Для некоторых случаев можно реализовать режим для группового изменения, как это сделано в Lazarus, например: выделили блок, нажали клавишу или пиктограмму слева от текста, включился режим спец-редактирования, таб-ом выбрали нужное слово, редактируем и все такие же слова одинаково изменяются, нажили esc — закончили. Как это выглядит, можно глянуть здесь.

K>Да, не хватает. У меня запланировано. Но я думал лучшая имплементация у Sublime. У меня даже больше не проблема переделки функционала а проблема Usability: как начинать множественное выделение, клик с Ctrl зарезервирован под выделение слова (ну и вообще Ctrl везде связан с работой со словами). Вариант со спец режимом, я предпочитаю как дополнение, а не альтернативу.

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

А в jedit сделано очень грамотно переключение выделений: "Ctrl-\" — включает/отключает множественное выделение, "Alt-\" — управляет выделением по столбцам. Не нужно жать всякие Alt-Shift-... Также почитай, как выделяется мышкой, и про её прочие функции (хотя я лично мышкой фактически не пользуюсь, даже не помню, как ее вертеть надо для выделения). Всё очень удобно.
Можно ещё переключатели добавить в строку статуса. Также реально полезно обычное выделение и множественное выделять разными цветами.

А для всяких спец режимов вокруг множественных выделений — нет ограничения для фантазий.

PSV>>- вроде для выделений есть режимы Reset/Restore, но как-то они не так работают. Посмотрите опять же на Sublime.

K>Ну не знаю. Режимом пользуются не часто, но нареканий не было. Я гляну.
Тут надо одновременно клацать и там и здесь. Пока заметил, что Reset в sublime не всегда сразу всё сбрасывает, как-то он удобнее.

PSV>>И ещё по выделению. Вроде заявлен способ перемещения через выделение, когда, например, выделили блок, курсор на его правой границе, нажали влево — перелетели на его начало, но нажатие вверх почему то работает как обычно.

K>Не, вроде не заявлен Или я че-то что запрограммировал забыл
А-а, понятно. Реально удобно использовать выделения не только для правки. Вот выше я давал шорткаты: "Ctrl+E a s" — выделить всё предложение, вместе с концевыми пробелами, или "Ctrl+K i p" — выделить содержательную часть параграфа, т.е. без хвостовых пробелов и пустых строк после него (вот кстати и логика в шорткатах: a — от "a object", i — от "in object", p — параграф и т.д., что упрощает запоминание), или "Ctrl+K i ' " — выделить всё внутри кавычек, но без самих кавычек. После выделения клацнул влево, вверх — перелетел в начало и т.д.

Кстати, в редакторе я не заметил выделений текстовых объектов. Полезны переходы типа вперёд/назад по параграфам и пр., выше по фолд-уровню и пр. Но, имхо, действительно это всё всем не нужно.

PSV>>- у вас вроде неплохой набор функций вокруг буфера обмена. В JEdit-е есть ещё неплохая штука — он хранит историю удаленных элементов, которые не кидались в буфер обмена, и можно делать вставки оттуда.

K>Записал себе. Хотя в не убежден в надобности подобной функции. на крайняк можно сделать поиском через Undo больших, удаленных кусков. Чтоб новое хранилище не заводить.
Да, в целом. Лично мне редко помогало, но иногда здорово. А в undo-истории нельзя выдрать кусок без восстановления всего предыдущего (хотя может и можно ?).

Кстати, вроде в виме очень крутое какое-то дерево для undo, но как с ним работать, я быстро не разобрался, а потом забил.

PSV>>Также в редакторах есть работа с буферами-регистрами по мотивам эмакса, но лично я уже отошёл от их использования. Они полезны для всяких макросов/скриптов, но если есть нормальный API, то и там можно на них забить.

K>Да, у меня уже в планах есть.
В jedit, кстати, всё сделано удобно.

PSV>>- глюк в окне закладок: после перегрузки редактора там появились какие-то пустые строки в начале списка. При нажатии "перейти" на закладке нет переключения на нужное окно с файлом. Также не хватает позиции столбца (кроме строки). В JEdit-е есть ещё удобный способ работы с именованными метками, но у вас есть Anchor, в принципе, наверно его достаточно.

K>С пустой строкой в начале списка — похоже на баг, но воспроизвести не смог. С переходом — это новый баг. Поправлю. Букмарки, базированны на линиях. Можно конечно добавить и колонку, но похоже народу это не надо.
Вот картинка:


Как получилось — я не заметил. Но вверху как таковых пустых строк нет, т.е. туда не попадёшь курсором или мышкой.

PSV>>- в редакторе весьма гибкий поиск, но вроде нет возможности искать/заменять многострочные выражения.

K>Поиск с регулярными выражениями. Просто вставьте многострочный текст в диалоге поиска Ctrl + F (не поддерживается в QuickSearch Bar -> Ctrl + Q).
Понятно. В том же jedit есть поля для многострочного ввода. В других редакторах иногда жмёшь Ctrl+Enter — и поле расширилось на две строки или более.

PSV>>В jedit-е есть классная штука: замена текста на результат работы макро-кода. Удобно, иногда избавляет от написания макроса или внешнего скрипта/утилиты.

K>Думаю это усложнение. Можно написать стандартный скрипт для всех.
Можно и скрипт. Но, например, можно задать какую-то регулярку, чего-то понаходить и конвертнуть в нижний регистр, указав в поиске для замены выражение "_0.toLowerCase()". Быстро, просто, удобно.

PSV>>- не очень улобная работа с фолдингом. Нет понятия уровней, не ясно, можно ли делать произвольные свёртки.

K>Уровни не хотел — они засоряют UI. Хотя когда то в планах было.
K>Если произвольные свертки подразумевают, выделить мышкой произвольный кусок и свернуть — то пока нет, но запланировано.
K>Есть поддержка регионов — те можно для любого синтаксиса задавать области для свертки в тегах форматирования (в принципе в комментариях чтоб не тревожить компилятор).
Я с фолдингом в последнее время тоже мало вожусь. Но частенько приятно, когда правила для фолдинга составлены грамотно, например, для своего DSL, и клацнул, скажем, сверни до 2-го уровня: получи список структур или функций, и т.п. В sublime есть свертки вида "сверни все атрибуты в тегах", тоже облегчает.

PSV>>Не хватает виртуального вырезания кода, т.е. временного отбрасывания лишнего, как механизм Narrow в JEdit.

K>Не уверен что оно надо. У меня есть другие идеи на этот счет, так что я скорее всего пойду в другом направлении.
Согласен, что этот Narrow не идеал. А какие идеи, если не секрет, конечно ?

PSV>>- в полноэкранном режиме редактор не перекрывает весь экран — видна виндовская панель задач. В Sublime есть ещё один приятный режим — Distraction Mode.

K>Distraction Mode — я не фанат. "видна виндовская панель задач" — это по дизайну. Можно конечно добавить кофигурационный флаг.
Да это всё неважно. Про Distraction Mode я просто подсказал, что есть такие варианты. А так, лично я просто привык, когда в полноэкранном режиме я больше ничего не вижу. Я раскрашиваю весь редактор в одни цвета, вечером — в тёмные, причём и текст и весь интерфейс в одном тоне — фактически вим/эмакс. Так просто приятнее работать.

PSV>>- не понял, как работают макросы. Скорее, чего-то не хватает в поставке. Я предполагаю, что будет задействован стандартный майкрософтский ActiveX для скриптинга (не помню как он обзывается), и скрипты можно будет ваять на JavaScript.

K>В HippoEDIT есть как макро последовательности, так и поддержка скриптинга на базе Active Scripting (см выше). Зачем надо было и то и другое здесь.
Ясно, а много языков реально востребовано ? Ведь усложняет процесс...
В jedit есть плагин, с которым можно програмлять на чём угодно, но как-то он особо никому не нужен...

PSV>>Также хотелось бы предложить для редактора такие фичи:

PSV>>- список ошибок. Сейчас в редакторе ошибки светятся чёрточками справа от текстовой панели. Не мешало бы их вывести отдельным списком, да и внутри кода подчеркнуть при необходимости. Но, возможно есть проблема, что парсеры в редакторе не дают подробного описания ошибки и не объясняют, чем им "красное" место не нравится.
K>Да парсер не знает что он показывает Обычно это просто ошибки, определенные на основе схемы (не закрытые скобки, scopes и тд). Думаю что подсветка на Overview Bar достаточна. А детальные сообщения можно отдать внешним инструментам и плагинам.
Я так и думал. А вот такие подсветки как в Overview Bar, как-то они, лично для меня, не очень информативны. Удобнее, когда есть явный их список и в коде все подсвечивается. Но в Jedit, да, работают спец-парсеры для этого.

PSV>>- модные ныне minimap-ы. В основном, баловство, но иногда приятны, особенно когда можно чуть увеличить и видны всякие подчёркивания и выделения. Им не хватает какого-нибудь hint-а: под мышкой чтобы вылазило окошко с увеличенной информацией.

K>Ну может быть. Как плагин. Народ просит, но я пока не убежден
Тут только одна мотивация для тебя — привлечение юзверов, многие просто кайфуют, и всё. Но работы до хрена...
Кстати, скачал сейчас NotePad++ по наводке alex_public, давненько я на него не смотрел. С этой хреновеной редактор падает постоянно...

PSV>>- diff-сравнивалки. B JEdit-е есть простой, но хороший diff. Удобно, когда сразу внутри редактора можно всё править по месту, пользуясь всеми его функциями, вместо запуска внешних тулсов.

K>Да. Запланировано.
Посмотри в jedit, реально удобнее и не нужно.

PSV>>- что может выводить Overview Bar (только чёрточки типа для ошибок ?);

K>Он много что показывает.
Понятно. Я думал, что может кроме чёрточек вдруг какие-то диаграммы вылазят, к примеру.

PSV>>- что может вытворять Smart Navigate (Alt+G) ?

K>Зависит от контекста Скопировал из кода: [...]
Ясно, подозревал, что это гибко настраивается.

PSV>>Virtual Space

K>Если хочется писать где хочешь, а не только в границах строки.
А можно в двух словах подробнее, или скриншот, если есть.


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


P.S. Блин, опять простыня. Писал весь день в твоем редакторе, с "перерывами на работу". Сорри...
Re[13]: Нормальный редактор для C++ - существует ли?
От: Kefir http://www.hippoedit.com
Дата: 29.03.12 19:15
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ммм, жаль) Хотя для своих кодов я такую функцию никогда и не использовал. А вот чужие привести в привычный вид одним нажатием в Нетбинсе бывало удобно.

Да жаль, но как я уже писал — здесь сделать что-то, что подходит всем будет очень сложно. Лучше найти какое нибудь специализированное решение — "с++ code beautifier" и подсоединить его как внешний инструмент или скрипт. Точно такое уже есть, и точно оно будет мощнее чем решение в HippoEDIT.

_>Да, а мне тут баг встретился — не хочет назначать ассоциации файлов. Ставлю галочки, нажимаю update — окно молча закрывается, но в проводнике никаких изменений... Это потому что бета или нет? )

Это баг. Потому что 1.50 бета. В 1.49 должно работать. Появился недавно, когда я делал рефакторинг для поддержки процесс UAC elevation. В обновлении исправлю. Спасибо.
Re[13]: Нормальный редактор для C++ - существует ли?
От: PSV100  
Дата: 30.03.12 11:17
Оценка:
Здравствуйте, PSV100, Вы писали:

PSV>[...]


В дополнение к предыдущему своему посту...

Я не заметил, что там не вылезла почему-то картинка с багом в окне закладок. Вот прямая ссылка:
http://xmages.net/i/3443320

Похоже, что баг на уровне GUI, что-то с самим контролом/виджетом.

И ещё пару слов. Я вчера кое-что забыл написать, да и замаялся конкретно... И тебе проще порциями разбираться.

— я писал про автокомплит, что неплохо бы курсор вставлять во внутрь скобок. Заметил, что редактор так и делает. Но видел, что так и не делает. Возможно от синтаксиса зависит. В общем, я не понял, это не очень важно, не обращай внимание.

Кстати, об автодополнении. У тебя хороший механизм с хинтами, в какой-то степени, киллер-фича редактора. Но некоторым нравится, например, как работает автокомплит в sublime, кто-то любит жать Esc/Shift-Esc для подстановки, кому-то нужно, чтобы при наборе автоматом добавлялись окончания как выделенный текст и т.д. Плюс настраиваемая игра с регистром: чувствительность при наборе, всегда ли преобразовывать как в источнике, всякий smart-поиск и т.п.
Имхо, в твоём случае, скорее, действительно не нужно распыляться на все варианты (да и здоровья не хватит одного для всего). Так, прежде всего, избалованы пользователи вим/эмакс (да и в JEdit есть всякие варианты), кто как хочет, так и делает. Но приятно...

И я не совсем въехал о всех источниках, откуда берутся данные. Но я особо не разбирался, просто скажу, что неплохо иметь возможность указывать вручную (не только в XML-описании грамматики) список элементов для каждого синтаксиса (например, список своих функций). Также удобно дополнять слова из соседних открытых буферов, но не из всех, а по определенным правилам. Но для этого нужна более удобная организация работы с буферами (как в том же jedit, или вим/эмакс).

Кстати, здесь на форуме ты говорил о мыслях прикрутить ctags — хорошая идея в рамках универсальности. Ещё можно подумать и о cscope и ей подобных — она ещё дает инфу и по зависимостям, кто кого вызывает. Иногда я видел, что для языков, которых не поддерживают эти штуки, составляют списки своих элементов (например, функций, всяких структур) в каком-то псевдо-синтаксисе а-ля С, чтобы ctags их проглотила.

— вроде не работает автокоррекция: светится хинт, но жмешь enter/tab, а эффекта нет.

И неплохо иметь автокоррекцию по пробелу, например, набрал "if", жмёшь пробел и получи "if (|)", т.е. добавили скобки и курсор прыгнул во внутрь. Причём список элементов для коррекции должен быть настраиваемый по синтаксисам.

И коррекция помогает набирать всякие мудрёные символы из юникода, кому нужно (я не пользовался).

И кстати, я не заметил команды временного запрета расширенной обработки клавиш. Например, клацнул Ctrl+Q, затем жмёшь пробел, а коррекция специально не срабатывает, вводится обычный пробел. Или Ctrl+Q, Enter — вводится просто перенос строки, без всякого выравнивания. Удобно, даже необходимо.

— я не разбирался подробно в правилах для синтаксисов в плане их разбора, выравниваний, отступов и т.д. Вроде всё неплохо. Но как-то не заметил всяких "помогалок", типа так: ввел "switch (some_var) {", клацнул enter — новая строка сдвинулась вправо, т.е. добавили пробелов или tab согласно отступу. Затем я набираю "case some_val:" — и строка сдвинулась влево, выровнялась по слову "switch". Т.е. в правилах можно указать, что а для "case" давай двигай мне обратно, причём тогда, когда я введу ":". В общем, посмотри на правила в JEdit, в чём-то они по шире, по удобнее (особенно в рамках всяких скобок). Но у тебя есть свои приятные фишки.
Кстати, в Sublime тоже очень гибкие правила, по наследству от TextMate, но я с ними не разбирался.
А "удобняшки" из коробки меньше нагибают писать макросы/плагины.

— не хватает в GUI для настроек синтаксиса пары важных элементов: указание символов для разделения слов, расширения файлов для синтаксиса, какими символами (скобками, кавычками, и пр.) автообрамлять текст и остальные ключевые элементы, которые реально могут потребоваться для настройки под себя.

— в диалогах не хватает хотя бы каких-то хинтов, которые чуть больше подскажут по опции. Документация сейчас неполная, да и мало кто ее читает. Например, "Easy Line Copy" — я, к примеру, настраиваю у себя копировать всю строку, если нет выделения, но это та же опция или нет, не понятно. Т.е. пользователи могут просто не заметить какие-то киллер-фичи.
Кстати, в sublime, где вся настройка в текстовых файлах, приятно, когда рядом с параметром есть комментарий к нему.

Но я понимаю, какая это муторная работа всё расписать...

— Я упоминал ранее о механизме "Actions" в jedit, что напоминает команды в твоём редакторе. У тебя в редакторе есть понятие "событий" — при старте редактора, при закрытии последнего документа (может что-то ещё). Можно расширить этот виртуальный список событий и дать возможность указывать всякие команды, встроенные, от плагинов, макросы. Это уменьшит потребность в ручном "программировании" редактора. Такой механизм есть в jedit. Например, можно указать, что при переключении на буфер с таким-то синтаксисом чтобы вылазила такая-то панель, или сразу переключиться на другое состояние среды, т.е. перестроить положение буферов/док-панелей (по мотивам перспектив в эклипсе, только работает всё мгновенно, в отличие от эклипса). Или перед тем, как что-то сделать, всё посохранять, что нужно, и т.д. и т.п.

Но нужен ли такой механизм в редакторе а-ля VS — сомнительно...

— заметил неплохую фишку: хинты для констант с цветом. Для эмакса есть классная вещь: rainbow-mode. Включил эту mode (режим) — все цветовые константы в коде выделяются своим цветом — тоже удобно.

— раз уж об эмаксе вспомнили, то рекомендую взглянуть на его org-mode. Это мощный режим для ведения всяких своих документов, списков данных и пр., где нужна структурированность данных, рисование таблиц, переходы на документы и т.д. Функционал огромный, лично я всего не знаю и пользовался этим mode мало. Но это реальная киллер-фича. Многие эмаксом пользуются только из-за неё, не для программирования. Потом и его почтовиком начинают пользоваться, HTML пописывать, и пошло и поехало...
Есть некая эмуляция, естественно, для вима, для JEdit я видел небольшой наборчик макросов. А во многих простых редакторах (и их пользователи) даже и не знают о таком функционале. Конечно, реализовать весь потенциал весьма проблематично, но базовые вещи можно — это хорошее завлекалово юзеров.


И о киллер-фичах. Есть небольшая просьба, чтобы ты намекнул, на что можно обратить внимание, по твоему мнению (т.е. чем можешь похвастаться ), кроме того, что естественно бросается в глаза. Сайт смотрел, но там нет всех нюансов, типа того же Virtual Space (что за штука ?). Думаю, просьба понятна.

Вроде всё, что хотел сказать. Больше нет сил и времени.
Re[13]: Нормальный редактор для C++ - существует ли?
От: PSV100  
Дата: 30.03.12 11:45
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Kefir, Вы писали:


K>>Не найдете


_>Ммм, жаль) Хотя для своих кодов я такую функцию никогда и не использовал. А вот чужие привести в привычный вид одним нажатием в Нетбинсе бывало удобно.


Поддержу товарища Kefir. Лучше пройтись каким нибудь AStyle.

В JEdit есть плагин, который может форматировать. Имеет гибкие настройки (через GUI, кстати) вокруг стандартных правил для разбора синтаксиса, но для ряда популярных языков всё-равно задействованы специальные парсеры, и свои специфичные настройки. Хотя через его универсальный механизм мы можем неплохо форматнуть наш DSL, например, но толком этим никто не пользуется (просто потому, что особо не нужно). Но с другой стороны, если нет внешнего инструмента, который можно подогнать под свои нужды, такие плагины весьма полезны, в ряде редакторов их нет.
Re[13]: Нормальный редактор для C++ - существует ли?
От: Kefir http://www.hippoedit.com
Дата: 31.03.12 23:47
Оценка:
Здравствуйте, PSV100, Вы писали:

PSV>Почему так получилось. Я когда-то разрабатывал типа встроенной IDE для продукта (бизнес-система), поверх SynEdit для Delphi (имхо, ты в курсе). После этого у меня в голове постоянно мысли как сделать нормальный удобный редактор, и есть тайные желания забабахать свой проект (какой же нормальный программист не мечтает о своём языке программирования (и языки приходилось делать) и о своём редакторе ? ). А тут и тема форума такая привлекла, и ты "за живое" задел...

Да, конечно, SynEdit я знаю — на нем много чего сделано. Это альтернатива Scintilla для дельфистов. Но насколько я помню, он уже давно не развивался, в отличии от Scintilla.
Я когда начинал редактор писать (как редактор для некоего проприетарного языка одной большой компании), то честно говоря, Scintilla не нашел, поэтому пришлось писать все самому. Хотя база была, CrystalEdit исходник с CodeProject. Но сейчас от него мало что осталось. Может было бы тогда больше опыта, получилось бы лучше и быстрее, но его не было . Сейчас бы наверное писал мультиплатформенно, на Qt. Хранение данных бы по другому реализовал и тд.
А у тебя, если желание есть — присоединяйся. Много вариантов сотрудничества есть

PSV>Ну почему же, у меня язык не поворачивается назвать "бегемот", как раз "бегемотик", и иконка в тему. Имхо, и "буржуи" вполне адекватны.

Кто как. Один из примеров.

PSV>Здесь я много говорил о JEdit, ибо его "вкурил", и о Sublime. Я не фанат ни всяких редакторов/IDE, ни языков программирования и пр. JEdit имеет GUI-направленность, но по духу близок к эмакс, с хорошим функционалом. В Sublime, как у потомка TextMate, хорошая функциональность для операций с текстом, что сейчас пытаются перетянуть во многие редакторы, включая и в вим/эмакс. К тому же, у него есть неплохие попытки найти компромисс между GUI/Text-направленностью, работа без модальных диалогов (что уже начинают применять и всякие IDE, типа QtCreator), конфигурация только на основе текста (кстати JSON вместо XML), и пр. Я думаю, что ты сам всё прекрасно знаешь и меня правильно понимаешь.

Ну не знаю, тут дело, мне кажется не в модальных диалогах, а просто в общем удобстве. Если удобно, понятно и не перегружено — зашибись. А только текстовые установки — это тоже не очень хорошо для первичного освоения. Нет вспомогательных инструментов как то: выбор файлов, цветов, дат и тд; нельзя управлять связанными данными и многое другое. Текстовые установки просто проще для разработчика.
JSON или XML разницы нет. Просто когда я начинал json был не так распространен, а корпоративным был xml.

K>>...Был еще неплохой редактор такого плана Intype, но он умер.

PSV>Есть ещё "E-Editor", но Sublime всех задавил.
E-TextEditor похоже тоже "умер". Ушел в OpenSource и давно не обновлялся. Его уникальная фича, как раз была навороченная история undo с визуализацией ветвлений.

K>>...Jedit мне не понравился — тяжеловат, но интеграция плагинов сделана хорошо.

PSV>Да, те, кому больше NotePad++ и не нужно, на него и не посмотрят. Сама жаба всех отпугивает, особенно на фоне эклипсов/нетбинсов/идеи. Но работает он шустро, по умолчанию он настроен для работы с памятью чуть с запасом (но гораздо меньше всяких хромов с лисами). Я экспериментировал с настройками и заставлял бегать под несколькими десятками мб, и ничего, нормально, GC чаще срабатывает конечно, но тормозов нет, это не сервер приложений. Есть возможность запустить "сервер" как в эмаксе, файлы из фара по Alt-F4 открываются мгновенно. Причём огромные файлы (например, лог) даже с подсветкой JEdit открывает быстрее всех.
Поставил сейчас — попробовал. С настройками из коробки, он отказался открывать 170 мб лог и потом завис когда я открыл файл с очень длинной строкой (9мб). Это я думаю проблемы java. Я понимаю что для маленьких файлов он работает шустро, но я бы, как пользователь, хотел решение что работает для всех сценариев (понятно что в разумных пределах).

PSV>Кстати, я обратил внимание, что в его декларациях для всяких правил разбора далеко не всегда указываются регулярные выражения, в отличие от многих редакторов, где всё на сплошных регулярках. Например, указывают типа так: это ключевое слово должно быть только со значимого начала строки, т.е. игнорируем все ведущие пробелы и пр. Скорее всего, это тоже сказывается на перфомансе.

У меня регулярки сейчас используются только для поиска так называемых меток (асинхронно). Правила разбора / движок свой (работает в основном синхронно). Руглярные выражения были в 10 раз медленней, даже на тех же сценариях (пробовал boost). Хотя скорее всего придется вводить и их поддержку, потому как мои правила все же сильно ограниченны и не позволяют покрыть все случаи.

PSV>И ещё про JEdit. У него есть ряд концепций, которые могут нормально вписаться в твой редактор, тем более, как я понимаю, уже ведётся неслабый рефакторинг в проекте:

Рефакторинг ведется всегда Сейчас у меня процесс завершения 1.50. Остался один баг (но серьезный) с многострочным поиском и подключение онлайнового функционала. Потом релиз. Так что серьезные вещи я сейчас уже начинать не хочу. И так 1.50 уже делается 2 года.

PSV>- да, у него хорошо сделана работа с плагинами и макросами, что-то удобнее и не нужно. Нормальная логика в организации меню: удобно, когда всё, что касается плагинов, находится в одном месте — пункт "Plugins" в главном меню (и Macros ещё), остальные пункты — типа стандартные функции редактора. Так проще и быстрее разобраться в функционале. Кому нужно, можно организовать изменяющееся меню в зависимости от текущего языка (или mode, т.е. синтаксиса), больше это актуально для popup-меню внутри панели с текстом. Я, например, добавил себе в главное меню (т.е. в самый верхний уровень) всяких своих пунктов — повыносил себе нужные мне действия — так быстрее было освоить состав функционала. Самим меню пользуюсь редко, и всякие тулбары с кнопками поотключал.

Здесь у меня другое отношение. В HE у плагина те же права, что и встроенного функционала. Он может расширять функционал там где считает нужным, чтоб органически вписаться в существующую организацию. Может добавить пункт в меню редактирования, или добавить свое главное меню. Расширить стандартный тудбар или добавить свой. Переписать стандартную команду.
Это была основная идея бесшовной интеграции, так как я планирую и сам расширять функционал далее в виде плагинов.
Ограничение по положению есть только у внешних инструментов и контекстной помощи.

PSV>- есть виртуальное понятие команд: Action. У тебя вроде тоже есть какие-то команды. Но они у тебя не удобно показываются. Лучше CamelCase светить так: "Very Long Command", особенно в каких-то списках. Так делает Sublime. В jedit также есть возможность с ними работать в эмакс-стиле, т.е. как с лисп-идентификаторами: very-long-command.

Мне уйти от текущего формата будет уже тяжело, потому как так записаны шоткаты в пользовательских схемах. Да и большой проблемы в формате не вижу. Поиск будет работать и так и так. Может только если делать какие command bars.

PSV>- есть удобная запускалка команд. Не помешала бы она в дополнение к твоим всяким вылетающим хинтам по командам и клавишам (кстати, здесь CamelCase лучше из-за множества столбцов). Есть команд-бар: клацнул — вылезла панелька типа твоего Quick Search, набрал пару букв, можно tab клацнуть — автодополнение (но в jedit нормального дополнения здесь не хватает), короче ввёл команду или имя макроса (!) — enter и выполнили. А если набираешь не буквы, а цифры — значит будем повторять действия, например, ввел 16 и клацнул пробел — вставили 16 пробелов, ввел 18 и left — перелетели на 18 левее.

PSV>Это удобно и избавляет от многих шорткатов.
Да. У меня в планах есть. Про повторение еще не думал — запишу. В Sublime вроде неплохо было сделано.

PSV>- есть возможность на основе XML создать свои простые диалоги, без программирования. Например, сделать форму для настройки параметров перед запуском какой-нибудь тулсы (это плагин Console). Я так понимаю, ты работаешь сейчас над этим вопросом.

Да у меня очень неплохо сделано. С data binding, layout и поддержкой property pages. Там есть в примерах скриптов.

PSV>Сейчас в эмаксе бывшую клавишу Meta эмулируют обычно через Alt или Esc.

PSV>А я имел в виду следующее. Заводим виртуальную клавишу, скажем, Ext. Определяем, что ее можно эмулировать так: "Ctrl+E" или "Ctrl-K". Назначаем шорткаты для команд вида: "Ext a s", "Ext i p". Теперь я могу вызвать команду так: "Ctrl+E", затем "a" и "s" или "Ctrl+K, a, s" — запустится та же команда. Но мне удобнее Ctrl жать правой, а "E" и клавиши с ней рядом — левой. Когда нужно клацать в районе "K" — удобнее правой это делать, соответственно Ctrl в это время удобнее клацать левой. Поэтому, когда хочу, жму Ctrl+E плюс остальное, а хочу — жму Ctrl+K плюс это же остальное. Думаю, что понятно.
PSV>При этом такая схема вместе с шорткатами вида "Ctrl+E A S" позволяют создавать много шорткатов (причём с логикой) и удобных, вместо неудобных для меня Ctrl+Alt, или когда пальцы можно сломать от четырёх одновременных нажатий, а то и более.
Теперь понял. Себе записал. Может оно и удобно, но у меня пока еще не просили. Скорее всего сказывается специфика пользователей, которые про это и не знают. Для часто используемых назначают обычные шоткаты, а редкие вызывают из меню.

PSV>Имхо, и не попросят. Так, например, любят делать любители вима: при их способе работы им удобнее не тянуться мизинцем к Ctrl, а клацать CapsLock. Часто и к Esc не тянутся, жмут Ctrl/CapsLock + [.

PSV>Если будет эмулятор вима (а ведь могут потребовать после Sublime ), может пригодиться.
Ну тогда и буду разбираться, я не собираюсь имплементировать все мыслимые команды и стили ввода. Редактор — это отражение моего мировоззрения на удобный инструмент + продающие фичи. Не думаю что это будет продающая фича.
Работы может и немного, но редактор по любому усложнит.

PSV>>>- вроде заявлена фича для автоматического обрамления скобками, но как-то не до конца проработанная. Например, не всегда работают кавычки (скорее, это где-то настраивается, чем обрамлять).

K>>Да это языково, контекстно зависимо.
PSV>Я так и думал. Для txt можно вместе с одинарными кавычками добавить и двойные по умолчанию.
Да, я добавил в схему. Хотя, по моему как раз ' там быть не должно. Из-за всяких Mc'Donalds или can't. Но может я там че-то уж поправил (вроде как).

PSV>Можно попробовать просто вставлять курсор внутри скобок, если они есть. Хотя, это мелочи.

Да, в принципе там можно кое что улучшить. Хотя я чего-то сценария не понял. Попробовал — у меня во многих случаях вставляет (есть паттерн в схеме для вставки функций). Но не сработает, если функция была собрана как просто символ а не как метка или загруженная из словаря. Те где то в тексте есть foo() * 3; но определения foo в текущем файле нет. А потом, когда редактор подсказывает foo, он не знает что это функция, ну и () не вставляет.

K>>Оно есть — называется Code Templates. Языково (синтакс) специфично. Можно поискать в Tools->Options.

PSV>Я как-то не заметил, есть ли там позиции/переменные, где можно быстро прыгать по tab, групповой ввод и пр., т.е. всё то, что вытворяет Sublime, например. Реально удобно.
Да, позиций пока нет. Это у меня в планах. Но придет вместе с множественным выделением.

PSV>Кстати, а историю undo я даже не заметил: ее нет в главном меню, а на всякие кнопки я по привычке уже не смотрю (хотя сам когда-то такие же undo-кнопки делал). Имхо, важный момент...

Ну ее по любому надо выводить в popup окне, для множественной отмены. Такой тип представления, посмотрите продукты от MS. И у них тоже нет отдельного пункта меню вроде. Так что думаю Windows пользователи найдут если надо.

PSV>>>- там же слева, где номера строк, неплохо подсвечивать область вместе с выделением скобочек. т.е. когда выделяются парные скобки (или другие элементы) и они на разных строках, то слева светится индикатор, как это делает JEdit.

K>>Да можно, но будет конфликтовать с подсветкой текущей области видимости. Я подумаю, может есть какой вариант, но большой надобности не вижу.
PSV>Это действительно не супер-важно. Просто, наверное, я к нему привык. Иногда помогает, когда сразу не видно, где светится парный элемент.
PSV>А вообще-то, в jedit сделано так, что он там никому не мешает. У тебя, кстати, удобно хинт светится для подсказки конца блока.
PSV>И по поводу выделений слева. Конечно хорошо, когда можно много чего выделять. В jedit есть ещё фича для закладок выделять номера строк вместо иконок, а также выделять номера через определенные позиции, и пр. Но как всё удобно сделать — я сам не знаю.
А запустить jEdit после падения я так и не смог... Он постоянно загружает файл на котором упал и виснет. Даже с полным uninstall и re-install. (нашел таки потом его перспективу — удалил — загрузился, хотя осадочек остался ).
У меня там тоже было много конфигураций по выделению/отображению левой границы. Кое что настраивается xml флагами, кое что зависит от того какие области отключены, тогда информация с отключенных областей переносится на панель номеров строк.

PSV>>>- Пробелы, концы строк, табы можно выделять через точечки, но не по средине строки, а внизу, как обычные точки, только дать им другие цвета, как это делает jedit. Тогда эти символы будут не бросаться в глаза, при этом можно включить их постоянный вывод и смотреть на них не только при выделении текста.

K>>Ну их можно и так включить View->Editor->White Space + Trailing White Space (поискать в Options), и задать для них то цвет что хочешь (или увеличить прозрачность). Только надо обратить внимание на установки Contrast Ratio (options -> search "contrast"), они могут не позволить не контрастные сочетания.
PSV>Понятно. Только вот эти параграфы, или как эти символы обзываются для конца строк а-ля Word (это очень распространено), как-то громоздки. В jedit светится точечка в конце строк, обычно оранжевая по умолчанию, она и в глаза не бросается, и заметна, когда специально посмотришь.
Ну тут можно возразить, что тогда просто пробел тяжело отличить от конца строки. У меня так показывает если нет смешанных терминаторов строк (те все CRLF или LF и тд). Если терминаторы разные, то будет показываться конкретные значения для каждой строки (как Notepad++). Тоже гда то настраивается.

PSV>>>- не хватает опции, чтобы концевые пробелы обрубались сразу по ходу дела, а не только при сохранении.

K>>Ну не знаю. Плагин?
PSV>Ну я не в курсе, плагин или нет. Многие IDE для паскаля, как Delphi, делают это всегда по умолчанию, и вроде всё нормально, удобно. А вот во многих редакторах/IDE, особенно тех, кто под впечатлением от VS, этого нет. Почему — хз. Но это неважно.
Ну потому как, по мне это и не важно пока не сохранено. Для тех кого это волнует, есть режим Show trailing spaces. Но обрезать их все придется или плагином или внешним инструментом.

PSV>А в jedit сделано очень грамотно переключение выделений: "Ctrl-\" — включает/отключает множественное выделение, "Alt-\" — управляет выделением по столбцам. Не нужно жать всякие Alt-Shift-... Также почитай, как выделяется мышкой, и про её прочие функции (хотя я лично мышкой фактически не пользуюсь, даже не помню, как ее вертеть надо для выделения). Всё очень удобно.

PSV>Можно ещё переключатели добавить в строку статуса. Также реально полезно обычное выделение и множественное выделять разными цветами.
Да можно делать по переключателю. У меня уже это все есть (Edit->Selection->Stream/Column/Line) и статус бар индикатор есть.
Про цвет, да тоже можно.

PSV>>>И ещё по выделению. Вроде заявлен способ перемещения через выделение, когда, например, выделили блок, курсор на его правой границе, нажали влево — перелетели на его начало, но нажатие вверх почему то работает как обычно.

K>>Не, вроде не заявлен Или я че-то что запрограммировал забыл
PSV>А-а, понятно. Реально удобно использовать выделения не только для правки. Вот выше я давал шорткаты: "Ctrl+E a s" — выделить всё предложение, вместе с концевыми пробелами, или "Ctrl+K i p" — выделить содержательную часть параграфа, т.е. без хвостовых пробелов и пустых строк после него (вот кстати и логика в шорткатах: a — от "a object", i — от "in object", p — параграф и т.д., что упрощает запоминание), или "Ctrl+K i ' " — выделить всё внутри кавычек, но без самих кавычек. После выделения клацнул влево, вверх — перелетел в начало и т.д.
Попробуй Edit->Selection->Expand/Shrink с множественным повтором. Тебе понравится

PSV>Кстати, в редакторе я не заметил выделений текстовых объектов. Полезны переходы типа вперёд/назад по параграфам и пр., выше по фолд-уровню и пр. Но, имхо, действительно это всё всем не нужно.

Переход/выделение по параграфам есть. Просто не в меню. Поищите в списке команд Paragraph. Прыжки по блока тоже есть. Фильтруй в командах по Scope.

PSV>>>- у вас вроде неплохой набор функций вокруг буфера обмена. В JEdit-е есть ещё неплохая штука — он хранит историю удаленных элементов, которые не кидались в буфер обмена, и можно делать вставки оттуда.

K>>Записал себе. Хотя в не убежден в надобности подобной функции. на крайняк можно сделать поиском через Undo больших, удаленных кусков. Чтоб новое хранилище не заводить.
PSV>Да, в целом. Лично мне редко помогало, но иногда здорово. А в undo-истории нельзя выдрать кусок без восстановления всего предыдущего (хотя может и можно ?).
Можно. Но надо будет дополнительную команду писать, работы немного. Сейчас пока нельзя.

PSV>Кстати, вроде в виме очень крутое какое-то дерево для undo, но как с ним работать, я быстро не разобрался, а потом забил.

Есть и в e-texteditor — его киллер фича. Но если даже ты не разобрался — кому оно надо

K>>С пустой строкой в начале списка — похоже на баг, но воспроизвести не смог. С переходом — это новый баг. Поправлю. Букмарки, базированны на линиях. Можно конечно добавить и колонку, но похоже народу это не надо.

PSV>Вот картинка:
PSV>
Да, это баг контрола. Я думал уже пофиксил, но похоже опять всплыло. Чего-то переоптимизировал.

PSV>>>- в редакторе весьма гибкий поиск, но вроде нет возможности искать/заменять многострочные выражения.

K>>Поиск с регулярными выражениями. Просто вставьте многострочный текст в диалоге поиска Ctrl + F (не поддерживается в QuickSearch Bar -> Ctrl + Q).
PSV>Понятно. В том же jedit есть поля для многострочного ввода. В других редакторах иногда жмёшь Ctrl+Enter — и поле расширилось на две строки или более.
Проблема многострочных полей ввода — тяжело показать историю запросов (поэтому у меня поле ввода и сделано как выпадающий список). Но принципе можно использовать трюк с Ctrl+Enter и заменять контрол на месте. Запишу себе.

PSV>>>В jedit-е есть классная штука: замена текста на результат работы макро-кода. Удобно, иногда избавляет от написания макроса или внешнего скрипта/утилиты.

K>>Думаю это усложнение. Можно написать стандартный скрипт для всех.
PSV>Можно и скрипт. Но, например, можно задать какую-то регулярку, чего-то понаходить и конвертнуть в нижний регистр, указав в поиске для замены выражение "_0.toLowerCase()". Быстро, просто, удобно.
Да, но думается мне это не для всех С таким же успехом, можно и в command bar написать : findAll("dodo").toLowerCase(). Или чего-нибудь подобное. Усложнять диалог поиска, я думаю идея плохая. Он и так уже слишком сложен.

K>>Есть поддержка регионов — те можно для любого синтаксиса задавать области для свертки в тегах форматирования (в принципе в комментариях чтоб не тревожить компилятор).

PSV>Я с фолдингом в последнее время тоже мало вожусь. Но частенько приятно, когда правила для фолдинга составлены грамотно, например, для своего DSL, и клацнул, скажем, сверни до 2-го уровня: получи список структур или функций, и т.п. В sublime есть свертки вида "сверни все атрибуты в тегах", тоже облегчает.
Ну сверни все аттрибуты в тегах — это языко-специфично. не будет. Но есть Collapse to Definition, Collapse Comments, Collapse all same blocks... Посмотрите контекстное меню, Outlining. Зависит от синтаксиса.

PSV>>>Не хватает виртуального вырезания кода, т.е. временного отбрасывания лишнего, как механизм Narrow в JEdit.

K>>Не уверен что оно надо. У меня есть другие идеи на этот счет, так что я скорее всего пойду в другом направлении.
PSV>Согласен, что этот Narrow не идеал. А какие идеи, если не секрет, конечно ?
Идея навеяна CodeBubles. Я хочу уйти от понятия файла а перейти к представлениям которые отражают задачу. Такой себе составной документ из разных кусков кода этого или других документов отобранных по заданным пользователям тегам. С поддержкой редактирования конечно. Например чтобы определение и имлементация функции были в одном месте, или функции для работы с текстом, в независимости от реального расположения обрабатывались вместе.
Это + множественные выделения у меня приоритетные задачи на следующие версии.

K>>В HippoEDIT есть как макро последовательности, так и поддержка скриптинга на базе Active Scripting (см выше). Зачем надо было и то и другое здесь.

PSV>Ясно, а много языков реально востребовано ? Ведь усложняет процесс...
PSV>В jedit есть плагин, с которым можно програмлять на чём угодно, но как-то он особо никому не нужен...
ну по умолчанию у всех есть JS + Vbscript. А так есть движки для Perl, PHP, Lua.

PSV>>>Также хотелось бы предложить для редактора такие фичи:

PSV>>>- список ошибок. Сейчас в редакторе ошибки светятся чёрточками справа от текстовой панели. Не мешало бы их вывести отдельным списком, да и внутри кода подчеркнуть при необходимости. Но, возможно есть проблема, что парсеры в редакторе не дают подробного описания ошибки и не объясняют, чем им "красное" место не нравится.
K>>Да парсер не знает что он показывает Обычно это просто ошибки, определенные на основе схемы (не закрытые скобки, scopes и тд). Думаю что подсветка на Overview Bar достаточна. А детальные сообщения можно отдать внешним инструментам и плагинам.
PSV>Я так и думал. А вот такие подсветки как в Overview Bar, как-то они, лично для меня, не очень информативны. Удобнее, когда есть явный их список и в коде все подсвечивается. Но в Jedit, да, работают спец-парсеры для этого.
Ну да, для ошибок это не очень подходит. Тут лучше список. Но для показа количества совпадений слова в документе, измененных зон, вложенных синтаксисов или наличие туду — подходит нормально. Можно использовать как индикатор ошибок в логе, создав стиль подсвечивающий сообщение об ошибке и вывести его на Overview Bar.

PSV>>>- модные ныне minimap-ы. В основном, баловство, но иногда приятны, особенно когда можно чуть увеличить и видны всякие подчёркивания и выделения. Им не хватает какого-нибудь hint-а: под мышкой чтобы вылазило окошко с увеличенной информацией.

PSV>Тут только одна мотивация для тебя — привлечение юзверов, многие просто кайфуют, и всё. Но работы до хрена...
Там работы в принципе не много. У меня уже все разделено и подготовлено. Единственно могут быть проблемы с производительностью, если показывать большой документ. Но вроде там всего пару экранов вводиться так что может будет нормально.

PSV>>>- что может выводить Overview Bar (только чёрточки типа для ошибок ?);

K>>Он много что показывает.
PSV>Понятно. Я думал, что может кроме чёрточек вдруг какие-то диаграммы вылазят, к примеру.
Нет — диаграмм нет Это в принципе стандартный вид отображения (Resharper, Chrome).

PSV>>>Virtual Space

K>>Если хочется писать где хочешь, а не только в границах строки.
PSV>А можно в двух словах подробнее, или скриншот, если есть.
Скриншот тут сильно не поможет, но я нашел пару описаний в интернете, чтоб заново не писать: MSDN или StackOverflow. Искать в гугле "virtual spaces text editor".

PSV>И ещё одно предложение. Для вима есть неплохие скрипты для быстрого перемещения по тексту в стиле вимператора для firefox, как EasyMotion. Но я бы сделал чуть по-другому. Подробно помечал бы слова внутри какой-то лексической области, например, функции, а в остальном помечал бы только начало функций — меньше шума, можно перейти как бы в 2 этапа, и быстро, если все удобно сделать.

PSV>В общем, думаю, что идея понятна.
Да я посмотрел — идея в принципе интересная. Записал себе. Хотя не знаю как она приживется в GUI редакторе. Сначала думал: как же это они делают в большом документе. А потом понял, что это только для видимой области. В этом случае, твое предложение по переходу по функциям кажется мне не очень полезным — сколько будет функций за раз видно на экране? ну и у меня уже есть достаточно удобная навигация по меткам (функциям) с помощью Navigation Bar: Alt+M -> набрать часть имени функции -> Enter.

PSV>P.S. Блин, опять простыня. Писал весь день в твоем редакторе, с "перерывами на работу". Сорри...

И ты на этом не остановился
Re[14]: Нормальный редактор для C++ - существует ли?
От: Kefir http://www.hippoedit.com
Дата: 01.04.12 00:56
Оценка:
Здравствуйте, PSV100, Вы писали:

PSV>Кстати, об автодополнении. У тебя хороший механизм с хинтами, в какой-то степени, киллер-фича редактора. Но некоторым нравится, например, как работает автокомплит в sublime, кто-то любит жать Esc/Shift-Esc для подстановки, кому-то нужно, чтобы при наборе автоматом добавлялись окончания как выделенный текст и т.д. Плюс настраиваемая игра с регистром: чувствительность при наборе, всегда ли преобразовывать как в источнике, всякий smart-поиск и т.п.

smart-поиск я еще приделаю: поиск по акронимам, нечеткий поиск.
Case я уже сейчас отслеживаю, и вставляю так как было набрано или как определено в свойствах (если позволено для синтаксиса).
Подстановка in-place — мне не нравиться — это от бедности GUI функционала.

PSV>И я не совсем въехал о всех источниках, откуда берутся данные. Но я особо не разбирался, просто скажу, что неплохо иметь возможность указывать вручную (не только в XML-описании грамматики) список элементов для каждого синтаксиса (например, список своих функций). Также удобно дополнять слова из соседних открытых буферов, но не из всех, а по определенным правилам. Но для этого нужна более удобная организация работы с буферами (как в том же jedit, или вим/эмакс).

Про пользовательские списки у меня уже в планах есть, но пока не приоритетно. Дополнение из других буферов... Это все не точно, и может принести больше проблем чем пользы. Лучше уж тогда прикрутить ctags или разбирать инклуды для синтаксиса. Но можно будет посмотреть.

PSV>Кстати, здесь на форуме ты говорил о мыслях прикрутить ctags — хорошая идея в рамках универсальности. Ещё можно подумать и о cscope и ей подобных — она ещё дает инфу и по зависимостям, кто кого вызывает. Иногда я видел, что для языков, которых не поддерживают эти штуки, составляют списки своих элементов (например, функций, всяких структур) в каком-то псевдо-синтаксисе а-ля С, чтобы ctags их проглотила.

Да — согласен В планах есть.

PSV>- вроде не работает автокоррекция: светится хинт, но жмешь enter/tab, а эффекта нет.

Это баг. Тоже воспроизвел. Поправлю. В 1.49 работает.

PSV>И неплохо иметь автокоррекцию по пробелу, например, набрал "if", жмёшь пробел и получи "if (|)", т.е. добавили скобки и курсор прыгнул во внутрь. Причём список элементов для коррекции должен быть настраиваемый по синтаксисам.

Ну это CodeTemplates, они зависимы от синтаксиса. А чтоб сработало на пробел, надо его установить как шоткат для Edit.ExpandTemplate. Я помню я там делал специальный хак, чтоб оно потом не ело пробелы, если был набран не имя шаблона. Но я думаю, вариант с Code Hint + Enter если есть шаблон интуитивнее и более стабилен.

PSV>И коррекция помогает набирать всякие мудрёные символы из юникода, кому нужно (я не пользовался).

ну автокоррекция есть, можно добавить что хочешь. Или как темплейт.

PSV>И кстати, я не заметил команды временного запрета расширенной обработки клавиш. Например, клацнул Ctrl+Q, затем жмёшь пробел, а коррекция специально не срабатывает, вводится обычный пробел. Или Ctrl+Q, Enter — вводится просто перенос строки, без всякого выравнивания. Удобно, даже необходимо.

Ну это не запрет расширенной обработки клавиш, но запрет форматирования, в случае HE. Да, можно сделать. Тем более у меня такой режим уже есть, но не виден в UI. Он активируется при записи макросов.

PSV>- я не разбирался подробно в правилах для синтаксисов в плане их разбора, выравниваний, отступов и т.д. Вроде всё неплохо. Но как-то не заметил всяких "помогалок", типа так: ввел "switch (some_var) {", клацнул enter — новая строка сдвинулась вправо, т.е. добавили пробелов или tab согласно отступу. Затем я набираю "case some_val:" — и строка сдвинулась влево, выровнялась по слову "switch". Т.е. в правилах можно указать, что а для "case" давай двигай мне обратно, причём тогда, когда я введу ":". В общем, посмотри на правила в JEdit, в чём-то они по шире, по удобнее (особенно в рамках всяких скобок). Но у тебя есть свои приятные фишки.

PSV>Кстати, в Sublime тоже очень гибкие правила, по наследству от TextMate, но я с ними не разбирался.
PSV>А "удобняшки" из коробки меньше нагибают писать макросы/плагины.
Ну у меня много чего есть, в плане автоматических отступов или положения табов, но конкретно уменьшения отступа по : для с++ нет. Есть уменьшение отступа по закрытию scope ( } ). О расширенном варианте с : я конечно думал, но решил пока не делать (в планах есть) — мне нужно универсальный движок, с поддержкой любы синтаксисов, а сделать его быстро не получиться. Но скорее всего буду делать базируясь на правилах описанных в регулярных выражениях.

PSV>- не хватает в GUI для настроек синтаксиса пары важных элементов: указание символов для разделения слов, расширения файлов для синтаксиса, какими символами (скобками, кавычками, и пр.) автообрамлять текст и остальные ключевые элементы, которые реально могут потребоваться для настройки под себя.

Расширения есть. Options->Synatx Settings->Syntax->Miscalenious->File Pattern. Остального в UI не планирую. Под себя проще настроить схему как файл . Скопировав, или наследуясь от стандартной.

PSV>- в диалогах не хватает хотя бы каких-то хинтов, которые чуть больше подскажут по опции. Документация сейчас неполная, да и мало кто ее читает. Например, "Easy Line Copy" — я, к примеру, настраиваю у себя копировать всю строку, если нет выделения, но это та же опция или нет, не понятно. Т.е. пользователи могут просто не заметить какие-то киллер-фичи.

PSV>Кстати, в sublime, где вся настройка в текстовых файлах, приятно, когда рядом с параметром есть комментарий к нему.
Плохо искал. Символ вопроса (?) в системном меню диалога и клик на интересующий контрол или Ctrl+F1.

PSV>- Я упоминал ранее о механизме "Actions" в jedit, что напоминает команды в твоём редакторе. У тебя в редакторе есть понятие "событий" — при старте редактора, при закрытии последнего документа (может что-то ещё). Можно расширить этот виртуальный список событий и дать возможность указывать всякие команды, встроенные, от плагинов, макросы. Это уменьшит потребность в ручном "программировании" редактора. Такой механизм есть в jedit. Например, можно указать, что при переключении на буфер с таким-то синтаксисом чтобы вылазила такая-то панель, или сразу переключиться на другое состояние среды, т.е. перестроить положение буферов/док-панелей (по мотивам перспектив в эклипсе, только работает всё мгновенно, в отличие от эклипса). Или перед тем, как что-то сделать, всё посохранять, что нужно, и т.д. и т.п.

Я думаю проще все же написать скрипт. Все варианты и комбинации все равно не учтешь. Плюс проблема прикрепления нескольких комманд. События в HippoEDIT — это артефакт Надо бы их убрать, но у меня пока что на них кое что завязано.

PSV>- заметил неплохую фишку: хинты для констант с цветом. Для эмакса есть классная вещь: rainbow-mode. Включил эту mode (режим) — все цветовые константы в коде выделяются своим цветом — тоже удобно.

Да, у меня уже есть в идеях, от одного фаната емакс. Там же отображением стилем для bold/italic и тд. Но интересно, что будет если цвет совпадает с цветом фона ну и у меня еще поправляется контрастность для цвета текста, так что может быть точного совпадения.

PSV>- раз уж об эмаксе вспомнили, то рекомендую взглянуть на его org-mode. Это мощный режим для ведения всяких своих документов, списков данных и пр., где нужна структурированность данных, рисование таблиц, переходы на документы и т.д. Функционал огромный, лично я всего не знаю и пользовался этим mode мало. Но это реальная киллер-фича. Многие эмаксом пользуются только из-за неё, не для программирования. Потом и его почтовиком начинают пользоваться, HTML пописывать, и пошло и поехало...

PSV>Есть некая эмуляция, естественно, для вима, для JEdit я видел небольшой наборчик макросов. А во многих простых редакторах (и их пользователи) даже и не знают о таком функционале. Конечно, реализовать весь потенциал весьма проблематично, но базовые вещи можно — это хорошее завлекалово юзеров.
Нет Редактор, это редактор. А органайзер — это органайзер Те кому нужен органайзер — купят специализированный продукт. А другие будут пользоваться бесплатным емакс.

PSV>И о киллер-фичах. Есть небольшая просьба, чтобы ты намекнул, на что можно обратить внимание, по твоему мнению (т.е. чем можешь похвастаться ), кроме того, что естественно бросается в глаза. Сайт смотрел, но там нет всех нюансов, типа того же Virtual Space (что за штука ?). Думаю, просьба понятна.

Фиг его знает. Фич много уже сделано за все время. Про Virtual Space я уже тебе написал.
Можешь глянуть новое, что появилось в 1.50:
— Virtual Folders в проекте (динамические фильтры на файловую систему)
— colored indent guides / braces. Ну видел, вложение скобок (разных) отражается цветом. Попробуй это (((((((((((()))))))))).
— Еще могут быть интересны аннотации закрытия блоков (Options->Editor->Display). Надо смотреть на больших функциях.
— Scope exits. Сделано на метках, наверное видел как помечаются return/break.
— Организацию диалога поиска Ctrl+F и Find All результаты.
— Произвольные выделения текста (на тулбаре). Сохраняются между сессиями.
— Smart Highlight.
— тут в принципе можно посмотреть список http://forum.hippoedit.com/beta-version-test/alpha-1-50/

PSV>Вроде всё, что хотел сказать. Больше нет сил и времени.

Не поверишь Отпишись в личку: можно будет поговорить/переписываться по skype или email. Так возможно будет быстрее.
А то как то здесь наши обсуждения как оффтопик выходят.
Re[10]: Нормальный редактор для C++ - существует ли?
От: _NN_ www.nemerleweb.com
Дата: 02.04.12 11:38
Оценка:
Здравствуйте, Аноним, Вы писали:

<skip/>

http://www.wholetomato.com/forum/forum.asp?FORUM_ID=13
Вы им напишите об этом, они и исправят.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[14]: Нормальный редактор для C++ - существует ли?
От: PSV100  
Дата: 03.04.12 13:05
Оценка:
Здравствуйте, Kefir, Вы писали:

K>Да, конечно, SynEdit я знаю — на нем много чего сделано. Это альтернатива Scintilla для дельфистов. Но насколько я помню, он уже давно не развивался, в отличии от Scintilla.

Да, в целом сам проект SynEdit фактически не развивают (но я его давно смотрел), есть всякие альтернативные его ветки. А так, кому нужно, в основном, берут его основу и правят не слабо под свои потребности.

K>А у тебя, если желание есть — присоединяйся. Много вариантов сотрудничества есть

Спасибо, но пока возможностей нет, не хватит ресурсов. Но всё может быть, вдруг...

PSV>>Ну почему же, у меня язык не поворачивается назвать "бегемот", как раз "бегемотик", и иконка в тему. Имхо, и "буржуи" вполне адекватны.

K>Кто как. Один из примеров.
М-да ..., идиотская тяга к животным в названиях у них прослеживается давно. Но, имхо, главное не встрять с вопросами расовой проблемы, типа не назвать каким-нибудь NegroEdit (типа как Sublime, где темная тема по умолчанию)

K>Ну не знаю, тут дело, мне кажется не в модальных диалогах, а просто в общем удобстве. Если удобно, понятно и не перегружено — зашибись. А только текстовые установки — это тоже не очень хорошо для первичного освоения. Нет вспомогательных инструментов как то: выбор файлов, цветов, дат и тд; нельзя управлять связанными данными и многое другое. Текстовые установки просто проще для разработчика.

K>JSON или XML разницы нет. Просто когда я начинал json был не так распространен, а корпоративным был xml.
Соглашусь. Кстати, для JEdit есть всякие плагины/макросы, где делают быстрый выбор/открытые файлов и пр. по мотивам Sublime/TextMate, и, в основном, через модальные окна — удобно, и вписывается в архитектуру редактора.
А XML и сейчас никуда не делся. Хоть и JSON легче воспринимается, но в том же jedit есть универсальный парсер для XML/HTML, который неплохо помогает при вводе, учитывает схемы и пр., фактически на уровне взрослых IDE, чего нет при JSON. И в целом, его система SideKick — для своих парсеров и всего связанного с ними функционала — весьма приятна, некий маленький Эклипс, но полегче и попроще.

K>Поставил сейчас — попробовал. С настройками из коробки, он отказался открывать 170 мб лог и потом завис когда я открыл файл с очень длинной строкой (9мб). Это я думаю проблемы java. Я понимаю что для маленьких файлов он работает шустро, но я бы, как пользователь, хотел решение что работает для всех сценариев (понятно что в разумных пределах).

Я jedit "мучал" уже давненько, перед использованием, и не помню уровень "экстрима". Но тогда я заметил, что с большими файлами он работает по-шустрее, чем вим/эмакс и редакторы поверх scintilla, типа NP++, Scite. А недостатки у него есть, и как раз длинные строки это его болезнь. Он также раздражающе тормозит в режиме виртуального wrap, когда строки переносятся на экране, поэтому я его в таком режиме не гоняю, что досадно. Но это не проблемы Java, такова его реализация (хотя, скорее всего, некоторые стандартные классы Java сыграли своё кривое дело). А в остальной обычной работе он вполне нормальный, но не без грехов, к сожалению.

Кстати, если будешь смотреть на его множественное выделение, то вроде там недавно появился какой-то глюк (или это только у меня из-за какого-то плагина, я пока не разбирался): при каком-то перемещении курсора иногда сбрасываются области выделений, чего вроде раньше не было.

А сам механизм множественного выделения, имхо, лучше делать по мотивам sublime, но добавить ручное переключение вида выделений, как в jedit, и плюс возможность, как в нём же, делать выделения и через клавиатуру, не только мышь + Ctrl. И, вообще-то, нужно всё-таки подумать по поводу того, разрешить ли "курсорам" бегать везде, или нет.
И функции мыши в jedit вроде неплохи, не только для выделений (лично я их мало использую).

А так, меня JEdit привлёк как лучшая альтернатива для вим/эмакс, не всегда удобно/возможно их использовать. Идеология и функционал jedit похожи на эмакс (местами он и удобнее, но по масштабам функционала, конечно, не дотягивает до эмакс), хорошо проработан интерфейс (несмотря на обманчивую убогость, которая многим кажется с первого взгляда), позволяет реально обходиться без мыши, но не всегда это удобно в нём. Но и ряда вещей ему не хватает, есть и проблемы. Идеального ничего нет, "своей мечты" так и не нашёл.

K>У меня регулярки сейчас используются только для поиска так называемых меток (асинхронно). Правила разбора / движок свой (работает в основном синхронно). Руглярные выражения были в 10 раз медленней, даже на тех же сценариях (пробовал boost). Хотя скорее всего придется вводить и их поддержку, потому как мои правила все же сильно ограниченны и не позволяют покрыть все случаи.

Кстати, для регулярок можно попробовать гугловский проект Re2, вроде его хвалят по скорости. Но лично я его не юзал.

K>Здесь у меня другое отношение. В HE у плагина те же права, что и встроенного функционала. Он может расширять функционал там где считает нужным, чтоб органически вписаться в существующую организацию. Может добавить пункт в меню редактирования, или добавить свое главное меню. Расширить стандартный тудбар или добавить свой. Переписать стандартную команду.

K>Это была основная идея бесшовной интеграции, так как я планирую и сам расширять функционал далее в виде плагинов.
K>Ограничение по положению есть только у внешних инструментов и контекстной помощи.
Вроде, логика вполне адекватна. Для макросов, похоже, планируется организация меню по типу jedit, тут нужно не забыть о возможности своей группировки, т.е. о своих папках/каталогах.

PSV>>- есть виртуальное понятие команд: Action. У тебя вроде тоже есть какие-то команды. Но они у тебя не удобно показываются. Лучше CamelCase светить так: "Very Long Command", особенно в каких-то списках. Так делает Sublime. В jedit также есть возможность с ними работать в эмакс-стиле, т.е. как с лисп-идентификаторами: very-long-command.

K>Мне уйти от текущего формата будет уже тяжело, потому как так записаны шоткаты в пользовательских схемах. Да и большой проблемы в формате не вижу. Поиск будет работать и так и так. Может только если делать какие command bars.
Да-да, удобный всякий command-bar очень важный элемент, там нужно очень комфортное быстрое восприятие.

K>А запустить jEdit после падения я так и не смог... Он постоянно загружает файл на котором упал и виснет. Даже с полным uninstall и re-install. (нашел таки потом его перспективу — удалил — загрузился, хотя осадочек остался ).

Да, jedit не без грехов. А его "перспектива" настраивается, где искать, чего открывать и т.д. (в т.ч и через другие плагины, и, вообще, без плагинов из коробки он от блокнота не далеко ушёл).

K>У меня там тоже было много конфигураций по выделению/отображению левой границы. Кое что настраивается xml флагами, кое что зависит от того какие области отключены, тогда информация с отключенных областей переносится на панель номеров строк.

Ага, реально много чего, я пока не уяснил всего. А этот индикатор положений парных элементов в jedit реальная полезняшка, причём эта большая типа скобка "[" никому не мешает, и гармонично смотрится с выделением элементов через рамки (особено, если элемент не скобка, а большой, даже не на одну строку, например, парный XML-тэг).

PSV>>>>- Пробелы, концы строк, табы можно выделять через точечки, но не по средине строки, а внизу, как обычные точки, только дать им другие цвета, как это делает jedit. Тогда эти символы будут не бросаться в глаза, при этом можно включить их постоянный вывод и смотреть на них не только при выделении текста.

K>>>Ну их можно и так включить View->Editor->White Space + Trailing White Space (поискать в Options), и задать для них то цвет что хочешь (или увеличить прозрачность). Только надо обратить внимание на установки Contrast Ratio (options -> search "contrast"), они могут не позволить не контрастные сочетания.
PSV>>Понятно. Только вот эти параграфы, или как эти символы обзываются для конца строк а-ля Word (это очень распространено), как-то громоздки. В jedit светится точечка в конце строк, обычно оранжевая по умолчанию, она и в глаза не бросается, и заметна, когда специально посмотришь.
K>Ну тут можно возразить, что тогда просто пробел тяжело отличить от конца строки. У меня так показывает если нет смешанных терминаторов строк (те все CRLF или LF и тд). Если терминаторы разные, то будет показываться конкретные значения для каждой строки (как Notepad++). Тоже гда то настраивается.
Ясно. Могу ещё "поприставать" — удобна гибкая настройка, например, отображать только концевые пробелы, светить только табуляцию, или когда в исходнике есть помесь и табов и пробелов, то светить все ведущие начальные символы (чтобы различать, где пробелы, а где табы) и все табы (чтобы видеть, что внутри строк натыкали).
Но это, имхо, опять для эмаксеров/вимоводов. И имхо, у тебя тоже наверняка чего-то такое есть, я со всем ещё не разобрался.

K>Попробуй Edit->Selection->Expand/Shrink с множественным повтором. Тебе понравится .

Ага, неплохо. Как раз тогда режимы Selection — Reset/Restore работают "в тему".

PSV>Кстати, вроде в виме очень крутое какое-то дерево для undo, но как с ним работать, я быстро не разобрался, а потом забил.

K>Есть и в e-texteditor — его киллер фича. Но если даже ты не разобрался — кому оно надо.
+1. В виме, конечно, без поллитра во многом не разберешься. А так, я только сейчас в процессе "разбора полётов" заметил, что в JEdit нет истории undo, и в sublime вроде тоже. А вот "Paste Previous", "Paste Deleted" — реально используемые вещи.

PSV>>>>В jedit-е есть классная штука: замена текста на результат работы макро-кода. Удобно, иногда избавляет от написания макроса или внешнего скрипта/утилиты.

K>>>Думаю это усложнение. Можно написать стандартный скрипт для всех.
PSV>>Можно и скрипт. Но, например, можно задать какую-то регулярку, чего-то понаходить и конвертнуть в нижний регистр, указав в поиске для замены выражение "_0.toLowerCase()". Быстро, просто, удобно.
K>Да, но думается мне это не для всех С таким же успехом, можно и в command bar написать : findAll("dodo").toLowerCase(). Или чего-нибудь подобное. Усложнять диалог поиска, я думаю идея плохая. Он и так уже слишком сложен.
Ну, если планируется хороший "commnad bar" или быстрая консоль, то это в любом случае здорово, и для такого поиска тоже.

K>Ну сверни все аттрибуты в тегах — это языко-специфично. не будет. Но есть Collapse to Definition, Collapse Comments, Collapse all same blocks... Посмотрите контекстное меню, Outlining. Зависит от синтаксиса.

Ага, соглашусь. В принципе, тут и явные уровни фолдинга можно игнорировать. Они помогают, когда правила для фолдинга составлены удобно, или, например, когда есть структурное оформление кода — на отступах (как питон), или символы "{{{" — "}}}" (фактически, стандарт в виме/эмаксе/jedit). Вот в jedit пишут CHANGES.txt с фолдингом для последнего случая: клацнул сверни до 1-го уровня — получил список всех версий, клацнул 2-й уровень — раскрыл чуть подробнее: небольшой комментарий к версии плюс разделы "Bug Fixes", "API Changes" и пр., далее ещё вложения и т.п. Для таких случаев не нужны языково-специфичные настройки и вполне универсальный инструмент эти уровни фолдинга, причём удобнее, чем какой-то CodeBrowser в виде дерева, как во многих IDE.

Кстати, удобна такая штука: можно прямо в файле в начале или в конце писать подсказки для редактора по поводу всяких настроек, как в том же примере с CHANGES.txt. Весьма распространено во многих редакторах. Имхо, в HE тоже есть, вероятно.

K>Идея навеяна CodeBubles. Я хочу уйти от понятия файла а перейти к представлениям которые отражают задачу. Такой себе составной документ из разных кусков кода этого или других документов отобранных по заданным пользователям тегам. С поддержкой редактирования конечно. Например чтобы определение и имлементация функции были в одном месте, или функции для работы с текстом, в независимости от реального расположения обрабатывались вместе.

K>Это + множественные выделения у меня приоритетные задачи на следующие версии.
У меня тоже летали подобные мысли. К этому ещё нужно добавить, как бы, некие форматы, или шаблоны ввода. Ну, например, вводим мы список полей в SQL-таблице вида:
create table SOME_TABLE(
    filed1        domain1,
    field_outher  domain2, 
    filed3        domain3,
    ...
);

Здесь, когда мы вводим сам список полей внутри скобок, нужно постоянное форматирование отступов (т.е. поддержка двух столбцов как в некой виртуальной таблице, когда само всё расширяется, двигается и т.д.), нужно tab-ом прыгать между элементами (как в сниппетах TextMate), автодополнение из определенного списка элементов (т.е. нужен список доменов) и пр. Думаю, что идея понятна.

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

Но как это всё реализовать удобно, и универсально, я даже не думал. Реально интересно увидеть твои попытки в этом направлении.
Тут важно не увлечься, и ликвидировать работу с файлами как класс. Так иногда делают некоторые концептуальные семантические редакторы и подобные вещи. Пытаются код хранить в своих базах и т.п. Лучше родных для нас файлов пока ничего нет.

И с такими планами можно до уровня MPS от jetbrains добраться, причём удобнее, хоть это система другого вида и для других задач

K>ну по умолчанию у всех есть JS + Vbscript. А так есть движки для Perl, PHP, Lua.

Да я о том, реально ли кому-то нужна некая неуниверсальность программного кода. Имхо, если все скрипты/макросы у всех будут только в JS, то только всем проще будет, будет лучше переносимость, широкая кодобаза и т.д.
По своему опыту. Я находил нужные мне макросы для jedit на питоне, но чем возиться с прикручиванием питона (есть спецплагины), мне проще переписать на обычный, стандартный, BeanShell (это типа JavaScript в jedit).
Но, похоже, всё решает маркетинг...

K>Ну да, для ошибок это не очень подходит. Тут лучше список. Но для показа количества совпадений слова в документе, измененных зон, вложенных синтаксисов или наличие туду — подходит нормально. Можно использовать как индикатор ошибок в логе, создав стиль подсвечивающий сообщение об ошибке и вывести его на Overview Bar.

По JEdit я заметил, что такой Overview Bar хорошо уживается рядом с MiniMap, когда в этом MiniMap-е заметны подчёркивания и выделения, как-то гармонично друг друга дополняют. Если бы был ещё и хинт для мыши в minimap, когда навёл и вылезло окошко с увеличенной инфой — кайфа ещё было бы больше, и прокручивать меньше нужно было бы.
Кстати, этот minimap фактически позволяет убрать скроллбар справа.

K>Там работы в принципе не много. У меня уже все разделено и подготовлено. Единственно могут быть проблемы с производительностью, если показывать большой документ. Но вроде там всего пару экранов вводиться так что может будет нормально.

Кстати, да, в jedit бывают из-за minimap-а подтормаживания. Обычно я его отключаю.

PSV>>>>Virtual Space

K>>>Если хочется писать где хочешь, а не только в границах строки.
PSV>>А можно в двух словах подробнее, или скриншот, если есть.
K>Скриншот тут сильно не поможет, но я нашел пару описаний в интернете, чтоб заново не писать:
Блин, я забыл, что это дело так мудрённо обзывают. Тут как раз все редакторы можно разделить на две группы: "дельфийцы" — курсор при прокрутке не прыгает всегда к концу строки (типа включенный Virtual Space) и есть обрезание концевых пробелов по ходу дела, а не при записи, и "а-ля VS" — курсор прыгает нервно туда-сюда и пробелы не рубим (и таких большинство, включая вим/эмакс по умолчанию).

K>Да я посмотрел — идея в принципе интересная. Записал себе. Хотя не знаю как она приживется в GUI редакторе. Сначала думал: как же это они делают в большом документе. А потом понял, что это только для видимой области. В этом случае, твое предложение по переходу по функциям кажется мне не очень полезным — сколько будет функций за раз видно на экране? ну и у меня уже есть достаточно удобная навигация по меткам (функциям) с помощью Navigation Bar: Alt+M -> набрать часть имени функции -> Enter.

Не-не-не, Navigation Bar — это для другого. Такие плагины — для быстрого перемещения в пределах видимой области. По поводу функций, я имел в виду следующее. Этот плагин работает, как бы, только вперед: подсвечивает элементы для перехода от курсора до конца экрана. Можно подумать, как сделать перемещение в любую сторону (и нужно ли оно). Если все подсвечивать, весь экран — как-то много шума. Можно попробовать подробно выделять все элементы внутри текущей синтаксической области (функции), а остальные видимые функции на экране — выделять только начало (даже другим цветом, к примеру), и когда ты прыгнул на другую функцию — сразу начинать выделять элементы внутри этой функции (вне её можно/нужно убрать подсветку). Как-то так.

K>Хотя не знаю как она приживется в GUI редакторе.

Отлично. Такие вещи могут "подсадить" как всякий minimap. Если ты не гоняешь вим/эмакс, то можно пощупать плагины Vimperator/Pentadactyl или KeySnail (с подплагином HoK) для FireFox. Там похожая работа со ссылками в броузере (по мотивам этих плагинов и делают перемещения в виме). Реально мышка не нужна.
Здесь нужно учесть ряд нюансов, например, различать/нет регистр для меток, в каком регистре их выводить, из каких букв их формировать и пр. Нужно удобно запрашивать ввод данных, в вим/эмакс есть стандартные мини-буферы для всех случаев, в jedit подобные запросы делают через строку статуса.

Кстати, в этих плагинах для FireFox есть хорошие варианты для реализации всяких command-bar. В Vimperator-е удобно сделано для ввода таких команд как "translate -conv -langpair=ru|en текст для перевода", т.е. когда есть параметры внутри команды (как в командной строке OS). В KeySnail, как эмуляция эмакс, удобно сделан автокомплит, когда можно указывать несколько слов/букв через пробел. Я бы ещё добавил такую технику: в автокомплите, когда выбрал нужный элемент, скажем, имя буфера — т.е. открытой вкладки в FireFox — если нажали Enter, то выполняем ту команду, для которой запускали автокомплит, например, переключились на вкладку, если Ctrl+Enter — выполнили команду, но автокомплит не закрыли, если Shift+Enter — выполнили команду, не закрыли автокомплит и выделили следующий элемент в списке, Ctrl+Shift+Enter — выполнили и выделили пред. элемент (всё это вроде есть из коробки, а вот ->), Alt+Enter — открываем список суб-команд, например, для вкладок это: Close, Move left и т.д., Alt-BackSpace — вернулись назад из суб-меню. Причём, например, в jedit клавиши Alt+Enter и Alt-BackSpace часто связаны со всякими уровнями, например, откр./закрыть фолд.

С таких "мелочей" начинается удобная работа в инструментальной среде, с которой потом слезать крайне не охотно.

PSV>>Кстати, об автодополнении. У тебя хороший механизм с хинтами, в какой-то степени, киллер-фича редактора. Но некоторым нравится, например, как работает автокомплит в sublime, кто-то любит жать Esc/Shift-Esc для подстановки, кому-то нужно, чтобы при наборе автоматом добавлялись окончания как выделенный текст и т.д. Плюс настраиваемая игра с регистром: чувствительность при наборе, всегда ли преобразовывать как в источнике, всякий smart-поиск и т.п.

K>smart-поиск я еще приделаю: поиск по акронимам, нечеткий поиск.
K>Case я уже сейчас отслеживаю, и вставляю так как было набрано или как определено в свойствах (если позволено для синтаксиса).
K>Подстановка in-place — мне не нравиться — это от бедности GUI функционала.
Про Case я заметил, и в целом, система у тебя приятная. Но, я бы не сказал, что всякие альтернативные режимы от бедности в GUI. В том же эмакс тоже есть всякие хинты. Меня, например, немного как-то раздражали всякие постоянные хинты, когда я набирал текст, хотелось их отключить. Видимо, к ним нужно немного привыкнуть, или стараться не обращать внимание, когда они не нужны (имхо, скорее всего, можно быстро привыкнуть).
Конечно, тебе распыляться на всё нет смысла, прежде всего, необходимо ориентироваться на тех, кто хочет видеть перед собой маленькую VS.

PSV>>И я не совсем въехал о всех источниках, откуда берутся данные. Но я особо не разбирался, просто скажу, что неплохо иметь возможность указывать вручную (не только в XML-описании грамматики) список элементов для каждого синтаксиса (например, список своих функций). Также удобно дополнять слова из соседних открытых буферов, но не из всех, а по определенным правилам. Но для этого нужна более удобная организация работы с буферами (как в том же jedit, или вим/эмакс).

K>Про пользовательские списки у меня уже в планах есть, но пока не приоритетно. Дополнение из других буферов... Это все не точно, и может принести больше проблем чем пользы. Лучше уж тогда прикрутить ctags или разбирать инклуды для синтаксиса. Но можно будет посмотреть.
Чтобы дополнять из соседних буферов всё-таки нужна удобная система для работы с буферами. В JEdit есть понятие "Buffer Sets": Global (все открытые), View (только из текущего окна, можно запускать несколько отдельных окон), EditPane (те, которые видны в текущей панели). Например, удобно и просто рядом открыть 1-2 необходимых буфера и данные дополнять и оттуда, особенно когда нет спецпарсеров или всяких ctags для каких-то документов, текстов, или своих DSL и пр. Да и для работы со многими языками часто так выкручиваются, многим полноценный автокомплит и не нужен (который может быть и не всегда верным, чего-то не то показывать, тормозным, ctags на каждый чих перезапускать — тоже не фонтан).

PSV>>И неплохо иметь автокоррекцию по пробелу, например, набрал "if", жмёшь пробел и получи "if (|)", т.е. добавили скобки и курсор прыгнул во внутрь. Причём список элементов для коррекции должен быть настраиваемый по синтаксисам.

K>Ну это CodeTemplates, они зависимы от синтаксиса. А чтоб сработало на пробел, надо его установить как шоткат для Edit.ExpandTemplate. Я помню я там делал специальный хак, чтоб оно потом не ело пробелы, если был набран не имя шаблона. Но я думаю, вариант с Code Hint + Enter если есть шаблон интуитивнее и более стабилен.
PSV>>И коррекция помогает набирать всякие мудрёные символы из юникода, кому нужно (я не пользовался).
K>ну автокоррекция есть, можно добавить что хочешь. Или как темплейт.

Понял. Я хочу лишь подчеркнуть, что для коррекций через пробел вида "if" -> "if (|)" хинт лишний раз можно и не светить, они, как бы, естественные для нужного языка и типа даже незаметные. Не помешала бы коррекция и без пробелов, вида "var1;=SomeVal" — здесь ";" можно автоматом заменить на ":", чтобы получить паскалевское ":=". Или некоторым удобна коррекция для ввода юникода в таком виде: набираешь ``"a`` и тут же сразу это заменяется на ``ä``, а если нужно, скажем, ввести ``'a`` вместо запланированного (по настройкам) ``á``, то вводишь ``' a`` и получаешь ``'a``.

K>Ну у меня много чего есть, в плане автоматических отступов или положения табов, но конкретно уменьшения отступа по : для с++ нет. Есть уменьшение отступа по закрытию scope ( } ). О расширенном варианте с : я конечно думал, но решил пока не делать (в планах есть) — мне нужно универсальный движок, с поддержкой любы синтаксисов, а сделать его быстро не получиться. Но скорее всего буду делать базируясь на правилах описанных в регулярных выражениях.

Да, у тебя много чего есть приятного, поэтому и предлагаю лишний раз глянуть на правила в JEdit, Sublime/TextMate, там есть тоже неплохие идеи (имхо, ты сам обо всём в курсе).
Кстати, замечаю такую тенденцию: многие пишут себе макросы/скрипты в таком стиле — при нажатии, например, на "Ctrl+Enter" мы смотрим, где находимся: если мы внутри JavaDoc — в новой строке добавляем "*" с отступами согдасно пред. строке, или делаем автоинкремент в списках вида "a)... b)...", "1. ... 2. ..." и т.д., и прочие префиксы/окончания. Можно и во внутрь строки посмотреть, например, для строки вида "var1 = value1" делаем новую строку "var2 = value2".
Фактически, такие трюки вырождаются в стандартные функции редактора, с настройкой по синтаксисам.

PSV>>- в диалогах не хватает хотя бы каких-то хинтов, которые чуть больше подскажут по опции. Документация сейчас неполная, да и мало кто ее читает. Например, "Easy Line Copy" — я, к примеру, настраиваю у себя копировать всю строку, если нет выделения, но это та же опция или нет, не понятно. Т.е. пользователи могут просто не заметить какие-то киллер-фичи.

PSV>>Кстати, в sublime, где вся настройка в текстовых файлах, приятно, когда рядом с параметром есть комментарий к нему.
K>Плохо искал. Символ вопроса (?) в системном меню диалога и клик на интересующий контрол или Ctrl+F1.
Ага, это я уже отвык от "стандартов windows". Поэтому и undo-истории не заметил.

K>Я думаю проще все же написать скрипт. Все варианты и комбинации все равно не учтешь. Плюс проблема прикрепления нескольких комманд. События в HippoEDIT — это артефакт Надо бы их убрать, но у меня пока что на них кое что завязано.

Через скрипт, конечно, гибче и мощнее. Тут вопрос в твоих пользователях, захотят ли они "программировать". Хотя та же VS вроде тоже "скриптуется", да и нужно это далеко не всем.

K>Да, у меня уже есть в идеях, от одного фаната емакс. Там же отображением стилем для bold/italic и тд. Но интересно, что будет если цвет совпадает с цветом фона ну и у меня еще поправляется контрастность для цвета текста, так что может быть точного совпадения.

Можно рамочкой выделять, но только в нужных местах.
А всякая "контрастность" и "цветастость" у тебя действительно мощные, быстро и не разберешься во всём.

K>Нет Редактор, это редактор. А органайзер — это органайзер Те кому нужен органайзер — купят специализированный продукт. А другие будут пользоваться бесплатным емакс.

В твоем случае, имхо, так и есть. Могу лишь просто скромно подчеркнуть, что работа в org-mode, как с текстом, реально удобнее многих органайзеров (плюс шире функционал), для тех, кто понимает.

K>Фиг его знает. Фич много уже сделано за все время. Про Virtual Space я уже тебе написал.

K>Можешь глянуть новое, что появилось в 1.50:
K>- [...]
Спасибо, посмотрю по возможности.

K>Не поверишь Отпишись в личку: можно будет поговорить/переписываться по skype или email. Так возможно будет быстрее.

K>А то как то здесь наши обсуждения как оффтопик выходят.

Ну почему оффтоп, как раз обсуждаем "нормальный редактор для C++, который существует" (и не только для C++)

Да, конечно, такие отзывы здесь не к месту. Это меня немного "зацепило"...
Меня сейчас прижимает работа, кроме програмляния нужно разбираться и с кучей инфы. Необходимо искать время, чтобы поглубже покопать редактор. Если будут у меня вопросы, предложения и пр. буду уже обращаться по конкретным "адресам и явкам".

А так, буду рад, если удалось дать реально что-то полезное для твоей копилки. Нужно/не нужно, стоит/не стоит — решать только тебе.

Спасибо.
Re[15]: Нормальный редактор для C++ - существует ли?
От: Kefir http://www.hippoedit.com
Дата: 03.04.12 20:30
Оценка:
Здравствуйте, PSV100, Вы писали:

Лирика:
Любой продукт можно вылизывать до бесконечности: добавлять маленькие рющечки/фишечки и тд. В любом направлении копать не перекопать. Но ресурсы то ограничены. Тем более HippoEDIT все таки не OpenSource (и не Freeware). Так что, как бы это не печально, делать надо те фичи, которые заставят продукт купить или привлечь аудиторию (как то мини-мап какой нибудь). Сдается мне, что все эти имакс/вим фишки, товарищь обнаружит когда поработает с редактором пару месяцев, те тогда когда он его уже типа купил Те — это waste (с маркетинговой точки зрения или модного нынче lean process). Еще: эти все мелкие удобства, на самом деле требуют много работы, которую никто не видит (те маркетиговая ценность их мала).
C другой стороны, как ты заметил, с редактора я не живу (это не основная моя область деятельности). Хотелось бы конечно, но из-за особенностей области или моей лени заниматься продвижением, это как то не выходит. Совсем.
Те, занимаюсь я им для удовольствия (хотя часто приходится дело то, что не очень нравится). Поэтому, приоритеты я ставлю на то, что мне надо самому, или то что соответствует моему стилю работы.
На данный момент, я пока ничего глобального добавлять не буду: надо выпустить 1.50 а там посмотрим. Интересные идеи я себе записал, потом пережую

Ну несмотря на все вышесказанное, во всех этих фишечках я все равно закапываюсь, потому что хочется все сделать по уму и безукоризнено. Хотя в душе понимаю — waste

K>>У меня регулярки сейчас используются только для поиска так называемых меток (асинхронно). Правила разбора / движок свой (работает в основном синхронно). Руглярные выражения были в 10 раз медленней, даже на тех же сценариях (пробовал boost). Хотя скорее всего придется вводить и их поддержку, потому как мои правила все же сильно ограниченны и не позволяют покрыть все случаи.

PSV>Кстати, для регулярок можно попробовать гугловский проект Re2, вроде его хвалят по скорости. Но лично я его не юзал.
Я смотрел — для правил он бы подошел (там достаточно ограниченные возможности), но он к сожалению поддерживает только utf-8, а мне надо utf-16.

K>>Ограничение по положению есть только у внешних инструментов и контекстной помощи.

PSV>Вроде, логика вполне адекватна. Для макросов, похоже, планируется организация меню по типу jedit, тут нужно не забыть о возможности своей группировки, т.е. о своих папках/каталогах.

K>>У меня там тоже было много конфигураций по выделению/отображению левой границы. Кое что настраивается xml флагами, кое что зависит от того какие области отключены, тогда информация с отключенных областей переносится на панель номеров строк.

PSV>Ага, реально много чего, я пока не уяснил всего. А этот индикатор положений парных элементов в jedit реальная полезняшка, причём эта большая типа скобка "[" никому не мешает, и гармонично смотрится с выделением элементов через рамки (особено, если элемент не скобка, а большой, даже не на одну строку, например, парный XML-тэг).
Это в HippoEDIT тоже есть — я писал. Просто не так явно видно (можно настроить — другой цвет/фон). Обрати внимание на яркость фолдинга, напротив текущей области, там где бы ты ожидал скобку jedit.

PSV>Ясно. Могу ещё "поприставать" — удобна гибкая настройка, например, отображать только концевые пробелы, светить только табуляцию, или когда в исходнике есть помесь и табов и пробелов, то светить все ведущие начальные символы (чтобы различать, где пробелы, а где табы) и все табы (чтобы видеть, что внутри строк натыкали).

PSV>Но это, имхо, опять для эмаксеров/вимоводов. И имхо, у тебя тоже наверняка чего-то такое есть, я со всем ещё не разобрался.
У меня пока показывает только все невидимые символы, или ничего. Плюс замыкающие (trailing) пробелы. Добавлять остальное пока не собираюсь — интереса нет. Приспичит, сделаю как плагин. А вообще видеть это кому то нафиг не над, имхо. Конвертировать в один формат при открытии/сохранении это возможно.

K>>Ну сверни все аттрибуты в тегах — это языко-специфично. не будет. Но есть Collapse to Definition, Collapse Comments, Collapse all same blocks... Посмотрите контекстное меню, Outlining. Зависит от синтаксиса.

PSV>Ага, соглашусь. В принципе, тут и явные уровни фолдинга можно игнорировать. Они помогают, когда правила для фолдинга составлены удобно, или, например, когда есть структурное оформление кода — на отступах (как питон), или символы "{{{" — "}}}" (фактически, стандарт в виме/эмаксе/jedit). Вот в jedit пишут CHANGES.txt с фолдингом для последнего случая: клацнул сверни до 1-го уровня — получил список всех версий, клацнул 2-й уровень — раскрыл чуть подробнее: небольшой комментарий к версии плюс разделы "Bug Fixes", "API Changes" и пр., далее ещё вложения и т.п. Для таких случаев не нужны языково-специфичные настройки и вполне универсальный инструмент эти уровни фолдинга, причём удобнее, чем какой-то CodeBrowser в виде дерева, как во многих IDE.
Да, в HippoEDIT есть. Я уже упоминал. Как в питоне фолдинг пока не поддерживается, но user defined регионы/блоки есть.

PSV>Кстати, удобна такая штука: можно прямо в файле в начале или в конце писать подсказки для редактора по поводу всяких настроек, как в том же примере с CHANGES.txt. Весьма распространено во многих редакторах. Имхо, в HE тоже есть, вероятно.

Есть. Я пищу либо в файл сателит, либо в дополнительный файловый поток. Чтоб текст не засорять.

PSV>У меня тоже летали подобные мысли. К этому ещё нужно добавить, как бы, некие форматы, или шаблоны ввода. Ну, например, вводим мы список полей в SQL-таблице вида:

PSV>
PSV>create table SOME_TABLE(
PSV>    filed1        domain1,
PSV>    field_outher  domain2, 
PSV>    filed3        domain3,
PSV>    ...
PSV>);
PSV>

PSV>Здесь, когда мы вводим сам список полей внутри скобок, нужно постоянное форматирование отступов (т.е. поддержка двух столбцов как в некой виртуальной таблице, когда само всё расширяется, двигается и т.д.), нужно tab-ом прыгать между элементами (как в сниппетах TextMate), автодополнение из определенного списка элементов (т.е. нужен список доменов) и пр. Думаю, что идея понятна.
В HE это можно сделать вложением синтаксисов. Внутри каждого синтаксиса свои правила на все. У меня так везде сделано.
По поводу само расширяется — двигается. Посмотри Elastic Tabstop.

PSV>Но как это всё реализовать удобно, и универсально, я даже не думал. Реально интересно увидеть твои попытки в этом направлении.

PSV>Тут важно не увлечься, и ликвидировать работу с файлами как класс. Так иногда делают некоторые концептуальные семантические редакторы и подобные вещи. Пытаются код хранить в своих базах и т.п. Лучше родных для нас файлов пока ничего нет.
Файлы все равно будут конечно. Представь, что ты выделил в разных файлах произвольные области (по одной), присвоил им тег (или набор тегов), как букмарк. Например "Settings". А потом создаешь Settings view: как будто документ состоящий из кусочков ты выделял до этого. С view можно будет работать как с нормальным документом (редактирование, поиск, замена, сохранение), но данные будут меняться, сохраняться в оригинальных документах.
Как то так — по простому.

PSV>Да я о том, реально ли кому-то нужна некая неуниверсальность программного кода. Имхо, если все скрипты/макросы у всех будут только в JS, то только всем проще будет, будет лучше переносимость, широкая кодобаза и т.д.

PSV>По своему опыту. Я находил нужные мне макросы для jedit на питоне, но чем возиться с прикручиванием питона (есть спецплагины), мне проще переписать на обычный, стандартный, BeanShell (это типа JavaScript в jedit).
PSV>Но, похоже, всё решает маркетинг...
У меня можно смешивать куски на разных языках. Те я напишу платформу на JS а использовать можно будет (вызывать) в VB.

PSV>Кстати, этот minimap фактически позволяет убрать скроллбар справа.

Без, в принципе можно, если наложить ползунок на Overview bar. Мини-мап он, как я писал, не на весь документ. Но там будут другие проблемы, как то сплиттер, ползунок закрывающий данные и тд. Посмотри если не видел Инфо-Скроллер

PSV>Не-не-не, Navigation Bar — это для другого. Такие плагины — для быстрого перемещения в пределах видимой области. По поводу функций, я имел в виду следующее. Этот плагин работает, как бы, только вперед: подсвечивает элементы для перехода от курсора до конца экрана. Можно подумать, как сделать перемещение в любую сторону (и нужно ли оно). Если все подсвечивать, весь экран — как-то много шума. Можно попробовать подробно выделять все элементы внутри текущей синтаксической области (функции), а остальные видимые функции на экране — выделять только начало (даже другим цветом, к примеру), и когда ты прыгнул на другую функцию — сразу начинать выделять элементы внутри этой функции (вне её можно/нужно убрать подсветку). Как-то так.

Ну может быть. Текущую область видимости (плюс вложенные) и все последующие открытия областей видимости.

PSV>Чтобы дополнять из соседних буферов всё-таки нужна удобная система для работы с буферами. В JEdit есть понятие "Buffer Sets": Global (все открытые), View (только из текущего окна, можно запускать несколько отдельных окон), EditPane (те, которые видны в текущей панели). Например, удобно и просто рядом открыть 1-2 необходимых буфера и данные дополнять и оттуда, особенно когда нет спецпарсеров или всяких ctags для каких-то документов, текстов, или своих DSL и пр. Да и для работы со многими языками часто так выкручиваются, многим полноценный автокомплит и не нужен (который может быть и не всегда верным, чего-то не то показывать, тормозным, ctags на каждый чих перезапускать — тоже не фонтан).


PSV>Понял. Я хочу лишь подчеркнуть, что для коррекций через пробел вида "if" -> "if (|)" хинт лишний раз можно и не светить, они, как бы, естественные для нужного языка и типа даже незаметные. Не помешала бы коррекция и без пробелов, вида "var1;=SomeVal" — здесь ";" можно автоматом заменить на ":", чтобы получить паскалевское ":=". Или некоторым удобна коррекция для ввода юникода в таком виде: набираешь ``"a`` и тут же сразу это заменяется на ``ä``, а если нужно, скажем, ввести ``'a`` вместо запланированного (по настройкам) ``á``, то вводишь ``' a`` и получаешь ``'a``.

Это все — языково специфично и без триггера не прозрачно. Я сделал, копипаст "var1;=SomeVal" — что делать. Или просто вставил ; перед =. Конечно, что то сделать можно, но это все будут частные случаи, которые требуют знаний специфики языка. Поэтому пусть те, кто ее знают — пишут плагин или скрипт. Я предоставлю фреймворк. Может сделаю как пример, для синтаксиса который я использую сам.

K>>Ну у меня много чего есть, в плане автоматических отступов или положения табов, но конкретно уменьшения отступа по : для с++ нет. Есть уменьшение отступа по закрытию scope ( } ). О расширенном варианте с : я конечно думал, но решил пока не делать (в планах есть) — мне нужно универсальный движок, с поддержкой любы синтаксисов, а сделать его быстро не получиться. Но скорее всего буду делать базируясь на правилах описанных в регулярных выражениях.

PSV>Да, у тебя много чего есть приятного, поэтому и предлагаю лишний раз глянуть на правила в JEdit, Sublime/TextMate, там есть тоже неплохие идеи (имхо, ты сам обо всём в курсе).
PSV>Кстати, замечаю такую тенденцию: многие пишут себе макросы/скрипты в таком стиле — при нажатии, например, на "Ctrl+Enter" мы смотрим, где находимся: если мы внутри JavaDoc — в новой строке добавляем "*" с отступами согдасно пред. строке, или делаем автоинкремент в списках вида "a)... b)...", "1. ... 2. ..." и т.д., и прочие префиксы/окончания. Можно и во внутрь строки посмотреть, например, для строки вида "var1 = value1" делаем новую строку "var2 = value2".
PSV>Фактически, такие трюки вырождаются в стандартные функции редактора, с настройкой по синтаксисам.
Можно

K>>Да, у меня уже есть в идеях, от одного фаната емакс. Там же отображением стилем для bold/italic и тд. Но интересно, что будет если цвет совпадает с цветом фона ну и у меня еще поправляется контрастность для цвета текста, так что может быть точного совпадения.

PSV>Можно рамочкой выделять, но только в нужных местах.
Да, в принципе — идея.

PSV>Спасибо.

Тебе Спасибо
Re[16]: Нормальный редактор для C++ - существует ли?
От: PSV100  
Дата: 05.04.12 18:01
Оценка:
Здравствуйте, Kefir, Вы писали:

K>Лирика:

K>Любой продукт можно вылизывать до бесконечности: [...]

Это всё понятно. Воспринимаю как крик души...
(а я тут новый "недостаток" заметил: в настройках "Caret Shapes" до полноты картины не хватает "рамочки", как в JEdit. Даже боюсь теперь и предлагать ).

А вообще-то, тебе в жизни повезло: ты можешь заниматься любимым хобби-проектом, который реально полезный и тебе самому, при этом и даёт ещё какую-то материальную отдачу. Другие, к примеру, чтобы совсем не отупеть, чтобы нудную и достающею основную работу как-то разбавить чем-то для души, вынуждены, например, заниматься "хаскельством"

Но недостатки тоже есть: наличие пользователей-клиентов (многие из которых ещё и "достали") вынуждает работать над проектом больше, чем есть возможность и желание.

K> Ну несмотря на все вышесказанное, во всех этих фишечках я все равно закапываюсь, потому что хочется все сделать по уму и безукоризнено. Хотя в душе понимаю — waste


Кстати, да, видно, что работа проделывается не абы как. Например, вывод сообщений в статус-баре: выделили жёлтым и затухание до бледного жёлтого. Мелочи прорабатываешь, очень приятно.

K>>>У меня там тоже было много конфигураций по выделению/отображению левой границы. Кое что настраивается xml флагами, кое что зависит от того какие области отключены, тогда информация с отключенных областей переносится на панель номеров строк.

PSV>>Ага, реально много чего, я пока не уяснил всего. А этот индикатор положений парных элементов в jedit реальная полезняшка, причём эта большая типа скобка "[" никому не мешает, и гармонично смотрится с выделением элементов через рамки (особено, если элемент не скобка, а большой, даже не на одну строку, например, парный XML-тэг).
K>Это в HippoEDIT тоже есть — я писал. Просто не так явно видно (можно настроить — другой цвет/фон). Обрати внимание на яркость фолдинга, напротив текущей области, там где бы ты ожидал скобку jedit.

Я так пока и не понял, что в той области слева от текста может быть выведено. Поклацал всякие настройки, но не заметил:
— некоего аналога скобки jedit, или выделения цветом для этого;
— выделения текущей синтаксической области, например, функции, как это делает Эклипс, к примеру.

Вроде ты говоришь, что всё есть, но я не пойму как. Фолдинг не выделяется, как-то включил только то, что вся его полоска может быть ярче при наведении мыши. Есть только выделение цветом признака измененности строк, он становится бледнее после сохранения, нет обозначения разными цветами для отдельных операций (добавлено, модифицировано, а здесь удалено). Есть прикольные значки для операторов выхода, как return, continue, для вылетов по эксцепшинам — прикольно, что значки красные.
В общем, возможно, что я чего-то не досматриваю.

Кстати, посмотри на сбрасывание флага измененности строки после undo — режим undo не доступен (нет и истории, соответственно), а индикатор горит. Похоже, всё-таки баг.

PSV>>Кстати, удобна такая штука: можно прямо в файле в начале или в конце писать подсказки для редактора по поводу всяких настроек, как в том же примере с CHANGES.txt. Весьма распространено во многих редакторах. Имхо, в HE тоже есть, вероятно.

K>Есть. Я пищу либо в файл сателит, либо в дополнительный файловый поток. Чтоб текст не засорять.
Да, засорять исходники чем-то для IDE в большинстве случаев неприятно. Писать в сам файл удобно тогда, когда проще, например, передать сам один файл, без всяких внешних настроек, например, в проекте. Или когда нет работы с проектом, и т.п.

А что это за фишка такая в NTFS: Alt. File Stream, чё-то раньше не обращал внимание. Куда копнуть? (скорее, я опять туплю в чём-то, от усталости)

K>В HE это можно сделать вложением синтаксисов. Внутри каждого синтаксиса свои правила на все. У меня так везде сделано.

K>По поводу само расширяется — двигается. Посмотри Elastic Tabstop.
Это не совсем то, что я хотел сказать, точнее, я не так выразил идею. Вложенные синтаксисы и в JEdit есть, и эти резиновые табы вроде прикручивают туда же.

Тут нужен такой эффект: вот после того, как сработал сниппет а-ля TextMate/Sublime, я чего-то поделал, а потом хотелось бы вернуться курсором в той район, где раньше был ввод через сниппет, чего-то клацнуть, и этот сниппет опять заработал, но уже на имеющихся данных, т.е., например, я могу редактировать имя функции/метода, клацнул таб — перелетел на первый параметр, его правлю и т.д. При этом все изменения автоматом корректируются и в JavaDoc для этого метода, т.е. то, что было настроено для некоего сниппета для ввода нового метода. В сниппетах и резиновые табы очень полезны будут. Как-то так. Надеюсь, что более-менее понятно, о чём говорю.
Конечно, такой функционал — это уже для спецпарсеров с семантикой, удел настоящих IDE, с рефакторингом и пр. Но можно попробовать оценить, реально или нет для универсального парсера, с настройками для всяких синтаксических сниппетов, добиться похожего функционала.

А в идеале, нужна одна единая система для парсеров — и для прорисовки, и для IDE-функций. Но похоже, что даже во всяких Эклипсах это не так: один разбор текста для рисования, и есть другой разбор — для всякого AST и функционала поверх него. Отсюда начинается и расход памяти, и тормоза на молотилку часто одного и того же в разных системах.

K>Файлы все равно будут конечно. Представь, что ты выделил в разных файлах произвольные области (по одной), присвоил им тег (или набор тегов), как букмарк. Например "Settings". А потом создаешь Settings view: как будто документ состоящий из кусочков ты выделял до этого. С view можно будет работать как с нормальным документом (редактирование, поиск, замена, сохранение), но данные будут меняться, сохраняться в оригинальных документах.

K>Как то так — по простому.
Идея хорошая. Имхо, главное, как раз чтобы было по простому.

PSV>>Кстати, этот minimap фактически позволяет убрать скроллбар справа.

K>Без, в принципе можно, если наложить ползунок на Overview bar. Мини-мап он, как я писал, не на весь документ. Но там будут другие проблемы, как то сплиттер, ползунок закрывающий данные и тд. Посмотри если не видел Инфо-Скроллер
Инфо-Скроллер я видел, и нечто подобное я и имел в виду. Я не совсем понял, что значит мини-мап не на весь документ.
Вот если посмотреть в Sublime, то можно заметить, что скроллбар фактически дублируется ползунком в мини-мапе.
Одним словом, можно объединить мини-мап, Overview Bar, скроллбар в один мега-пупер контрол, который заставит облизываться даже пользователей Sublime. А кнопки вверх/вниз в скроллбаре фактически не нужны.

P.S. Сорри, не удержался, но уже проще обсудить небольшие вопросики здесь по месту, где проблемы выявлены.
Re[5]: Нормальный редактор для C++ - существует ли?
От: Denys V. Украина http://ua.linkedin.com/in/dvalchuk
Дата: 08.04.12 19:35
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ха, а CEDIT прожевал Boost нормально, но при этом стал тормознее Нетбинса. Интересненько... )))


попробуйте emacs + clang здесь
видео

здесь

тут прикрутили clang к vim: здесь

а тут активно крутят к Sublime здесь

рано вы хороните "продвинутые редакторы"

Лично мне нравится vim/emacs/Sublime за возможность гибко настроить под себя.
Я когда то настраивал студию — создавал визарды, аддоны... как вы думаете — куда все это делось? Люди со скриптами для vim/emacs живут десятилетиями, допиливают, совершенствуют, меняют работу, платформы, языки — а их "IDE" продолжает работать... По моему — это огромный плюс!
И не нужно забывать о том что все их фичи (практически все) успешно работают без GUI.
Конечно же есть и недостатки:
VIM
1. высокий порог вхождения (пробовал cream мод — убивает многие базовые фичи редактора — потому бесполезен) — но побеждаем — я им довольно таки долго пользовался как редактором для скриптовых языков.
2. лично мне не понравился его язык для рассширений.
EMACS
1. высокий порог вхождения (планирую начать с ErgoEmacs — cудя по документации он не убивает фичи, а только добавляет привычные шоткаты)
Sublime Text 2
1. Стремная лицензия — не цена — я готов платить за хороший редактор — но не готов платить за редактор, мои скрипты к которому в один прекрассный день перестанут работать, а сделать с этим ничего нельзя будет. Для кого то это может быть и не недостаток... Но я боюсь Если с лицензией будут хотя бы исходники поставляться — тогда можно подумать о покупке...
С уважением Denys Valchuk

IMHO чем больше мнений тем оптимальней выбор варианта... :)
Re[14]: Нормальный редактор для C++ - существует ли?
От: jazzer Россия Skype: enerjazzer
Дата: 08.04.12 19:54
Оценка:
Здравствуйте, Kefir, Вы писали:

K>Да жаль, но как я уже писал — здесь сделать что-то, что подходит всем будет очень сложно. Лучше найти какое нибудь специализированное решение — "с++ code beautifier" и подсоединить его как внешний инструмент или скрипт. Точно такое уже есть, и точно оно будет мощнее чем решение в HippoEDIT.


+1
Я юзаю AStyle для этой цели, зову прямо из редактора (NEdit), чтоб перефроматировал выделенный текст
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[17]: Нормальный редактор для C++ - существует ли?
От: Kefir http://www.hippoedit.com
Дата: 08.04.12 22:46
Оценка:
Здравствуйте, PSV100, Вы писали:

PSV>Это всё понятно. Воспринимаю как крик души...

PSV>(а я тут новый "недостаток" заметил: в настройках "Caret Shapes" до полноты картины не хватает "рамочки", как в JEdit. Даже боюсь теперь и предлагать ).
Ну ты то все равно не будешь пользоваться, так что твой реквест не считается Я посмотрел, мне чтобы добавить рамочку, придется кое что менять (использую CreateSolidCared? надо будет переходить на CreateCaret). Так что пока — фиг с ней .

PSV>А вообще-то, тебе в жизни повезло: ты можешь заниматься любимым хобби-проектом, который реально полезный и тебе самому, при этом и даёт ещё какую-то материальную отдачу. Другие, к примеру, чтобы совсем не отупеть, чтобы нудную и достающею основную работу как-то разбавить чем-то для души, вынуждены, например, заниматься "хаскельством"

Ну энергию то можно было бы тратить на что то более экономически выгодное или на карьерный рост. Так что все спорно Текстовые редакторы, слишком старая ниша, чтоб не закопаться в мелкой рутине, имхо.

PSV>Я так пока и не понял, что в той области слева от текста может быть выведено. Поклацал всякие настройки, но не заметил:

PSV>- некоего аналога скобки jedit, или выделения цветом для этого;
PSV>- выделения текущей синтаксической области, например, функции, как это делает Эклипс, к примеру.
Вот сделал скриншот — надеюсь теперь будет понятней. Просто для стиля Outlining (Highlighted) надо поставить цвет поярче.


Там вообще много что можно сконфигурировать, играясь цветами стилей (например убрать рамочку для Current Line frame etc).

PSV>Вроде ты говоришь, что всё есть, но я не пойму как. Фолдинг не выделяется, как-то включил только то, что вся его полоска может быть ярче при наведении мыши. Есть только выделение цветом признака измененности строк, он становится бледнее после сохранения, нет обозначения разными цветами для отдельных операций (добавлено, модифицировано, а здесь удалено).

Удаление я пока не показываю. Я не делаю diff а запоминаю как атрибут строки была ли она модифицирована/сохранена и манипулирую этими данными после undo/redo.

PSV>Кстати, посмотри на сбрасывание флага измененности строки после undo — режим undo не доступен (нет и истории, соответственно), а индикатор горит. Похоже, всё-таки баг.

Да, наверное, я потом тоже как то заметил.

PSV>>>Кстати, удобна такая штука: можно прямо в файле в начале или в конце писать подсказки для редактора по поводу всяких настроек, как в том же примере с CHANGES.txt. Весьма распространено во многих редакторах. Имхо, в HE тоже есть, вероятно.

K>>Есть. Я пищу либо в файл сателит, либо в дополнительный файловый поток. Чтоб текст не засорять.
PSV>Да, засорять исходники чем-то для IDE в большинстве случаев неприятно. Писать в сам файл удобно тогда, когда проще, например, передать сам один файл, без всяких внешних настроек, например, в проекте. Или когда нет работы с проектом, и т.п.
Ну да, если файлы сателиты, то надо копировать вместе с файлом. Но если копируется каталогами, то не проблема. Зато решается проблема с различными форматами этих магических записей в файл в зависимости от синтаксиса...
А с файловыми потоками этой проблемы вообще нет. Все копируется вместе с файлом (конечно если с NTFS на NTFS).

PSV>А что это за фишка такая в NTFS: Alt. File Stream, чё-то раньше не обращал внимание. Куда копнуть? (скорее, я опять туплю в чём-то, от усталости)

File Streams и еще тут кое что. Там ничего сложного, тоже чтение/запись в файл но с кое какой магией в именах.

PSV>Тут нужен такой эффект: вот после того, как сработал сниппет а-ля TextMate/Sublime, я чего-то поделал, а потом хотелось бы вернуться курсором в той район, где раньше был ввод через сниппет, чего-то клацнуть, и этот сниппет опять заработал, но уже на имеющихся данных, т.е., например, я могу редактировать имя функции/метода, клацнул таб — перелетел на первый параметр, его правлю и т.д. При этом все изменения автоматом корректируются и в JavaDoc для этого метода, т.е. то, что было настроено для некоего сниппета для ввода нового метода. В сниппетах и резиновые табы очень полезны будут. Как-то так. Надеюсь, что более-менее понятно, о чём говорю.

PSV>Конечно, такой функционал — это уже для спецпарсеров с семантикой, удел настоящих IDE, с рефакторингом и пр. Но можно попробовать оценить, реально или нет для универсального парсера, с настройками для всяких синтаксических сниппетов, добиться похожего функционала.
Понятно, типа работа по форме/шаблону. Думается мне — тут работы будет дофига, а будет ли что то юзабельное в конце концов — не ясно.
Можно будет глянуть, когда я добавлю множественное выделение/редактирование. Может быть надо будет просто не сбрасывать/запоминать шаблоны после вставки... Хотя их все надо будет пересчитывать, плюс что делать если пользователь кликнет где нибудь мимо шаблона. Те надо будет еще какие то защищенные области вводить.

PSV>А в идеале, нужна одна единая система для парсеров — и для прорисовки, и для IDE-функций. Но похоже, что даже во всяких Эклипсах это не так: один разбор текста для рисования, и есть другой разбор — для всякого AST и функционала поверх него. Отсюда начинается и расход памяти, и тормоза на молотилку часто одного и того же в разных системах.

Оно то да, да только все упирается в производительность. В HippoEDIT тоже разбор раздельный. Потому как рисование синхронное и некоторые данные, как то где строки/комментарии а где кож мне надо сразу тоже синхронно. И я не могу допустить чтобы парсер "тормозил". А есть "не обязательные" данные, которые могут рассчитываться дольше, и делаются в параллельных потоках, а потом накладываются. При совмещении парсеров — мои синхронные работы будут выполняться по самому длительному сценарию, а это не допустимо. Так что раздельные парсеры, хоть и сложнее, но более гибче.

PSV>>>Кстати, этот minimap фактически позволяет убрать скроллбар справа.

K>>Без, в принципе можно, если наложить ползунок на Overview bar. Мини-мап он, как я писал, не на весь документ. Но там будут другие проблемы, как то сплиттер, ползунок закрывающий данные и тд. Посмотри если не видел Инфо-Скроллер
PSV>Инфо-Скроллер я видел, и нечто подобное я и имел в виду. Я не совсем понял, что значит мини-мап не на весь документ.
PSV>Вот если посмотреть в Sublime, то можно заметить, что скроллбар фактически дублируется ползунком в мини-мапе.
PSV>Одним словом, можно объединить мини-мап, Overview Bar, скроллбар в один мега-пупер контрол, который заставит облизываться даже пользователей Sublime. А кнопки вверх/вниз в скроллбаре фактически не нужны.
Да действительно, был не прав. Скролит по всему документу. Просто мини изображение только по части документа (попробуй реально большой документ). А overview bar — по всему документу. Те больше соответствует инфо скроллеру.
Скролл бар позволяет скролить постранично/построчно с помощью мыши. Если это убрать, народ работающий с мышью будет возмущаться.
Так что если делать, совместить не сильно получится, только для небольших документов как то можно. Но пока желания нет . По крайней мере не в 1.50
Re[10]: Нормальный редактор для C++ - существует ли?
От: Brutalix  
Дата: 08.04.12 23:13
Оценка:
Здравствуйте, Kswapd, Вы писали:

K>Я вышел на Emacs немного странным путём — через увлечение лиспом; показалось забавным поработать в редакторе, расширяемом скриптами на лиспе. Потом только вкурил, насколько красива и последовательна архитектура Emacs, и насколько неограниченны возможности расширения и адаптации под свои задачи. Emacs, по сути, виртуальная машина, в которой работает собственная OS.



Ага. Если б туда еще текстовый редактор приличный добавили б, так цены б ему не было

K>Мне кажется, работать в IDE, которую можно освоить за несколько дней, как-то скучновато .


== стоя в гамаке и в скафандре
Re[6]: Нормальный редактор для C++ - существует ли?
От: alex_public  
Дата: 09.04.12 10:09
Оценка:
Здравствуйте, Denys V., Вы писали:

DV>видео


Вооот, на этом видео как раз то что мне надо. И функциональность и скорость. Ну т.е. то что надо от автодополнения. Надо ещё навигацию по файлам соответствующую (хотя при таком анализе проблем быть не должно). И собственно нормальный редактор.

Не знаете где такое можно скачать и что бы просто работало, без проблем? )))

Я лично не знаю ни одного такого редактора. И знаю 3 ide (VS+VA, Netbeans, Eclipse) разной степени монструозности и тормознутости.

DV>попробуйте emacs + clang здесь

DV>здесь
DV>тут прикрутили clang к vim: здесь
DV>а тут активно крутят к Sublime здесь

Попробовал в Sublime. На проектах типа hello world работает практически идеально. Далее, если подключаем мощные библиотеки, то при переключение на файл оно тормозится на несколько секунд и потом выдаёт в консоль миллионы ошибок. При этом как ни странно автодополнение кое-как работает, но при этом тормозит больше чем Netbeans, практически как emacs+cedit — не юзабельно уже. Но самое интересно было на маленьком файлике вообще без библиотек, но зато с лямбдами — на нём оно стабильно зависало навсегда. )))

Причём всё это меня не сильно удивило. Я тут пробовал clang сам по себе — он не тянет многое до сих пор. Т.е. все вышеописанные глюки, это вина именно clang'a, а не редактора или плагина. Может быть, когда-нибудь, когда clang доделают до вменяемого состояния, это всё и заработает суперски. Но пока всё ужасно.

DV>Лично мне нравится vim/emacs/Sublime за возможность гибко настроить под себя.

DV>Я когда то настраивал студию — создавал визарды, аддоны... как вы думаете — куда все это делось? Люди со скриптами для vim/emacs живут десятилетиями, допиливают, совершенствуют, меняют работу, платформы, языки — а их "IDE" продолжает работать... По моему — это огромный плюс!
DV>И не нужно забывать о том что все их фичи (практически все) успешно работают без GUI.

Тут вроде бы уже проскакивала мысль, что Еmacs современности — это Eclipse. Если есть желание что-то сильно кастомизировать, то ничего лучше этого монстра нет. Там можно всё что угодно добавить. Просто в моём случае я как раз не хочу ничего настраивать (ну кроме цветов, папки инклудов и стиля форматирования), а хочу просто скачать продукт и работать с ним.

А vim и emacs со своим древним интерфейсом мне кажется несколько устарели. Эклипс может всё тоже что и они (ну разве что кроме работы через терминал) и плюс ещё кучу всего. Но как я уже сказал это всё не то что мне хотелось бы лично. Мне скорее ближе Nebeans или HippoEDIT)))

Что касается Sublime, то это очень инересный продукт. Он не менее удобен и лаконичен чем какой-нибудь Notepad++, всё работает из коробки и при этом расширяем почти как монстры (Eclipse, emacs). Мне нравится с ним работать. Нравится как сделаны его расширения (Питон у нас интенсивно используется для близких целей). Но пока не знаю зачем он мне может понадобиться. На место IDE ему сложно претендовать — у него навигация и т.п. слабеее даже чем HippoEDIT, я уже молчу про Netbeans. А для просто небольшого быстрого редактора кода все эти расширения и не нужны — тут даже Notepad++ перекрывает всё нужное. Так что... Хотя наверное на не windows платформах он будет точно нужен, т.к. там половины конкурентов нет.
Re[13]: Нормальный редактор для C++ - существует ли?
От: MasterZiv СССР  
Дата: 09.04.12 14:48
Оценка:
> А вот IDE — это уже заметно больше. Там и проекты и системы сборки

Билд-системы бывают в IDE разные, есть встроенные, а есть внешние.
Так что это не ключевая функциональность IDE.
Например, почти все IDE из GNU используют внешние билд-системы.

и отладчики и

Отладчик — да. Ключевая функция IDE.

> контроль версий и контроль задач и взаимодействие с командкой...


Этого в половине IDE нет даже в задумках.


Так что остаётся -- IDE это редактор с подсветкой синтаксиса,
броузинг кода, запуск сборки и отладчик.
Posted via RSDN NNTP Server 2.1 beta
Re[14]: Нормальный редактор для C++ - существует ли?
От: MasterZiv СССР  
Дата: 09.04.12 15:21
Оценка:
On 03/14/2012 10:59 AM, PSV100 wrote:

> Дополню юмор.

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

Эти макросы ещё будут сохраняться в КАЖДОМ ВОРКСПЕЙСЕ ОТДЕЛЬНО !
Posted via RSDN NNTP Server 2.1 beta
Re[14]: Нормальный редактор для C++ - существует ли?
От: alex_public  
Дата: 09.04.12 18:02
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>Этого в половине IDE нет даже в задумках.


В тех трёх IDE, где я видел приемлемую подсветку синтаксиса, броузинг и автокомплит, от всяких дополнительных функций (типа командной работы) было деваться некуда. )))

MZ>Так что остаётся -- IDE это редактор с подсветкой синтаксиса,

MZ>броузинг кода, запуск сборки и отладчик.

Ещё система проектов обязательно для любой IDE, даже для слабой. Но как я уже сказал, в слабых и сам редактор меня не удовлетворяет... Так что по любому остаются только те монстры.
Re[15]: Нормальный редактор для C++ - существует ли?
От: MasterZiv СССР  
Дата: 09.04.12 20:30
Оценка:
> Ещё система проектов обязательно для любой IDE, даже для слабой. Но как я уже
> сказал, в слабых и сам редактор меня не удовлетворяет... Так что по любому
> остаются только те монстры.

Что значит система проектов?
Билд-система -- я сказал, а система проектов, -- это что ?
Набор файлов, который IDE считает "своими" ?
Если так, то тоже далеко не везде она есть, система прокетов.
Например, тот же самый Eclipse -- нету там системы проектов.
Есть только билд-система.
Posted via RSDN NNTP Server 2.1 beta
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.