Здравствуйте, ML380, Вы писали:
ML>Пользуюсь JEdit, потому как приходится работать в разных ОС с разными компиляторами для разных платформ. Собираю системой, основанной на Jam. Первое время, как стал пользоваться, ужасно напрягало отсутствие подсветки ошибок и автодополнения. Сейчас ничего, привык вроде. ML>Но, вот недавно надо было поковырять проект на студии... Студия + асистикс казалась просто сказочной по сравнению с JEdit... ML>Очень не нравится отсутствие возможности компилировать прям из редактора с последующим даблкликом по ошибке и переходом на сторку, ее содержащую. Существует ли такой плагин?
Лично я JEdit не использую именно для разработки под C++ (кроме как посмотреть код, небольшие локальные правки и т.п.), поэтому дать чёткие конкретные рекомендации по поводу C++ не могу. Могу лишь расписать общую картину в JEdit для разработки (вдруг и кому-то ещё что-то пригодится).
JEdit всё-таки не IDE, а универсальный текстовый редактор общего назначения, который из коробки от блокнота недалеко ушёл. Чтобы организовать какую-то IDE, есть, фактически, типовой наборчик плагинов:
— SideKick — это базовое API для реализации "маленького Эклипса": здесь основа для синтаксического разбора, автокомплита, броузер кода и т.д. Многие плагины реализованы с его использованием, или если он есть в наличии, то делают некоторые дополнительные функции (например, подсвечивают места в коде через чёрточки возле вертикального скроллбара и пр.)
— XML — это плагин как яркий пример использования SideKick. Позволяет комфортно работать с XML/HTML, где есть и автокомплит, и ошибки светятся по ходу дела (при вводе текста), и есть показ структуры документа и т.д. Может быть полезен при конфигурировании какого-нибудь синтакс-моде (настройки для синтаксиса), всяких опций для плагинов (которые в XML, например, для Console — о нём ниже) и т.д.
Есть плагины-аналоги и для работы с некоторыми другими языками, но для C++ пока такого нет, ибо тяжело реализовать полноценный разбор C++-кода (вроде были разные попытки, и мысли прикрутить парсинг от Нетбинс, но результатов нет).
— Console — плагин, который организовывает системную консоль (команды ОС), консоль для BeanShell и любые другие консоли для прочих плагинов. А также он позволяет запускать внешние тулсы и обрабатывать/показывать их результат, в том числе и ошибки выводит и в коде их подсветит. Это то, что тебе нужно. Плагин гибко настраивается, из коробки есть что-то и для ряда популярных С++-компиляторов, если покопаться на оф. сайте или в инете, то можно понаходить настройки для всякого известного. Но ничего сложного нет для самостоятельной настройки, главное понимать ключи запуска для тулзовины и как обработать её вывод.
— ErrorList — этот плагин как раз для показа ошибок и переходов по ним. Используется в т.ч. и плагином Console.
— TaskList — подобный плагин, но для показа TODO-меток и много всего, что настроишь себе.
— ProjectViewer — тоже популярная вещь: управление проектами (если оно нужно). Частенько этот плагин используется и другими для многих функций.
— CtagsSideKick, CtagsInterface, ClassBrowser, CscopeFinder, GlobalPlugin, CodeHelper и пр. — это какие-то помощники для работы в т.ч. и для с С++, в основном, через ctags, cscope, Global. Я подробно с ними не разбирался, конкретно ничего не скажу о них.
— AStylePlugin, Beauty — ещё помощники для форматирования кода.
— Completion, CamelComplete, TextAutocomplete, FinishHim — помощники для альтернативного автокомплита.
— ConfigurableFoldHandler, FoldViewer, CandyFolds — настройка своего фолдинга.
— WhiteSpace — показ пробелов с табами и пр.
— SuperAbbrevs — шаблоны кода по мотивам сниппетов а-ля TextMate.
— FirstMate — примочки из TextMate, автообрамление скобками, кавычками и пр.
— TextTools — операции над текстом (transpose, sort и многое др.)
— TextObjects — выделение текстовых объектов (включая и для быстрого перехода)
— TextFilter — выполнение внешних команд и замена текста на их результат.
— JDiffPlugin — удобная сравнивалка файлов.
— QuickOpen, FastOpen, SmartOpen — быстрое открытие файлов по мотивам TextMate (из проекта, из каталогов).
— EditorScheme — цветовые схемы.
— MetalColor, LookAndFeel, Substance — внешний вид редактора.
— FindFile — поиск в файлах.
— SQL, DBTerminal — работа с SQL-базами.
И есть ещё куча весьма полезных для многих случаев плагинов, всё находится на оф. сайте здесь или доступно из Plugin Manager. Также в инете можно что-то найти, например, есть мало известный плагин PelczarSql — хорошая альтернатива для плагина SQL, какой-то поляк написал для своих нужд, там нет документации, но и так всё понятно и хорошо работает. Кроме этого, есть куча макросов (на оф. сайте и в прочем инете) для всего, что душе угодно.
Но, если от самого текстового редактора, как такового, ничего больше не нужно, что есть в каком-нибудь NotePad++, то есть смысл рассмотреть вариант использования Эклипс с Нетбинсом, именно в рамках IDE для С++ у них функционал, конечно, шире.
Re[28]: Нормальный редактор для C++ - существует ли?
Здравствуйте, Kefir, Вы писали:
PSV>>А вообще-то, уже пора свой фирменный шрифт в поставке вместе с редактором предоставлять, как делают некоторые редакторы под маком, например, Espresso (если я не ошибаюсь) K>Да ну нафиг . Чужой шрифт вставлять — не хорошо, а свой надо еще написать... Пока просто убрал шрифт по умолчанию из базовой схемы и определяю динамически, если есть Consolas — беру его. Нет — Courier New. Только для новых пользователей.
А что старым пользователям делать? Дискриминация ?! Тебе "буржуи" ещё про "неполиткорректного бегемота" по случаю напомнят !!! (Это шутка, понятно, что имеется в виду первичные настройки редактора, когда в системе ещё нет сохраненных опций).
А шрифт свой писать — тут до пенсии работы точно хватит...
K>Я думаю — это вопрос вкуса, и спорить об этом бессмысленно. Если бы combo были так круты, мы бы их видели, по крайней мере чаще
Эти combo мы бы увидели чаще, если бы их в своё время взяли бы на вооружение инет-браузеро-строители. А весь тот "поток сознания" из прошлого поста задумывался не для каких-то споров, а фактически, просто нужно было о чём-то писать для тест-драйва редактора, одним словом, хоть какие-то полезные (надеюсь) мысли из себя выдавил (и заодно от основной работы отвлёкся, где мозги немного уже кипят).
K>У меня есть нормальный Tab Switch Window (Ctrl+Tab и не отпускать Tab, думаю ты уже нашел). Она перекрывает все то что есть в combo: там и список, и индикации и быстрый поиск (если не отпускать Ctrl и набирать часть имени) и данные по выделенному файлу в Details. Screenshots вставлять не хотел — не нравиться.
Ну вот, это хороший пример, что в редакторе не только всё на мышекликанье рассчитано, значит, пользователи чего-то хотят (особенно, после Оперы и прочих броузеров). А в прошлый раз я так, к слову, привёл пример, где через комстроку, по подобию TypeAndRun, можно заменить/дополнить функционал Ctrl-Tab, "Windows...", "Commands Hint" и пр. Откровенно говоря, у меня от "Commands Hint" уже глаза разбегаются, а ведь он намечается расширяться, и макросы туда же нужно вставлять. Если есть комстрока, то я, например, могу набрать "tab" и редактор сможет вывалить все команды, которые он нашёл (и не только по первым буквам), вместо общего списка сразу всех команд, которые частично хоть и становятся недоступными (затеняются) при наборе букв, но всё-равно окно информационно перегружено.
А так да, я с тобой согласен с тем, что нужно позволять эффективно работать и мышью (и кое-какие мысли есть по этому поводу, т.е. как эффективно соединять клаву и мышь в редакторе, но идеи пока сумбурные). Но есть ещё один момент: мне кажется, что мышь, как таковая, относительно скоро уже может отойти на второй план. Развитие планшетов и им подобных однозначно повлияет и на передел типовых интерфейсов, и на появление новых устройств для ввода данных и пр. Уже даже винда склонна к новым веяниям, с её metro-фантазиями. Когда устаканятся технологии по поводу жестов, то они (жесты и прочие техники управления) станут типовыми для всех платформ, как мышь в своё время. Кроме сенсорных экранов появятся и отдельные клавиатуры с нормальными и, дай бог, удобными всякими multitouch-ами, т.е. заменители сенсоров. В этих новых интерфейсах заметно, что кликать принято на относительно большие элементы (кроме всяких "шевелений" туда-сюда) и немало рассчитано на непосредственный ввод букв (ибо сенсорная клава позволяет набирать текст рядом с тыканием/шевелением). Это всё будет перенесено и на "обычный десктоп".
Короче говоря, имхо, уже сегодня об этом нужно подумывать, ибо не за горами дело. Metro-винда всего лишь небольшой переходной этап. И в целом, в десктоп-операционках явно прослеживается стремление к "планшетности", как минимум, скоро уже нужно будет проектировать типовое меню для своего приложения, чтобы оно "светилось" в стандартной "панели задач" операционки по её правилам, делать поддержку стандартного системного автокомплита для своей программы и т.д. Одним словом, "убунто-мания" будет стандартным явлением.
И кстати, имхо, Screenshots в Ctrl-Tab действительно не нужен. Это в Опере можно по визуальному восприятию как-то понять отличия содержательной части разных интернет-страниц, но в текстовом редакторе, когда фактически везде "текстовая картинка" — как-то не очень (ну разве что-то по разной цветовой схеме — светлая и темная, но такое сочетание рядом для глаз тяжеловато). Мне понравилась идея в Sublime: фоново показывать потенциальный новый буфер внутри активного (при переключении/открытии файлов), если отказались от открытия/переключения, то восстанавливаем исходное. Для "продвинутого" редактора я бы сделал явное подчёркивание того момента, что мы в процессе выбора файлов делаем именно "превью": как-то можно вписать картинку в картинку — т.е. этот превью оформлять как бы внутри буфера, где изображение превью будет чуть меньше, чем границы буфера, здесь можно типовые тени добавить для окошка превью и т.п. Но есть один момент: специально автокомплит сделан вверху окна, чтобы не перекрывать картинку превью.
K>Полный путь файла, при желании, можно включить для показа в заголовке главного окна. Ну и Navigation Bar иногда показывает.
Тут как раз про область заголовка окна для вывода содержательной информации, имхо, лучше уже забывать по выше описанным причинам. И сейчас заголовок окна как-то не очень привлекателен для вывода данных (особенно при Full Screen, когда его (заголовка) нет в большинстве софта), туда обычно мало смотрят (это сугубо мой личный вывод, по своему софту). А при сплошных "убунтах" заголовок окна должен будет быть компактным, чтобы он нормально вписался в какую-нибудь "панель задач" (ибо в большинстве случаев приложения всегда будут "максимизированы" и без явного заголовка, и, дай бог, чтобы хоть где-то писалось, что за окно открыто), а также нужен небольшой заголовок для системного автокомплита/переключения м/д приложениями. Придётся в какой-нибудь Navigation Bar или Statusbar писать всё по полной программе (постоянно всё обновляя, включая и вывод сообщений).
K>А так переходить между активным документом и панелями можно и шоткатам: команда View.ActiveDocument и View.FileExplorer и тд.
Могу полезняшку подсказать: можно, кроме прямого View.FileExplorer и ему подобного, сделать так, как я настроил в JEdit, например:
"Ctrl+E влево" — перешли на dock-панель слева, с которой там в последней раз работали
"Ctrl+E Ctrl-влево" — открыли/закрыли панель слева, но не переходя туда (т.е. что-то временно подсмотреть)
"Alt-Home" — установка курсора в активный буфер, где мы были в последний раз (наверное, это аналог View.ActiveDocument)
"Alt-End" — установка курсора в последнюю активную dock-панель, с любой стороны, т.е. где мы последний раз были.
Последние шорткаты "Alt-Home" и "Alt-End" гармонично соседствуют с Alt-PageUp/PageDown — переключение между сплит-буферами, а также и с Ctrl-PageUp/PageDown — переключение м/д буферами (след./пред.). В JEdit неплохи и остальные функции по поводу dock-панелей (и с буферами тоже), например, F12 — убрать/восстановить все dock-панели, сохранение/переключение состояния по мотивам перспектив в Эклипсе и пр.
K>Я не пользуюсь Firefox (сижу на Chrome и Opera) Но видишь, у тебя ориентация в основном на чисто клавиатурное управление, на подобие emacs/vim. А это в принципе не моя аудитория. Хотя некоторые идеи интересны и могут гармонично вписаться: как тот же EasyMotion или различные варианты командной строки. Но пока это для меня не приоритет. Все примеры записал (спасибо), но копаться глубоко пока не буду. Вернусь, когда дойдут руки до имплементации чего то подобного.
Они, конечно, не дотягивают до функционала и удобства тех плагинов для Firefox.
Я ничего не навязываю и не буду "задалбывать": просто такие вещи реально позволяют прочувствовать, как что-то лучше реализовать для редактора, если дело реально до чего-то дойдёт.
PSV>>Изменения, конечно, грамотные, и нужно отметить, что у тебя мощный базовый функционал в редакторе, разные шрифты и пр., далеко не в каждом редакторе встретишь такое. Я так понимаю, что расстановка переносов в словах, как в word-e, уже не за горами K>Да, в принципе можно, Hunspell (используемый в Spell Checker) — это может. Но пока не планировал: не знаю как будет выглядеть hyphenation в исходных кодах
Ну да, переносы будут востребованы в лиспе, особенно . Вообще-то, я пошутил по этому поводу, и даже не обращал внимание на то, что во всяких опенофисах расстановкой переносов занимается тот же Hunspell. Конечно, будет приятно для многих, для всяких документов. В принципе, и для исходников может что-то сгодится, например, в рамках комментариев или строковых констант. Хотя для комментариев такие навороты будут нестандартны: редко кто из IDE таким может заниматься . Тут больше востребована некая функция "Paste and Format" — при вставке из клиппбоарда во внутрь комментария нужно сразу форматировать текст: разбивать строки по заданной правой границе, где нужно обрамлять символами комментария ("// ", "-- " и пр.), как было в уже имеющихся строках, или обрамлять текст звёздочками и т.д. Сейчас такое приходится делать макросами, но, в принципе, это фактически стандартная функция редактора.
Сорри за новую философию выше, но просто это новый тест-драйв редактора, пришлось "пописать".
По поводу проблемного wrap. Всё ранее описанное подтвердилось, ещё добавилось:
— иногда переносятся такие символы как точка, закрывающая скобка без пред. слова;
— иногда появляется горизонтальный скролл: последний символ как те же точки и скобки как бы вылазят за предела окна без переноса, причём за границу окна не вылазит полностью, а частично, символ на половину видно;
— иногда появляются несколько пробелов в конце строк по ходу набора текста, причём по какому сценарию — не могу понять.
Кроме этого:
— остался баг с контролом в окне Bookmarks (появляются вверху списка "пустые" строки), возможно, ты его ещё не исправлял;
— сразу после загрузки редактора, когда открываются файлы, с которыми работали в прошлый раз (восстанавливается сессия), иногда не обновляется Navigation Bar (там где Label светятся) — он пустой, нужно чего-то сделать, например, нажать любую клавишу для перемещения курсора, тогда всё обновится как положено;
— иногда при использовании Ctrl-Tab для переключения м/д буферами перед глазами что-то мелькает: похоже на то, что восстанавливается свёрнутое mdi-окно, распахиваясь на весь экран. Это возможно из-за того, что я баловался со всякими режимами для mdi-окон (пытаясь понять как ездить без шашечек ), какие-то окна я свернул, затем я максимизировал одно окно и интерфейс редактора вернулся в типовой режим, появились табы и пр. Если после этого клацать мышкой табы — всё как обычно, а если переключаться по Ctrl-Tab, то иногда, на некоторых буферах, на долю секунды мелькает восстановление mdi-окна, причём оно повторяется каждый раз на тех же буферах (т.е. как бы нет одноразового восстановления окна, или они как бы заново сворачиваются когда-то, но "сворачивание" не мелькает).
Re[29]: Нормальный редактор для C++ - существует ли?
Прошу прощения за запоздалый ответ — закрутился :/
PSV>Ну вот, это хороший пример, что в редакторе не только всё на мышекликанье рассчитано, значит, пользователи чего-то хотят (особенно, после Оперы и прочих броузеров). А в прошлый раз я так, к слову, привёл пример, где через комстроку, по подобию TypeAndRun, можно заменить/дополнить функционал Ctrl-Tab, "Windows...", "Commands Hint" и пр. Откровенно говоря, у меня от "Commands Hint" уже глаза разбегаются, а ведь он намечается расширяться, и макросы туда же нужно вставлять. Если есть комстрока, то я, например, могу набрать "tab" и редактор сможет вывалить все команды, которые он нашёл (и не только по первым буквам), вместо общего списка сразу всех команд, которые частично хоть и становятся недоступными (затеняются) при наборе букв, но всё-равно окно информационно перегружено.
Ну он не совсем для этого делался, это больше как побочный эффект Accelerators list, который срабатывает если пользователь "задумывается" держа Ctrl или Shift. Тогда появляется список шоткатов включающих Shift или Ctrl. Тоже с фильтрацией. Но эта фича — "не пошла". Много юзабилити проблем.
Комстрока наверное здесь все же удобней. Но все же не так наглядна...
PSV>Короче говоря, имхо, уже сегодня об этом нужно подумывать, ибо не за горами дело. Metro-винда всего лишь небольшой переходной этап. И в целом, в десктоп-операционках явно прослеживается стремление к "планшетности", как минимум, скоро уже нужно будет проектировать типовое меню для своего приложения, чтобы оно "светилось" в стандартной "панели задач" операционки по её правилам, делать поддержку стандартного системного автокомплита для своей программы и т.д. Одним словом, "убунто-мания" будет стандартным явлением.
Тогда надо сразу думать о языковом вводе и пальце-жестах Клавиатура тоже когда то "уйдет".
PSV>И кстати, имхо, Screenshots в Ctrl-Tab действительно не нужен. Это в Опере можно по визуальному восприятию как-то понять отличия содержательной части разных интернет-страниц, но в текстовом редакторе, когда фактически везде "текстовая картинка" — как-то не очень (ну разве что-то по разной цветовой схеме — светлая и темная, но такое сочетание рядом для глаз тяжеловато). Мне понравилась идея в Sublime: фоново показывать потенциальный новый буфер внутри активного (при переключении/открытии файлов), если отказались от открытия/переключения, то восстанавливаем исходное. Для "продвинутого" редактора я бы сделал явное подчёркивание того момента, что мы в процессе выбора файлов делаем именно "превью": как-то можно вписать картинку в картинку — т.е. этот превью оформлять как бы внутри буфера, где изображение превью будет чуть меньше, чем границы буфера, здесь можно типовые тени добавить для окошка превью и т.п. Но есть один момент: специально автокомплит сделан вверху окна, чтобы не перекрывать картинку превью.
Да — мне тоже понравилось. Я себе записал в туду. Но там все же не совсем интуитивно сделано было — когда оно показывается вместо текущего буфера (заголовок старый), как-то это непродуманно. Все же я согласен что надо подчеркнуть что это превью.
PSV>Тут как раз про область заголовка окна для вывода содержательной информации, имхо, лучше уже забывать по выше описанным причинам. И сейчас заголовок окна как-то не очень привлекателен для вывода данных (особенно при Full Screen, когда его (заголовка) нет в большинстве софта), туда обычно мало смотрят (это сугубо мой личный вывод, по своему софту). А при сплошных "убунтах" заголовок окна должен будет быть компактным, чтобы он нормально вписался в какую-нибудь "панель задач" (ибо в большинстве случаев приложения всегда будут "максимизированы" и без явного заголовка, и, дай бог, чтобы хоть где-то писалось, что за окно открыто), а также нужен небольшой заголовок для системного автокомплита/переключения м/д приложениями. Придётся в какой-нибудь Navigation Bar или Statusbar писать всё по полной программе (постоянно всё обновляя, включая и вывод сообщений).
Ну и combo это не выход, потому как там свои проблемы. Пока что не буду заморачиваться. У меня workaround есть для тех кому надо (аж два) а там посмотрим.
K>>А так переходить между активным документом и панелями можно и шоткатам: команда View.ActiveDocument и View.FileExplorer и тд. PSV>Могу полезняшку подсказать: можно, кроме прямого View.FileExplorer и ему подобного, сделать так, как я настроил в JEdit, например: PSV>"Ctrl+E влево" — перешли на dock-панель слева, с которой там в последней раз работали
Тоже думаю удобней и проще запомнить переход на определнную панель... PSV>"Ctrl+E Ctrl-влево" — открыли/закрыли панель слева, но не переходя туда (т.е. что-то временно подсмотреть)
В HE (ну и всех VS like редакторах) панели дочаться отдельно, и закрытие открытие у них отдельное. Там конечно немного не доделано, но по теории так. PSV>"Alt-Home" — установка курсора в активный буфер, где мы были в последний раз (наверное, это аналог View.ActiveDocument) PSV>"Alt-End" — установка курсора в последнюю активную dock-панель, с любой стороны, т.е. где мы последний раз были.
Хм.. я думаю здесь все же удобней переход на определенную панель. Так как все равно его изначально делать/помнить придется. Так что лучше все равно один использовать.
Подумаю, может и можно минимум открытие без фокуса добавить. Этого пока нет.
PSV>Последние шорткаты "Alt-Home" и "Alt-End" гармонично соседствуют с Alt-PageUp/PageDown — переключение между сплит-буферами, а также и с Ctrl-PageUp/PageDown — переключение м/д буферами (след./пред.). В JEdit неплохи и остальные функции по поводу dock-панелей (и с буферами тоже), например, F12 — убрать/восстановить все dock-панели, сохранение/переключение состояния по мотивам перспектив в Эклипсе и пр.
Шоткаты конечно для Windows не очень стандартны, но в HE тоже многое из этого есть: как то переключение между буферами Alt+Left/Right либо Expand любого окна (документа или tools) как в Eclipse, через меню или тулбар окна.
PSV>Ну да, переносы будут востребованы в лиспе, особенно . Вообще-то, я пошутил по этому поводу, и даже не обращал внимание на то, что во всяких опенофисах расстановкой переносов занимается тот же Hunspell. Конечно, будет приятно для многих, для всяких документов. В принципе, и для исходников может что-то сгодится, например, в рамках комментариев или строковых констант. Хотя для комментариев такие навороты будут нестандартны: редко кто из IDE таким может заниматься . Тут больше востребована некая функция "Paste and Format" — при вставке из клиппбоарда во внутрь комментария нужно сразу форматировать текст: разбивать строки по заданной правой границе, где нужно обрамлять символами комментария ("// ", "-- " и пр.), как было в уже имеющихся строках, или обрамлять текст звёздочками и т.д. Сейчас такое приходится делать макросами, но, в принципе, это фактически стандартная функция редактора.
Где то я видел (наверное в SlickEdit) фичу, которая врапила сама коментарии после изменения http://www.codeproject.com/KB/showcase/SlickEditToolsForVS.aspx.
PSV>По поводу проблемного wrap. Всё ранее описанное подтвердилось, ещё добавилось:
Я вроде все поправил и нашел причину, почему оно "прыгало". Это все из-за SpellChecker. Он добавлял свои стили, а они влияли на wrap.
PSV>- остался баг с контролом в окне Bookmarks (появляются вверху списка "пустые" строки), возможно, ты его ещё не исправлял;
Я это, что то так и не воспроизвел, хоть и так и сяк игрался.
PSV>- сразу после загрузки редактора, когда открываются файлы, с которыми работали в прошлый раз (восстанавливается сессия), иногда не обновляется Navigation Bar (там где Label светятся) — он пустой, нужно чего-то сделать, например, нажать любую клавишу для перемещения курсора, тогда всё обновится как положено;
PSV>- иногда при использовании Ctrl-Tab для переключения м/д буферами перед глазами что-то мелькает: похоже на то, что восстанавливается свёрнутое mdi-окно, распахиваясь на весь экран. Это возможно из-за того, что я баловался со всякими режимами для mdi-окон (пытаясь понять как ездить без шашечек ), какие-то окна я свернул, затем я максимизировал одно окно и интерфейс редактора вернулся в типовой режим, появились табы и пр. Если после этого клацать мышкой табы — всё как обычно, а если переключаться по Ctrl-Tab, то иногда, на некоторых буферах, на долю секунды мелькает восстановление mdi-окна, причём оно повторяется каждый раз на тех же буферах (т.е. как бы нет одноразового восстановления окна, или они как бы заново сворачиваются когда-то, но "сворачивание" не мелькает).
Не — не воспроизвел.
Бету обновил, что смог — пофиксил.
Re[30]: Нормальный редактор для C++ - существует ли?
Здравствуйте, Kefir, Вы писали:
K>Ну он не совсем для этого делался, это больше как побочный эффект Accelerators list, который срабатывает если пользователь "задумывается" держа Ctrl или Shift. Тогда появляется список шоткатов включающих Shift или Ctrl. Тоже с фильтрацией. Но эта фича — "не пошла". Много юзабилити проблем. K>Комстрока наверное здесь все же удобней. Но все же не так наглядна...
Ага, этот Accelerators list я заметил, когда "задумываешься" при нажатии. А наглядность комстроки можно улучшить. Например, в списке автокомплита сделать несколько столбцов, как в окне Commands Hint, и можно сделать настройку для комстроки, чтобы при запуске режима для ввода команд сразу показывать весь список по колонкам (плюс скроллинг, который будет "небольшим" из-за наличия столбцов). Вот в ранее указанном плагине KeySnail (эмакс для FireFox) есть такая возможность для ввода команд, только там список обычный, линейный, в один столбец, но вполне можно мышкой выбрать позицию из списка, даже большого, без ввода букв.
Я почему акцентирую внимание на наличие комстроки в редакторе. Я ничего не навязываю, но, имхо, как рекомендация, тебе без такого удобного ввода данных уже не обойтись, особенно с развитием плагино/макро-строения. И лучше эту комстроку сделать пораньше, пока всё ещё на этапе зарождения (плагины с макросами). Ведь через один интерфейс (комстрока) можно делать кучу операций, всё в одном стиле, и неплохо, если API будет несложное и доступное для простых смертных (для макросов с плагинами). Кто начнёт ваять уже сейчас всякие расширения, то он уже сможет отталкиваться от наличия комстроки, вместо изобретения своих GUI-диалогов.
А комстроки сейчас активно приживаются во многих типичных GUI-приложениях. Например, Chrome: его строка с адресом уже не только используется для ввода адреса и для поиска в инете, но и много всяких плагинов также осуществляют ввод данных через неё же. Повторюсь, что для редактора неплохо подойдут принципы из KeySnail для FireFox, или такая строка как TypeAndRun — они подходят идеологически и впишутся в имеющийся интерфейс редактора.
PSV>>Короче говоря, имхо, уже сегодня об этом нужно подумывать, ибо не за горами дело. Metro-винда всего лишь небольшой переходной этап. И в целом, в десктоп-операционках явно прослеживается стремление к "планшетности", как минимум, скоро уже нужно будет проектировать типовое меню для своего приложения, чтобы оно "светилось" в стандартной "панели задач" операционки по её правилам, делать поддержку стандартного системного автокомплита для своей программы и т.д. Одним словом, "убунто-мания" будет стандартным явлением. K>Тогда надо сразу думать о языковом вводе и пальце-жестах Клавиатура тоже когда то "уйдет".
Имхо, как раз клавиатура "уйдёт" очень нескоро. Мне кажется, что здесь есть аналог с автомобильным рулём — были попытки его заменить, мерседес как-то сделал реальный прототип, где вместо руля были два джойстика (справа и слева от сидящего водителя, всё "под рукой") — вроде реакции быстрее, лучше манёвренность и т.п., но управляется машина как-то не так, не "по-человечески", и признали, что руль пока заменить не могут.
PSV>>И кстати, имхо, Screenshots в Ctrl-Tab действительно не нужен. Это в Опере можно по визуальному восприятию как-то понять отличия содержательной части разных интернет-страниц, но в текстовом редакторе, когда фактически везде "текстовая картинка" — как-то не очень (ну разве что-то по разной цветовой схеме — светлая и темная, но такое сочетание рядом для глаз тяжеловато). Мне понравилась идея в Sublime: фоново показывать потенциальный новый буфер внутри активного (при переключении/открытии файлов), если отказались от открытия/переключения, то восстанавливаем исходное. Для "продвинутого" редактора я бы сделал явное подчёркивание того момента, что мы в процессе выбора файлов делаем именно "превью": как-то можно вписать картинку в картинку — т.е. этот превью оформлять как бы внутри буфера, где изображение превью будет чуть меньше, чем границы буфера, здесь можно типовые тени добавить для окошка превью и т.п. Но есть один момент: специально автокомплит сделан вверху окна, чтобы не перекрывать картинку превью. K>Да — мне тоже понравилось. Я себе записал в туду. Но там все же не совсем интуитивно сделано было — когда оно показывается вместо текущего буфера (заголовок старый), как-то это непродуманно. Все же я согласен что надо подчеркнуть что это превью.
Да, если сделать именно явное превью, будет по приятнее. Хотя в том же JEdit я привык, что явного превью тоже нет. Правда там всё-таки не превью, а реальное переключение на буфер, когда раскрыт "combo" и клавиатурой выбираешь вверх/вниз (т.е. по esc нет возврата на исходный буфер).
PSV>>Тут как раз про область заголовка окна для вывода содержательной информации, имхо, лучше уже забывать по выше описанным причинам. И сейчас заголовок окна как-то не очень привлекателен для вывода данных (особенно при Full Screen, когда его (заголовка) нет в большинстве софта), туда обычно мало смотрят (это сугубо мой личный вывод, по своему софту). А при сплошных "убунтах" заголовок окна должен будет быть компактным, чтобы он нормально вписался в какую-нибудь "панель задач" (ибо в большинстве случаев приложения всегда будут "максимизированы" и без явного заголовка, и, дай бог, чтобы хоть где-то писалось, что за окно открыто), а также нужен небольшой заголовок для системного автокомплита/переключения м/д приложениями. Придётся в какой-нибудь Navigation Bar или Statusbar писать всё по полной программе (постоянно всё обновляя, включая и вывод сообщений). K>Ну и combo это не выход, потому как там свои проблемы. Пока что не буду заморачиваться. У меня workaround есть для тех кому надо (аж два) а там посмотрим.
Кстати, я на практике присмотрелся к идее, что основную вспомогательную информацию выводить в строке статуса, постоянно там обновляя. Так реализовано в ранее рекомендованном Pentadactyl — вим для FireFox: строка статуса и комстрока соединены в одно целое, внизу (в статусе) светится полный адрес текущей страницы (он часто длинный, поэтому требует основное там место), туда же (вместо адреса) выводятся информационные сообщения, всё обновляется или по событиям, или через паузы (есть и история сообщений, иногда она полезна). Плюс отдельный режим, когда клацнул и вывелось полное описание, какое тебе нужно, например, в редакторе можно показывать: полный путь, положение каретки, количество выделений и сколько выделено символов и т.д. (в общем, что себе настроишь). В принципе, рациональное решение, реально удобно.
PSV>>Могу полезняшку подсказать: можно, кроме прямого View.FileExplorer и ему подобного, сделать так, как я настроил в JEdit, например: PSV>>"Ctrl+E влево" — перешли на dock-панель слева, с которой там в последней раз работали K>Тоже думаю удобней и проще запомнить переход на определнную панель... PSV>>"Ctrl+E Ctrl-влево" — открыли/закрыли панель слева, но не переходя туда (т.е. что-то временно подсмотреть) K>В HE (ну и всех VS like редакторах) панели дочаться отдельно, и закрытие открытие у них отдельное. Там конечно немного не доделано, но по теории так. PSV>>"Alt-Home" — установка курсора в активный буфер, где мы были в последний раз (наверное, это аналог View.ActiveDocument PSV>>"Alt-End" — установка курсора в последнюю активную dock-панель, с любой стороны, т.е. где мы последний раз были. K>Хм.. я думаю здесь все же удобней переход на определенную панель. Так как все равно его изначально делать/помнить придется. Так что лучше все равно один использовать. K>Подумаю, может и можно минимум открытие без фокуса добавить. Этого пока нет.
Все эти выкрутасы, конечно, для тех, кто работает через клавиатуру, и оправдываются они тогда, когда и в dock-панели можно работать без мыши. Переключение на каждую конкретную dock-панель у меня тоже имеется и без него никак, например, "Ctrl+E ` B" — броузер файлов, "Ctrl+E ` S" — SQL-explorer, "Ctrl+E ` C" — консоль и пр. (символ "`" задействован на переключениях, например, "Ctrl-`" — список буферов, "Alt-`" — список окон текущего приложения, т.е. это системная переключалка в дополнение к Alt-Tab — VistaSwitcher). Но, чтобы переключиться на конкретную dock, нужно чуть пошевелить мозгами, чтобы вспомнить под какой буквой закреплена конкретная панель, или это подсмотреть на экране (нужная буква подчёркнута в заголовке dock-а). А когда жмёшь Alt-Home, Alt-End, Ctrl-E down и пр., то это происходит мгновенно "на автомате", а в большинстве случаев на практике приходится прыгать на одну и ту же панель в/из буфера, или буфер — левая панель/нижняя панель.
K>Где то я видел (наверное в SlickEdit) фичу, которая врапила сама коментарии после изменения http://www.codeproject.com/KB/showcase/SlickEditToolsForVS.aspx.
Ты осторожнее, а то пользователи просекут и начнут доставать У меня для таких дел просто макросы — выделил текст, клацнул, отврапилось и символы комментария с отступами вставились в начале. В принципе, этого достаточно. Но если стандартная синтаксическая область так настроена делать при всех изменениях — это признак "продвинутости" редактора.
PSV>>По поводу проблемного wrap. Всё ранее описанное подтвердилось, ещё добавилось: K>Я вроде все поправил и нашел причину, почему оно "прыгало". Это все из-за SpellChecker. Он добавлял свои стили, а они влияли на wrap.
Ага, заметил, что стало лучше. Но есть моменты:
— каким-то образом иногда в конце набираемого текста появляются пробелы, что влияет иногда на wrap (слово или символ, например, "-", может рановато перенестись, но после при наборе следующего слова ранний перенос прыгнет туда, куда нужно). Скорее всего, пробелы появляются при правке где-то внутри текста, когда там всё перестраивается, но сценарий понять не могу.
Возможно причина появления пробелов такова: я при наборе текста после последнего слова ставлю пробел, готовясь к набору нового слова, но вдруг вижу место внутри набранного текста, где нужно подправить, прыгаю туда, исправляю, затем возвращаюсь на конец набираемого текста, нажимая End, но срабатывает "smart end" и курсор устанавливается именно на конец последнего слова, не на конец всего текста (т.е. не за введенный ранее концевой пробел, которого к тому же не видно по настройкам по умолчанию), я опять жму пробел и ввожу новое слово, продолжая набирать текст, где уже есть лишние концевые пробелы, иногда влияющие на wrap.
— есть переносы таких символов как точка в конце предложения, но после именно слова я не уверен, но есть точно моменты, когда точка переносится после скобки ")", т.е. скобка осталась на пред. строке, а одна точка перенеслась.
И со скобками, возможно, будет лучше, если их приравнять к таким символам как точка, запятая и т.п. Бывает, что переносится только одна скобка ")" или остается на строке одна "(".
PSV>>- остался баг с контролом в окне Bookmarks (появляются вверху списка "пустые" строки), возможно, ты его ещё не исправлял; K>Я это, что то так и не воспроизвел, хоть и так и сяк игрался.
Вот картинка:
Здесь также видно, что последней элемент в списке виднеется на половину, и там ещё есть пару закладок, при этом вертикального сколлбара нет, т.е. такое ощущение, что содержательная часть контрола сдвинута вниз относительно своего заголовка, а скроллбар работает нормально, т.е. как бы от заголовка (при большем списке закладок он появляется как положено). Так происходит после перегрузки редактора сразу же, когда восстанавливается сессия, включая и список закладок. Но происходит это не всегда, как-то зависит от набора этих закладок (бывает и при одной штуке). Но если получился такой странный набор, то на нём глюк стабильный. Закономерность понять не могу. Глюк проявляется только после перегрузки редактора и восстановления списка закладок (повторюсь, не всегда), но если этого глюка изначально нет, то в дальнейшем всё работает как нужно.
PSV>>- сразу после загрузки редактора, когда открываются файлы, с которыми работали в прошлый раз (восстанавливается сессия), иногда не обновляется Navigation Bar (там где Label светятся) — он пустой, нужно чего-то сделать, например, нажать любую клавишу для перемещения курсора, тогда всё обновится как положено;
Ещё картинка:
Здесь нет текста в Navigation Bar, т.е. вверху пустой label. Это состояние сразу же после открытия файла, бывает такое и после восстановления файла после загрузки редактора (причём курсор может быть восстановлен в любую позицию в файле, не только в самое начало). Это происходит не всегда. Достаточно "дёрнуть" курсор клавишей, или раскрыть этот список label-ов — и всё нормально. Более того — достаточно подвести курсор мыши на Navigation Bar, вылазит хинт и тут же появляется текст внутри bar-а — т.е. баг на уровне GUI: не всегда контрол себя перерисовывает, или не всегда изменяется text у контрола.
PSV>>- иногда при использовании Ctrl-Tab для переключения м/д буферами перед глазами что-то мелькает: похоже на то, что восстанавливается свёрнутое mdi-окно, распахиваясь на весь экран. Это возможно из-за того, что я баловался со всякими режимами для mdi-окон (пытаясь понять как ездить без шашечек ), какие-то окна я свернул, затем я максимизировал одно окно и интерфейс редактора вернулся в типовой режим, появились табы и пр. Если после этого клацать мышкой табы — всё как обычно, а если переключаться по Ctrl-Tab, то иногда, на некоторых буферах, на долю секунды мелькает восстановление mdi-окна, причём оно повторяется каждый раз на тех же буферах (т.е. как бы нет одноразового восстановления окна, или они как бы заново сворачиваются когда-то, но "сворачивание" не мелькает). K>Не — не воспроизвел.
Сценарий:
— открыть несколько буферов;
— переключиться, например, на первый буфер и нажать Minimize — этот буфер будет свёрнут как mdi-окно, остальные буферы тоже станут mdi-окнами, но не свёрнутыми;
— нажать "распахнуть" на любом буфере, кроме на первом, который свёрнут: вид редактора вернётся в привычный режим, вверху появятся tab-ы;
— если через клаву (например, через Ctrl-Tab или "Windows...") переключиться на первый буфер, то сначала мелькает восстановление mdi-окна, а затем происходит переключение на буфер. Если мышкой тыкать по tab-ам, то такого эффекта нет. Также нет и при Alt-Left/Right.
Re[21]: Нормальный редактор для C++ - существует ли?
В новом билде (1.50.767) добавил поддержку конфигураций. Теперь при создании User Variables можно указать к какой конфигурации они относятся. Соответственно User Variables определения есть глобальные для workspace и для проекта.
Конфигурации потом можно переключать через выпадающий список в новом тулбаре (по умолчанию скрыт), как в VS.
On 03/06/2012 12:34 AM, alex_public wrote:
> NetBeans — тормознутый, удобный (простой интерфейс), анализ кода и рефакторинг > хороши.
Таки взгромоздил это чудо на мою Ubuntu, в 12.04 его заправили и включили
в репозитории (из родной коробки оно не работает).
Ну, конечно, интерфейс -- ужас, летящий на крыльях ночи. Ну да фиг с ним, лишь
бы работало, и не тормозило, я уже на Эклипсе научен -- не всё хорошо, что красиво.
Буду пробовать.
Posted via RSDN NNTP Server 2.1 beta
Re[7]: Нормальный редактор для C++ - существует ли?
Здравствуйте, alex_public, Вы писали:
DV>>видео _>Вооот, на этом видео как раз то что мне надо. И функциональность и скорость. Ну т.е. то что надо от автодополнения. Надо ещё навигацию по файлам соответствующую (хотя при таком анализе проблем быть не должно). И собственно нормальный редактор.
Для Emacs на базе Clang сейчас есть:
* Авто-дополнение (company-clang, irony-mode, emacs-ycmd, ac-clang).
* Навигация по коду — rtags, в нём же простой рефакторинг типа rename symbol.
* Фоновый анализ и подсветка ошибок в коде flycheck-clangcheck.
* Настраиваемое форматирование — clang-format.
Для Vim тоже должны быть аналоги.
Re[8]: Нормальный редактор для C++ - существует ли?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Для Emacs на базе Clang сейчас есть: EP>* Авто-дополнение (company-clang, irony-mode, emacs-ycmd, ac-clang). EP>* Навигация по коду — rtags, в нём же простой рефакторинг типа rename symbol. EP>* Фоновый анализ и подсветка ошибок в коде flycheck-clangcheck. EP>* Настраиваемое форматирование — clang-format. EP>Для Vim тоже должны быть аналоги.
Ух какая старая темка... С тех пор многое изменилось и я сейчас перешёл на QT Creator, который неожиданно сильно развился в последнее время. К примеру он позволяет удобно делать исполнение/отладку на (мне прямо всё это надо):
— Андроиде
— удалённой линух машине
— микроконтроллере.
И при этом у него интерфейс на порядки проще всяких жирных IDE. К тому же он ещё и быстрее них и местами удобнее (один из самых удобных рефакторингов для C++, что я видел). Пожалуй единственный минус там, это использование убогих систем сборки в качестве проектных файлов. Но я это легко обошёл, используя эти файлы только для поддержки работы IDE, а собственно сборку и т.п. осуществляя своими средствами (хорошо что подобная возможность есть, в отличие от CLion). Ну и может небольшой минус ещё в том, что там идёт не 100% анализ исходников (нет фичи подчёркивания неверного кода без компиляции, как в том же Netbeans'e). Если подключить анализатор на базе Clang'a, то будет 100%, но тогда боюсь скорость перестанет быть такой молниеносной.
Да, это всё было про просто использование для C++ проектов, без библиотеки Qt и визуального редактора GUI к ней. Если предполагается их использование, то понятно, что тут QT Creator вообще вне конкуренции.
Re[9]: Нормальный редактор для C++ - существует ли?
Здравствуйте, alex_public, Вы писали:
_>Ух какая старая темка... С тех пор многое изменилось и я сейчас перешёл на QT Creator, который неожиданно сильно развился в последнее время. К примеру он позволяет удобно делать исполнение/отладку на (мне прямо всё это надо): _>... _>- удалённой линух машине
В Emacs кстати есть пакет TRAMP — позволяет удалённо (через ssh, telnet и т.д.) редактировать/копировать файлы, работать с shell'ом, даёт fuzzy completion, интерактивный grep, режим компиляции и т.д. и т.п. В том числе таким образом работает и отладка на удалённой машине (на которой Emacs не нужен — всё идёт например через ssh).
Короткий пример: http://www.youtube.com/watch?v=UjPasLGWzD0
_>И при этом у него интерфейс на порядки проще всяких жирных IDE.
Я помню смотрел QT Creator лет пять назад. На тот момент из всех C++ IDE под Linux он показал себя лучше всех, по крайней мере в состоянии из коробки.
Если продолжает в том же духе — то
_>К тому же он ещё и быстрее них и местами удобнее (один из самых удобных рефакторингов для C++, что я видел).
А какие там рефакторинги есть? Например extract function/method имеется?
_>Пожалуй единственный минус там, это использование убогих систем сборки в качестве проектных файлов. Но я это легко обошёл, используя эти файлы только для поддержки работы IDE, а собственно сборку и т.п. осуществляя своими средствами (хорошо что подобная возможность есть, в отличие от CLion).
Я помню он прекрасно работал с CMake проектами — это как раз то что я использую.
_>Да, это всё было про просто использование для C++ проектов, без библиотеки Qt и визуального редактора GUI к ней.
Да, знаю что он к QT не привязан.
Re[10]: Нормальный редактор для C++ - существует ли?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
_>>- удалённой линух машине EP>В Emacs кстати есть пакет TRAMP — позволяет удалённо (через ssh, telnet и т.д.) редактировать/копировать файлы, работать с shell'ом, даёт fuzzy completion, интерактивный grep, режим компиляции и т.д. и т.п. В том числе таким образом работает и отладка на удалённой машине (на которой Emacs не нужен — всё идёт например через ssh). EP>Короткий пример: EP>http://www.youtube.com/watch?v=UjPasLGWzD0
Это немного не тот режим. Я подразумевал, что у нас все исходники находятся на машине разработчика (и компиляция там же), а при нажатие кнопки запуска происходит загрузка итогового бинарника (возможно в виде дистрибутива, если надо) на удалённую машину и запуск там под отладчиком (с отображением всего в IDE на машине разработчика). Понятно, что всю сложную работу на самом деле реализуют ssh и gdb (т.е. можно и без IDE), но удобство даёт именно IDE.
EP>Я помню смотрел QT Creator лет пять назад. На тот момент из всех C++ IDE под Linux он показал себя лучше всех, по крайней мере в состоянии из коробки. EP>Если продолжает в том же духе — то
Ну Эклипс с Нетбинсом же кроссплатформенные.. )
_>>К тому же он ещё и быстрее них и местами удобнее (один из самых удобных рефакторингов для C++, что я видел). EP>А какие там рефакторинги есть? Например extract function/method имеется?
Меня больше радуют всяческие мелкие удобства, а не глобальные вещи. К примеру вот редактирую я объявление функции в классе (в hpp файле) и при этом около функции возникает маленькая лампочка. Я на неё нажимаю и все изменения применяются к определению функции (в cpp файле), причём включая изменения и теле функции (переименуются используемые параметры). И таких мелких удобств там много. Их даже сразу не увидишь, т.к. они не входят в формальное меню Рефакторинг. )))
_>>Пожалуй единственный минус там, это использование убогих систем сборки в качестве проектных файлов. Но я это легко обошёл, используя эти файлы только для поддержки работы IDE, а собственно сборку и т.п. осуществляя своими средствами (хорошо что подобная возможность есть, в отличие от CLion). EP>Я помню он прекрасно работал с CMake проектами — это как раз то что я использую.
Формально там 3 системы сборки:
1. qmake — убожество из библиотеки Qt.
2. qbs — их новая универсальная система. Теоретически она могла бы служить идеальным вариантом "файлов проекта", но на практике не всё так хорошо. Она пока глючная, плохо поддерживается даже самой IDE, да и синтаксис далёк от удобства.
3. cmake — более менее поддерживается для обычных проектов.
Это всё для проектов без библиотеки Qt (там qmake по любому). Да и даже для обычных проектов некоторые удобности среды (там даже просто отображение в дереве проекта разное получается) не работают с другими (не qmake) проектами. Это естественно всё речь о "настройках проекта", т.к. саму сборку можно производить чем угодно.
Re[11]: Нормальный редактор для C++ - существует ли?
Здравствуйте, alex_public, Вы писали:
_>>>- удалённой линух машине EP>>В Emacs кстати есть пакет TRAMP — позволяет удалённо (через ssh, telnet и т.д.) редактировать/копировать файлы, работать с shell'ом, даёт fuzzy completion, интерактивный grep, режим компиляции и т.д. и т.п. В том числе таким образом работает и отладка на удалённой машине (на которой Emacs не нужен — всё идёт например через ssh). EP>>Короткий пример: EP>>http://www.youtube.com/watch?v=UjPasLGWzD0 _>Это немного не тот режим. Я подразумевал, что у нас все исходники находятся на машине разработчика (и компиляция там же), а при нажатие кнопки запуска происходит загрузка итогового бинарника (возможно в виде дистрибутива, если надо) на удалённую машину и запуск там под отладчиком (с отображением всего в IDE на машине разработчика). Понятно, что всю сложную работу на самом деле реализуют ssh и gdb (т.е. можно и без IDE), но удобство даёт именно IDE.
В этом случае должно быть достаточно gdbserver.
EP>>Я помню смотрел QT Creator лет пять назад. На тот момент из всех C++ IDE под Linux он показал себя лучше всех, по крайней мере в состоянии из коробки. EP>>Если продолжает в том же духе — то _>Ну Эклипс с Нетбинсом же кроссплатформенные.. )
Я сравнивал с ними в том числе. QT Creator показал себя лучше всех.
_>Это всё для проектов без библиотеки Qt (там qmake по любому).
Один из проектов как раз использует Qt — при этом сами файлы проекта на CMake.
Здравствуйте, alex_public, Вы писали:
_>Практически уверен что получу отрицательный ответ (т.к. если бы существовал положительный, то скорее всего я бы про него уже давно знал), но всё же потрачу время на написание... А вдруг?
...
_>Требования в общем то простые: _>- простейший редактор типа Notepad++ с настройкой своих цветов для всех сущностей
...
попробуй notepad2mod из плюсов минималистичен, мгновенен. В отличие от IDEA, VS и Eclipse, HippoEdit, UtraEdit, SlikEidit, Lion и Sublime. Из минусов только под винду.
Re[8]: Нормальный редактор для C++ - существует ли?
EP>Для Emacs на базе Clang сейчас есть: EP>* Авто-дополнение (company-clang, irony-mode, emacs-ycmd, ac-clang). EP>* Навигация по коду — rtags, в нём же простой рефакторинг типа rename symbol. EP>* Фоновый анализ и подсветка ошибок в коде flycheck-clangcheck.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
_>>Это немного не тот режим. Я подразумевал, что у нас все исходники находятся на машине разработчика (и компиляция там же), а при нажатие кнопки запуска происходит загрузка итогового бинарника (возможно в виде дистрибутива, если надо) на удалённую машину и запуск там под отладчиком (с отображением всего в IDE на машине разработчика). Понятно, что всю сложную работу на самом деле реализуют ssh и gdb (т.е. можно и без IDE), но удобство даёт именно IDE. EP>В этом случае должно быть достаточно gdbserver.
Нуу в случае отладчиков консоль — это не удобство. ))) Так что речь именно о GUI, автоматике и т.п. )
_>>Это всё для проектов без библиотеки Qt (там qmake по любому). EP>Один из проектов как раз использует Qt — при этом сами файлы проекта на CMake.
Возможность собрать не означает ещё использование всех возможностей IDE.
Re[13]: Нормальный редактор для C++ - существует ли?
Здравствуйте, alex_public, Вы писали: _>>>Это немного не тот режим. Я подразумевал, что у нас все исходники находятся на машине разработчика (и компиляция там же), а при нажатие кнопки запуска происходит загрузка итогового бинарника (возможно в виде дистрибутива, если надо) на удалённую машину и запуск там под отладчиком (с отображением всего в IDE на машине разработчика). Понятно, что всю сложную работу на самом деле реализуют ssh и gdb (т.е. можно и без IDE), но удобство даёт именно IDE. EP>>В этом случае должно быть достаточно gdbserver. _>Нуу в случае отладчиков консоль — это не удобство. ))) Так что речь именно о GUI, автоматике и т.п. )
Так я и не предлагаю отлаживать через консоль, я говорю о том как связать Emacs на одной машине и отладку на другой. В самом Emacs есть вот такой режим:
Скрытый текст
_>>>Это всё для проектов без библиотеки Qt (там qmake по любому). EP>>Один из проектов как раз использует Qt — при этом сами файлы проекта на CMake. _>Возможность собрать не означает ещё использование всех возможностей IDE.
В том проекте этого хватает — весь boilerplate генерируется из схемы, от "QT IDE" требуется только "редактор форм".
Re[14]: Нормальный редактор для C++ - существует ли?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>В этом случае должно быть достаточно gdbserver. _>>Нуу в случае отладчиков консоль — это не удобство. ))) Так что речь именно о GUI, автоматике и т.п. ) EP>Так я и не предлагаю отлаживать через консоль, я говорю о том как связать Emacs на одной машине и отладку на другой. В самом Emacs есть вот такой режим:
А QtCreator не ограничивается только возможностями gdb. К примеру там можно удобно глянуть на все запущенные процессы на целевой машине и т.п...
_>>Возможность собрать не означает ещё использование всех возможностей IDE. EP>В том проекте этого хватает — весь boilerplate генерируется из схемы, от "QT IDE" требуется только "редактор форм".
Кстати, дизайнер форм есть и просто в самой библиотеке Qt. Не помню правда поддерживает ли он совсем все возможности IDE (типа автоматической генерации реакции на нажатия кнопок в наших классах), но с точки зрения создания самих форм это прямо точная копия. )))
Re[13]: Нормальный редактор для C++ - существует ли?
Здравствуйте, alex_public, Вы писали:
_>>>Это немного не тот режим. Я подразумевал, что у нас все исходники находятся на машине разработчика (и компиляция там же), а при нажатие кнопки запуска происходит загрузка итогового бинарника (возможно в виде дистрибутива, если надо) на удалённую машину и запуск там под отладчиком (с отображением всего в IDE на машине разработчика). Понятно, что всю сложную работу на самом деле реализуют ssh и gdb (т.е. можно и без IDE), но удобство даёт именно IDE. EP>>В этом случае должно быть достаточно gdbserver. _>Нуу в случае отладчиков консоль — это не удобство. ))) Так что речь именно о GUI, автоматике и т.п. )
Ну да, я про что-то подобное и говорил. Правда про IoT я что-то в тексте статьи ничего не нашёл. А для этих дел используeтся не просто gdb, а специфические инструменты типа OpenOCD.
Здравствуйте, alex_public, Вы писали:
_>Практически уверен что получу отрицательный ответ (т.к. если бы существовал положительный, то скорее всего я бы про него уже давно знал), но всё же потрачу время на написание... А вдруг?
отдельно от компилятора Visual Studio для разных платформ
CodeBlocks
CodeLite
