Здравствуйте, Kefir, Вы писали:
K>с "прыганьем" курсора при скролле, я вроде понял. Это у меня скорее всего оптимизация прорисовки, что обновляет позицию каретки только на idle, чтобы уменьшить количество обновлений при скролле. Можно будет это отключить для маленьких документов но оставить для терминальной сессии или больших документов.
Как-то этот курсор в ряде редакторов абсолютно "не прыгающий". В том же JEdit он какой-то всегда "вкопанный", как-будто сам по себе, без текста. Имхо, у каждого свои компромиссы между отрисовками, парсингом, обработка событий и т.д.
Если проблема "геморна", то можно смело "забить", ведь никто не обращал твоё внимание на это.
K>Для скринкастов вроде инструментов полно, тот же Snagit или Camtasia. Но уже не надо.
Ага, спасибо. Я уже сам попробовал парочку вариантов, но ничего и не получится: нет как бы сплошной беспрерывной записи видео (как ни старайся в настройках) и дёргание курсора незаметно.
K>Версию я уже обновил, но чувствую я, что придется скоро заново обновлять. Бывает падает при выходе.
А бывает и при входе. Я как-то пытался на одном компе с win7 запустить редактор, но не получилось: процесс немного висит и затем молча без сообщений и без окошек вылетает. Брандмауэр в винде этот процесс не валит (якобы, что он лезет в инет без спроса), запуск от "администратора" не помогает, антивирус вроде тоже не причём.
Версия не последняя, предыдущая. Последнюю сейчас проверить не могу, нет этого компа под рукой.
И ещё проблемы в обновленной версии — как-то кривовато работает режим при вводе длинных строк, когда делается wrap по границе окна (wrap по конкретному столбцу не пробовал): слово иногда (!) может обрезаться внутри, т.е. не перенестись целым словом на новую строку, нажимаешь следующую букву, может не одну, тогда всё переносится как надо. Вроде иногда переносится слово рановато, т.е. в конце виртуальной строки оно могло бы ещё влезть (но это может показалось).
И рекомендация: может есть смысл установить шрифт Consolas по умолчанию, вроде сейчас так многие делают, та же студия (если я не ошибаюсь).
K>В общем, ко всему надо подходить с умом Может если писать что то новое, вариант Light Table не плох и там со временем можно будет решить все проблемы, но переделать существующий проект под его стиль — неблагодарный труд. K>А идеи спереть/переработать — это да
Да конечно нет смысла всё переделывать в имеющемся проекте, да и ненужно это конкретным пользователям (хотя многие просто не пробовали иное). А этот Light Table всего лишь концепт, сделанный вэб-дизайнером на вэб-технологиях. А эти всякие Bubbles-окошки, на мой взгляд, какие-то неудобные, особенно если в них только мышкой тыкать.
Кстати, вот в JEdit, в отличие от эмакса и вима, сел и поехал. Привыкать год ненужно. И мышкой, и клавой (без мыши) работать вполне удобно (но всё-таки, иногда проще мышкой тыкать), и всякие тулбары с кнопками не нужны, я даже не включаю традиционные tab-ы для переключения буферов, эти здоровые "combobox-ы" вверху буфера удобнее их (хотя можно сделать ещё удобнее).
Re[17]: Нормальный редактор для C++ - существует ли?
Здравствуйте, MasterZiv, Вы писали:
>> Да, только Windows. Перенести конечно возможно, но не реально >> Работы много, и она, скорее всего не отобьется.
MZ>Ну... как сказать, есть андроид...
Честно говоря я не понял, причем здесь андроид...
Портировать под андроид??
Re[19]: Нормальный редактор для C++ - существует ли?
Здравствуйте, alex_public, Вы писали:
_>У меня на любом выскакивает проблема) Ну взять любой класс из библиотечки. wxString, wxWindow )
Проблема, скорее всего из-за скрипта подсветки слова поиска. У меня, в принципе, видимых проблем не заметно: да, поле пути стоит javascript:void(0), но страница правильная. Слово поиска — не подсвечено.
Скорее всего скрипт падает, и в зависимости от настроек IE, у наст разное поведение. Пустого фрейма тоже нет, но я предполагаю как он мог получиться — как писал: поправлю.
Со скриптом тоже гляну — пример есть.
Re[25]: Нормальный редактор для C++ - существует ли?
Здравствуйте, PSV100, Вы писали:
PSV>Если проблема "геморна", то можно смело "забить", ведь никто не обращал твоё внимание на это.
Поправим
PSV>Версия не последняя, предыдущая. Последнюю сейчас проверить не могу, нет этого компа под рукой.
Да. Оно все таки бета. Все выловлю со временем. Просто не успеваю да и новые вещи добавляю, а они приносят новые баги
PSV>И ещё проблемы в обновленной версии — как-то кривовато работает режим при вводе длинных строк, когда делается wrap по границе окна (wrap по конкретному столбцу не пробовал): слово иногда (!) может обрезаться внутри, т.е. не перенестись целым словом на новую строку, нажимаешь следующую букву, может не одну, тогда всё переносится как надо. Вроде иногда переносится слово рановато, т.е. в конце виртуальной строки оно могло бы ещё влезть (но это может показалось).
Это я в этой версии обновил алгоритм wrap, для лучшей поддержки не пропорциональных фонтов. Тоже русский товарищ жаловался. Я долго забивал, а то переделал (только для небольших документов, для больших работает оптимизированный, старый вариант). Так что может что то работать не так. Скинь пример.
Еще там же было одно изменение, что строка должна начинаться только с буквы (точнее слова), а не пробела или знака препинания, а то выглядит не кошерно. Тоже замечание от того же товарища. Так что может это оно? Если конечно не получается — то режет где попало.
PSV>И рекомендация: может есть смысл установить шрифт Consolas по умолчанию, вроде сейчас так многие делают, та же студия (если я не ошибаюсь).
Он только с Vista (или XP? не помню), а у меня поддерживается все с Windows 98. C версии 1.50 только с Win 2000. Придется делать default в зависимости от версии. Но сделать можно конечно.
K>>В общем, ко всему надо подходить с умом Может если писать что то новое, вариант Light Table не плох и там со временем можно будет решить все проблемы, но переделать существующий проект под его стиль — неблагодарный труд. K>>А идеи спереть/переработать — это да
PSV>Кстати, вот в JEdit, в отличие от эмакса и вима, сел и поехал. Привыкать год ненужно. И мышкой, и клавой (без мыши) работать вполне удобно (но всё-таки, иногда проще мышкой тыкать), и всякие тулбары с кнопками не нужны, я даже не включаю традиционные tab-ы для переключения буферов, эти здоровые "combobox-ы" вверху буфера удобнее их (хотя можно сделать ещё удобнее).
А если надо видеть все файлы сразу (табы тоже несут информационную нагрузку: изменен, блокирован, UAC) или переключиться в один клик? combo — вопрос спорный.
Тулбары с кнопками удобны для редких, но все же используемых функций и для более простого освоения интерфейса.
Re[20]: Нормальный редактор для C++ - существует ли?
Здравствуйте, Kefir, Вы писали:
K>Проблема, скорее всего из-за скрипта подсветки слова поиска. У меня, в принципе, видимых проблем не заметно: да, поле пути стоит javascript:void(0), но страница правильная. Слово поиска — не подсвечено. K>Скорее всего скрипт падает, и в зависимости от настроек IE, у наст разное поведение. Пустого фрейма тоже нет, но я предполагаю как он мог получиться — как писал: поправлю. K>Со скриптом тоже гляну — пример есть.
Да, может быть ещё разница потому что у меня на этой машине старый IE. Просто сам chm (вне редактора) открывается нормально и другие chm (в редакторе уже) открываются тоже нормально. Т.е. это как бы единственное такое исключение.
Re[18]: Нормальный редактор для C++ - существует ли?
Здравствуйте, MasterZiv, Вы писали:
MZ>Ну, например. MZ>Или просто под linux, он сейчаст тоеж популярнее стал.
Кстати огромная разница. Допустим наш софт переносится на нормальный linux и на osx простой перекомпиляцией. А под андроид фиг такое выйдет — надо обязательно переделывать интерфейс, да ещё и на этой кривой яве. Кстати, под iOS (iphone, ipad) тоже теоретически перекомпиляции достаточно, но на практике "взрослый" интерфейс там выглядит не так удобно, так что лучше тоже переделать.
В общем мне странно когда смешивают такие разные вещи. Windows, Linux, OS X — это одно, а Android и iOS — это совсем другое и проблемы для переноса принципиально разные.
Re[26]: Нормальный редактор для C++ - существует ли?
Здравствуйте, Kefir, Вы писали:
PSV>>И рекомендация: может есть смысл установить шрифт Consolas по умолчанию, вроде сейчас так многие делают, та же студия (если я не ошибаюсь). K>Он только с Vista (или XP? не помню), а у меня поддерживается все с Windows 98. C версии 1.50 только с Win 2000. Придется делать default в зависимости от версии. Но сделать можно конечно.
Да, скорее всего, Consolas начался с Vista, я помню, что на один комп с XP я его кидал вручную, забирал от win7. Но он в любом случае может быть на машине, та же студия его ставит при своей инсталяции (вроде бы).
Я почему обратил на это внимание. Я когда первый раз запустил редактор заметил, что отрисовка слегка неважнецкая (но в целом, нормальна), особенно на фоне софта, запущенного рядом. Я сразу сообразил, что нужно смотреть настройки шрифта (кстати, а настройки шрифта по умолчанию не на поверхности лежат, нужно чуть покопаться), но кто-то может не подумать из тех, кто скачал редактор "на посмотреть", может чуть испортить себе впечатление. Тут ещё и про высоту шрифта по умолчанию надо подумать, например, лично мне с Consolas на своей машине приятнее работать в 11, а не в 10 размере.
А вообще-то, уже пора свой фирменный шрифт в поставке вместе с редактором предоставлять, как делают некоторые редакторы под маком, например, Espresso (если я не ошибаюсь)
PSV>>Кстати, вот в JEdit, в отличие от эмакса и вима, сел и поехал. Привыкать год ненужно. И мышкой, и клавой (без мыши) работать вполне удобно (но всё-таки, иногда проще мышкой тыкать), и всякие тулбары с кнопками не нужны, я даже не включаю традиционные tab-ы для переключения буферов, эти здоровые "combobox-ы" вверху буфера удобнее их (хотя можно сделать ещё удобнее). K>А если надо видеть все файлы сразу (табы тоже несут информационную нагрузку: изменен, блокирован, UAC) или переключиться в один клик? combo — вопрос спорный. K>Тулбары с кнопками удобны для редких, но все же используемых функций и для более простого освоения интерфейса.
Тут, похоже, сказывается то, что я уже стал сторонником спартанского минимализма в интерфейсе и приверженцем большего использования клавиатуры, чем мыши. Всё-таки удобно во время работы с текстом поменьше дёргаться к мыше или ковыряться в неудобных тачпадах. Но и мышей иногда проще возиться, когда мало редактируешь, что-то смотришь, листаешь, изучаешь и т.д., но такой режим работы относительно не частый, поэтому я все кнопочные тулбары поотключал, изредка несложно в меню мышкой клацнуть.
А эти табы для переключения буферов какие-то неудобные для меня, и не только в редакторах, а и в инет-броузерах всяких. Они становятся не информативными и слишком маленькими, когда их много, или появляется неудобная их прокрутка, или в два и более этажа их пытаются лепить. Они как-то непрактично смотрятся, если они не вверху окна, а где-то внутри, как заголовок буфера при сплите.
Плюсы "combo" в JEdit: рядом с именем файла виден его путь, откуда файл, удобно работать клавиатурой (клацнул — раскрыл список, или жмёшь вверх/вниз/pageUp/Down и пр. или ввёл пару букв и через быстрый поиск переключился куда надо), и мышкой нормально: клацнул в любом месте (не только на кнопку справа) — раскрыл список и выбрал (но не в один клик получается). Причём список буферов удобный: рядом пути, есть индикация об измененности буфера (и не только в списке). Недостаток: в combo нет рядом имён других файлов. Хотя я к этому привык и как-то вполне нормально.
В качестве альтернативы можно сделать как-то так: вместо tab-ов, в их классическом виде, можно сделать их аналог, в виде по мотивам твоей Hierarchy bar, где активная "tab" будет содержать и путь к файлу (поэтому она может быть длинной), а остальные рядом без пути, только имя файла, и остальные табы не нужно лепить все, только то, что нормально влезет, пусть даже несколько штук, в случае чего лучше дорисовать какие-нибудь "...", т.е. дать понять, что на экране не всё видно. Когда на активном табе нажали мышкой, или только навели курсор, раскрывается список с файлами (как в JEdit, т.е. с путями рядом и пр.) и можно выбрать мышкой. Т.е. такой себе симбиоз tab с combo.
Одним словом, у меня есть уже всякие разные взгляды и концепции по поводу удобного редактора, как раз в спартанском стиле по мотивам ранее указанного Light Table, с мощными автокомплитами, "режимами форм и сниппетов", "EasyMotion" для многих случаев и т.д., причём это всё не только для самой текстовой панели. Но это отдельная философия.
Я тут специально глянул на "глубину" проработки возможности работы через клаву. Есть "недочёты", но думаю, что их "ликвидация" нафиг не нужна большинству твоих пользователей. Например, в том же JEdit как-то поудобнее возможности в File Explorer: в списке с файлами нажал влево — наверх по каталогу, "/" — в корень дерева, "-" — каталог текущего буфера и пр. клавиши, как-то лучше взаимодействие между частями — дерево каталогов и список файлов (хотя я, имхо, просто привык к тому, что есть в JEdit). Или, например, я через Ctrl-Tab переключился на Bookmarks, но сам курсор туда не попал, т.е. сам контрол-список не установил в себя фокус ввода. Аналогично и File Explorer не получает в себя куда-то фокус ввода. Или я из этого списка закладок не могу уйти без возможности активировать закладку, т.е. просто что-то нажать и без действий вернуться в панель с текстом.
Кстати, заметил баг. Через Ctrl-Tab не получается переключиться на какой-нибудь Tool Window, если этот Window является как бы активным в своей области. Т.е., например, если внизу открыть Bookmarks и Find Result, то на Find я переключусь только тогда, если активным будет Bookmarks. А если, например, слева открыт будет только File Explorer, то на него фиг переключишься. Также глючит и окошко "Windows...".
А вообще-то, я раньше говорил о плагинах для FireFox по мотивам вима и эмакса. Рекомендую их попробовать. Осваиваются легко, для реальной работы из всего арсенала нужно с пяток функций и нужно запомнить несколько шорткатов, в общем, не напрягают никак. Они помогают понять сущность вима и эмакса (после этих плагинов становится понятно как там работать), реально дают удобство. После них для каждого софта хочешь найти свой "вимператор". Эти плагины помогут понять и прочувствовать, как лучше сделать какой-нибудь автокомплит, запускалку команд, "EasyMotion" и т.д., если у тебя планируется что-то из этого (а может и самому что-то захочется, без просьб пользователей). Это:
— Pentadactyl — альтернативная ветка "вимператора" — всё по мотивам вима. Может полностью переделать интерфейс фокса, где внизу будет строка как статус-бар, куда выводится и инфа про открытую страницу, и информационные сообщения, можно свои кнопки добавить для кликанья мышью, и там же будет мощная комстрока. Есть и мощный автокомплит, и вывод многострочной инфы. Несложно расширять. Я, например, сделал себе быстрый перевод, выделенного текста на странице или через ручной ввод, всё намного удобней, чем типовые расширения для этого во многих броузерах;
— KeySnail — это по мотивам эмакса. Этот плагин не переделывает интерфейс фокса, а дополняет его: есть и комстрока с автокомплитом, похожая на то, что есть в Pentadactyl, но со своими особенностями, показывается она только по требованию. Есть и разные функции в эмакс-стиле для редактирования текста в полях ввода. Для "EasyMotion" есть отдельный суб-плагин HoK (который приятнее, чем в Pentadactyl, имхо) и что-то ещё, а также и другие полезные плагины, например, для быстрого управления закладками и пр. По умолчанию в нём раскладка клавиш как в эмаксе, но можно легко сделать любую (из коробки вроде есть и привычная "виндовская").
Одним словом, это отличный пример, как можно GUI-редактор дополнить "эмаксовыми штучками".
Вот в них можно заметить ряд "мелочных полезностей", ну, например, автокомплит не закрывается, если я клацнул где-то мышью мимо его окна, я могу при наборе команды где-то что-то выделить мышей и скопировать текст, вставить его в комстроку, или переключиться на другую вкладку, затем вернуться и продолжить ввод, и пр.
Или вот этот "EasyMotion" используется не только для манипулирования ссылками на странице, но и над всеми элементами, включая и переход м/д полями ввода и пр.
Я ещё пользуюсь удобной запускалкой программ: TypeAndRun (а также там есть и всякие функции по управлению компом, калькулятор и пр.).
Это командная строка, открываемая по центру экрана (по умолчанию), где быстро вводишь команду и выполняешь. Там есть и история ввода, и хинт с инфой над строкой, и автокомплит с выпадающим списком и пр. Вот такая строка может отлично вписаться в твой редактор, где можно организовать переключение между буферами, открытие файлов, ввод команд, т.е. функции по мотивам Sublime.
При этом можно усовершенствовать, например, так: при переключении м/д буферами используется быстрый поиск, когда я ввожу буквы, а когда нажал пробел, то начинается ввод суб-команды, например в списке автокомплита уже содержатся возможные команды (close, close outhers, move left и т.д.), а вверху в хинте — имя выбранного буфера. Т.е. я ввожу: "ad c" — две буквы чтобы выбрать буфер, пробел — начинаем субкоманду, набрал "с" — выбрал close и жму enter.
Или организовать ввод команды так: набираем буквы — вводим команду с автокомплитом, если начинаем ввод с цифры — будем повторять действие — ввели 12 и нажали пробел — закрыли комстроку и ввели 12 пробелов. Также повторения можно указать и после ввода команды через пробел, даже если есть субкоманды/параметры.
Вот такой автокомплит с комстрокой можно развить дальше и реализовать чуть ли не все основные функции по управлению и пр., как в виме/эмаксе, где всё делается в одном минибуфере (и очень удобна такая техника).
Ну и чтобы два раза не вставать, могу сказать, что ещё гармонично дополняет все выше приведенные средства:
— VistaSwitcher — удобная переключалка между окнами в системе вместо стандартной по alt-tab (через клаву и мышь);
— AnVir — управление процессами и пр., удобен также тем, что в трее возле часов можно вывести иконки-индикаторы по загрузке процессоров, ОЗУ, дисков и пр., а также дополняет стандартные диалоги в винде, например, для открытия/сохранения файлов, рядом функций, как история папок и пр.;
— ConEmu — эмулятор консоли, используется совместно с фаром. Но у меня есть небольшие подтормаживания при скроллинге в панели фара с файлами, поэтому особо не юзаю, но вещь приятная. Есть для фара ещё и другая подобная альтернатива: ConMan — менеджер консолей, т.е. в одном окне несколько консолей, но всё в обычном текстовом режиме, без GUI-примочек. Плюс к этому добавить тот плагин YAC для фара, о котором я говорил раньше, который дополняет кроме файлов и системные DosKey-макросы — получаем удобную работу с консолью, как в линухе.
Мне в ближайшие времена придётся перелазить на линукс, как основная среда при разработке, я пока даже не знаю, чем там всё это можно удобно заменить (хотя пока глубоко этот вопрос не прорабатывал).
K>Это я в этой версии обновил алгоритм wrap, для лучшей поддержки не пропорциональных фонтов. Тоже русский товарищ жаловался. Я долго забивал, а то переделал (только для небольших документов, для больших работает оптимизированный, старый вариант). Так что может что то работать не так. Скинь пример. K>Еще там же было одно изменение, что строка должна начинаться только с буквы (точнее слова), а не пробела или знака препинания, а то выглядит не кошерно. Тоже замечание от того же товарища. Так что может это оно? Если конечно не получается — то режет где попало.
Изменения, конечно, грамотные, и нужно отметить, что у тебя мощный базовый функционал в редакторе, разные шрифты и пр., далеко не в каждом редакторе встретишь такое. Я так понимаю, что расстановка переносов в словах, как в word-e, уже не за горами
Я специально "тест-дравил", набирал этот пост в редакторе, написал специально многовато, и по ходу дела "фоткал" баги. Поэтому отчёт:
Здесь слово "разрывается", когда я дальше начну набирать остальные буквы (или хотя бы одну букву), то слово перенесётся нормально.
Здесь тоже самое, но не в конце текста, а при вставке внутри предложения. Также потом перенесётся нормально при вводе остальных букв.
Здесь слово Result перенеслось, хотя явно влезало. Позже при вводе дальше оно прыгнет вверх как положено.
Перенеслась кавычка после "вимператор".
А здесь кавычка осталась, не перенеслась.
А здесь при переносе буфер не прокрутился до конца, новое слово на строке слегка виднеется, я его выделил красной рамкой. И видна только половинка по высоте индикатора текущей строки.
А здесь интересный эффект: при наборе текста последний символ, в данном случае это точка в конце, настолько приблизился к краю окна, что "вытеснил" курсор — он как бы есть, но за пределами окна, его не видно. Если нажать enter, то он появится в новой строке.
В общем, если ты понабираешь текст, то, наверное, сам что-то увидишь. Могу посочувствовать, ибо задача не простая, этот wrap.
P.S. Вроде тут обсуждение HippoEdit как-то офтопное получилось, но полезное:
— автор этой темы вроде подсел на HE;
— тебя уже здесь просят про реализацию под линукс и андроид. Скоро маководы подтянутся;
— я, конечно, не в курсе о всей инфраструктуре вокруг HE, но здесь уже на два ведра больше конструктива, чем в форуме, откуда нужно скачивать бету, где с 2009 г. всего четыре странички непонятно чего.
Re[20]: Нормальный редактор для C++ - существует ли?
Здравствуйте, MasterZiv, Вы писали:
MZ>Sorry, или ещё вот под iThings. Ну не линукс, но тоже MZ>не винда.
Честно говоря, я слабо представляю как можно эффективно программировать даже на ipad. Чтобы сделать удобный редактор под него, это не порт, это новое направление, со своими концептами, подходами и тд. Причем еще абсолютно пустая, придется все делать с нуля (иметься в виду, специфика написания текстового редактора для программиста).
Под linux/unix там вроде бы понятнее, но вопрос мой был не в этом. А в том, отобьются ли эти труды финансово? Сомневаюсь. Можно было бы подумать про маки, но там уже тоже конкуренция есть, и пока подтянешься, будешь опять в хвосте. HippoEDIT это все же shareware (да бесплатная для exUSSR не коммерческого использования). Заниматься портированием из чистого альтруизма у меня желания нет. Я с большим удовольствием потрачу это время на развитие редактора под Windows. Да, наверное, если бы начинал сейчас, писал бы кросс-платформенно, а переделывать сейчас — слишком много работы.
Re[21]: Нормальный редактор для C++ - существует ли?
Здравствуйте, alex_public, Вы писали:
_>Да, может быть ещё разница потому что у меня на этой машине старый IE. Просто сам chm (вне редактора) открывается нормально и другие chm (в редакторе уже) открываются тоже нормально. Т.е. это как бы единственное такое исключение.
Посмотрел, что мог поправил. Хотя протестить не вышло. Теперь если и будут левые окна, то у них будет таб и они не перекроют текущий документ.
Еще поставил броузеру Silent mode чтобы не выбрасывал popups при ошибках.
Будет в новом обновлении.
Думал сделать подсветку поискового слова, но потом передумал — это замедлит открытие, и нафиг не надо..
Re[21]: Нормальный редактор для C++ - существует ли?
> Честно говоря, я слабо представляю как можно эффективно программировать даже на > ipad. Чтобы сделать удобный редактор под него, это не порт, это новое > направление, со своими концептами, подходами и тд. Причем еще абсолютно пустая, > придется все делать с нуля (иметься в виду, специфика написания текстового > редактора для программиста).
На iMac ? Я его имел в виду больше.
> Windows. Да, наверное, если бы начинал сейчас, писал бы кросс-платформенно, а > переделывать сейчас — слишком много работы.
А на чём написано ? (чисто любопытно).
Posted via RSDN NNTP Server 2.1 beta
Re[20]: Нормальный редактор для C++ - существует ли?
> Кстати огромная разница. Допустим наш софт переносится на нормальный linux и на > osx простой перекомпиляцией. А под андроид фиг такое выйдет — надо обязательно > переделывать интерфейс, да ещё и на этой кривой яве.
Вроде там можно нативные приложения заставлять работать.
Не знаю, как, но можно. Ну ладно, не важно.
Posted via RSDN NNTP Server 2.1 beta
Re[2]: Нормальный редактор для C++ - существует ли?
Здравствуйте, PSV100, Вы писали:
PSV>Можно ещё JEdit глянуть. Сейчас им мало кто пользуется, но, имхо, зря. Он на джаве, но на порядки легче и быстрее эклипсов с нетбинсами.
Пользуюсь JEdit, потому как приходится работать в разных ОС с разными компиляторами для разных платформ. Собираю системой, основанной на Jam. Первое время, как стал пользоваться, ужасно напрягало отсутствие подсветки ошибок и автодополнения. Сейчас ничего, привык вроде.
Но, вот недавно надо было поковырять проект на студии... Студия + асистикс казалась просто сказочной по сравнению с JEdit...
Очень не нравится отсутствие возможности компилировать прям из редактора с последующим даблкликом по ошибке и переходом на сторку, ее содержащую. Существует ли такой плагин?
Re[21]: Нормальный редактор для C++ - существует ли?
Здравствуйте, MasterZiv, Вы писали:
MZ>Вроде там можно нативные приложения заставлять работать. MZ>Не знаю, как, но можно. Ну ладно, не важно.
Там есть ndk. Так что грубо говоря весь движок можно просто перетащить (перекомпиляцией), а вот интерфейс всё равно придётся на java переписывать. В случае многих проектов это может быть просто. Но в случае подобного редактора, где по сути всё на интерфейс завязано...
Re[22]: Нормальный редактор для C++ - существует ли?
Здравствуйте, MasterZiv, Вы писали:
MZ>На iMac ? Я его имел в виду больше.
Ну там уже TextMate, BBEdit, Sublime, и думается мне куча всего на Scintilla (хотя про Mac OS я не в курсе, знаю что под Limux она точное есть, значит скорее всего и под Unix).
Ну в общем я уже ответил почему, в пред-идущем топике.
MZ>А на чём написано ? (чисто любопытно).
C++, MFC, VS2005.
Re[27]: Нормальный редактор для C++ - существует ли?
Здравствуйте, PSV100, Вы писали:
PSV>А вообще-то, уже пора свой фирменный шрифт в поставке вместе с редактором предоставлять, как делают некоторые редакторы под маком, например, Espresso (если я не ошибаюсь)
Да ну нафиг . Чужой шрифт вставлять — не хорошо, а свой надо еще написать... Пока просто убрал шрифт по умолчанию из базовой схемы и определяю динамически, если есть Consolas — беру его. Нет — Courier New. Только для новых пользователей.
PSV>А эти табы для переключения буферов какие-то неудобные для меня, и не только в редакторах, а и в инет-броузерах всяких. Они становятся не информативными и слишком маленькими, когда их много, или появляется неудобная их прокрутка, или в два и более этажа их пытаются лепить. Они как-то непрактично смотрятся, если они не вверху окна, а где-то внутри, как заголовок буфера при сплите. PSV>Плюсы "combo" в JEdit: рядом с именем файла виден его путь, откуда файл, удобно работать клавиатурой (клацнул — раскрыл список, или жмёшь вверх/вниз/pageUp/Down и пр. или ввёл пару букв и через быстрый поиск переключился куда надо), и мышкой нормально: клацнул в любом месте (не только на кнопку справа) — раскрыл список и выбрал (но не в один клик получается). Причём список буферов удобный: рядом пути, есть индикация об измененности буфера (и не только в списке). Недостаток: в combo нет рядом имён других файлов. Хотя я к этому привык и как-то вполне нормально. PSV>В качестве альтернативы можно сделать как-то так: вместо tab-ов, в их классическом виде, можно сделать их аналог, в виде по мотивам твоей Hierarchy bar, где активная "tab" будет содержать и путь к файлу (поэтому она может быть длинной), а остальные рядом без пути, только имя файла, и остальные табы не нужно лепить все, только то, что нормально влезет, пусть даже несколько штук, в случае чего лучше дорисовать какие-нибудь "...", т.е. дать понять, что на экране не всё видно. Когда на активном табе нажали мышкой, или только навели курсор, раскрывается список с файлами (как в JEdit, т.е. с путями рядом и пр.) и можно выбрать мышкой. Т.е. такой себе симбиоз tab с combo.
Я думаю — это вопрос вкуса, и спорить об этом бессмысленно. Если бы combo были так круты, мы бы их видели, по крайней мере чаще
У меня есть нормальный Tab Switch Window (Ctrl+Tab и не отпускать Tab, думаю ты уже нашел). Она перекрывает все то что есть в combo: там и список, и индикации и быстрый поиск (если не отпускать Ctrl и набирать часть имени) и данные по выделенному файлу в Details. Screenshots вставлять не хотел — не нравиться.
Полный путь файла, при желании, можно включить для показа в заголовке главного окна. Ну и Navigation Bar иногда показывает.
PSV>Одним словом, у меня есть уже всякие разные взгляды и концепции по поводу удобного редактора, как раз в спартанском стиле по мотивам ранее указанного Light Table, с мощными автокомплитами, "режимами форм и сниппетов", "EasyMotion" для многих случаев и т.д., причём это всё не только для самой текстовой панели. Но это отдельная философия.
Несомненно
PSV>Я тут специально глянул на "глубину" проработки возможности работы через клаву. Есть "недочёты", но думаю, что их "ликвидация" нафиг не нужна большинству твоих пользователей. Например, в том же JEdit как-то поудобнее возможности в File Explorer: в списке с файлами нажал влево — наверх по каталогу, "/" — в корень дерева, "-" — каталог текущего буфера и пр. клавиши, как-то лучше взаимодействие между частями — дерево каталогов и список файлов (хотя я, имхо, просто привык к тому, что есть в JEdit).
Записал.
PSV>Или, например, я через Ctrl-Tab переключился на Bookmarks, но сам курсор туда не попал, т.е. сам контрол-список не установил в себя фокус ввода. Аналогично и File Explorer не получает в себя куда-то фокус ввода. Или я из этого списка закладок не могу уйти без возможности активировать закладку, т.е. просто что-то нажать и без действий вернуться в панель с текстом.
Это похоже баг 1.50, в 1.49 там все работало корректно.
PSV>Кстати, заметил баг. Через Ctrl-Tab не получается переключиться на какой-нибудь Tool Window, если этот Window является как бы активным в своей области. Т.е., например, если внизу открыть Bookmarks и Find Result, то на Find я переключусь только тогда, если активным будет Bookmarks. А если, например, слева открыт будет только File Explorer, то на него фиг переключишься. Также глючит и окошко "Windows...".
Тоже новый "баг" — я эту часть переделывал на плагины, так что могло поломаться — поправлю.
А так переходить между активным документом и панелями можно и шоткатам: команда View.ActiveDocument и View.FileExplorer и тд.
PSV>А вообще-то, я раньше говорил о плагинах для FireFox по мотивам вима и эмакса. Рекомендую их попробовать. Осваиваются легко, для реальной работы из всего арсенала нужно с пяток функций и нужно запомнить несколько шорткатов, в общем, не напрягают никак. Они помогают понять сущность вима и эмакса (после этих плагинов становится понятно как там работать), реально дают удобство. После них для каждого софта хочешь найти свой "вимператор". Эти плагины помогут понять и прочувствовать, как лучше сделать какой-нибудь автокомплит, запускалку команд, "EasyMotion" и т.д., если у тебя планируется что-то из этого (а может и самому что-то захочется, без просьб пользователей). Это:
Я не пользуюсь Firefox (сижу на Chrome и Opera) Но видишь, у тебя ориентация в основном на чисто клавиатурное управление, на подобие emacs/vim. А это в принципе не моя аудитория. Хотя некоторые идеи интересны и могут гармонично вписаться: как тот же EasyMotion или различные варианты командной строки. Но пока это для меня не приоритет. Все примеры записал (спасибо), но копаться глубоко пока не буду. Вернусь, когда дойдут руки до имплементации чего то подобного.
K>>Это я в этой версии обновил алгоритм wrap, для лучшей поддержки не пропорциональных фонтов. Тоже русский товарищ жаловался. Я долго забивал, а то переделал (только для небольших документов, для больших работает оптимизированный, старый вариант). Так что может что то работать не так. Скинь пример. K>>Еще там же было одно изменение, что строка должна начинаться только с буквы (точнее слова), а не пробела или знака препинания, а то выглядит не кошерно. Тоже замечание от того же товарища. Так что может это оно? Если конечно не получается — то режет где попало.
PSV>Изменения, конечно, грамотные, и нужно отметить, что у тебя мощный базовый функционал в редакторе, разные шрифты и пр., далеко не в каждом редакторе встретишь такое. Я так понимаю, что расстановка переносов в словах, как в word-e, уже не за горами
Да, в принципе можно, Hunspell (используемый в Spell Checker) — это может. Но пока не планировал: не знаю как будет выглядеть hyphenation в исходных кодах
PSV>Я специально "тест-дравил", набирал этот пост в редакторе, написал специально многовато, и по ходу дела "фоткал" баги. Поэтому отчёт: PSV>В общем, если ты понабираешь текст, то, наверное, сам что-то увидишь. Могу посочувствовать, ибо задача не простая, этот wrap.
Большое спасибо за тест — постараюсь все поправить. Это в принципе новая имлементация, так что проблемы могут быть. В старой wrap делался по количеству символов, что работает нормально в моно-размерном шрифте, а сейчас по реальному размеру на экране, чтоб поддерживать и пропорциональные шрифты. Хотя по правде говоря, все равно, когда то придется переделывать все на Uniscribe, для нормальной поддержки редактирования Unicode текстов.
Может если писать что то новое, вариант Light Table не плох и там со временем можно будет решить все проблемы, но переделать существующий проект под его стиль — неблагодарный труд.
