Comments 79
Вы планируете сделать поддержку тонкого клиента? Когда на локальной машине работает только легкий интерфейс, а все остальное на удаленной? И улучшить vim-плагин?
> Вы планируете сделать поддержку тонкого клиента? Когда на локальной машине работает только легкий интерфейс, а все остальное на удаленной?
Текущие планы такие: сейчас вот только разобрались с удаленной отладкой; в дальнейшем будем думать про удаленное открытие проекта и запуск вот тут. Каких-то конкретных дат пообещать не могу.
Глобальная идея тонкого клиента интересна и обсуждается. Но опять же ничего конкретного не можем пока предложить.
> И улучшить vim-плагин?
А что именно хотелось бы улучшить? У нас есть трекер плагина — закидывайте туда свои идеи, если они еще не там.
Текущие планы такие: сейчас вот только разобрались с удаленной отладкой; в дальнейшем будем думать про удаленное открытие проекта и запуск вот тут. Каких-то конкретных дат пообещать не могу.
Глобальная идея тонкого клиента интересна и обсуждается. Но опять же ничего конкретного не можем пока предложить.
> И улучшить vim-плагин?
А что именно хотелось бы улучшить? У нас есть трекер плагина — закидывайте туда свои идеи, если они еще не там.
Как насчет поддержки managed-C++?
Ну и наконец, если вы решите добавить новые комментарии Doxygen в код проекта, воспользуйтесь автодополнением для команд Doxygen и параметров функций. Или просто сгенерируйте шаблон документации для его дальнейшего заполнения (работает при использовании “/*”, “/!”, “///” и “//!”, при условии, что у документируемой функции имеются параметры, она возвращает значение или кидает исключение):
Это очень радует.
с одной из самых первых версий, при добавлении нового файла в проект, CLion предлагал добавлять новые файлы в таргеты CMake.
А можно где-то про это прочитать подробнее? Я недавно начал работать с CLion, но CMake редактирую вручную, не нашел каких-то автоматических функций.
Например, здесь.
Суть в том, что, когда вы создаете файл через create new class/source file/header file, в диалоге создания файла CLion предлагает обновить таргеты и даже показывает те, которые по его мнению подойдут.
Суть в том, что, когда вы создаете файл через create new class/source file/header file, в диалоге создания файла CLion предлагает обновить таргеты и даже показывает те, которые по его мнению подойдут.
Очень хочется поддержку других билд-систем. Или хотя бы ручную настройку проекта как в Eclipse. Переносить всё на CMake не вариант.
А несчастному разработчику, который героически исправляет 261 баг парсинга C++, вы молоко за вредность даёте?
Пользуясь случаем, спрошу: есть возможность полностью выключить диагностику на участке кода? Прагмами, например? Использую пару библиотек, полных шаблонной магии и C++14, код местами весь красный. Вообще, интересно было бы узнать планы по улучшению поддержки языка.
C++14 пока не поддерживается, но на какие-то изменения в этом направлении надеемся уже в следующем релизе. Более точно планы озвучим чуть позже в блоге.
Инспекшены можно отключать через правую клавишу в меню квик-фиксов, но это не работает если проблема в парсере (красный код).
Инспекшены можно отключать через правую клавишу в меню квик-фиксов, но это не работает если проблема в парсере (красный код).
А вы не могли бы пример проекта для воспроизведения закинуть к нам в трекер?
Похоже там какие-то проблемы с __used (он даже не подкрашен судя по скриншоту). А можете сделать go to dedclaration на __used? Куда будет осуществлен переход?
ок, мы завели багу — попробуем воспроизвести на своей стороне и будем изучать/править. Спасибо!
Семантическая раскраска в разработке. Не могу пока пообещать, когда что-то готовое сможем показать, но надеюсь — скоро.
Про CMake-таргеты не очень понятно. Конфигурации в CLion соответствуют таргетам в CMake, то есть как зададите в CMake, так и будет. Build All — дефолтовый CMake таргет — собирает все по умолчанию. Дальше — как настроите в CMake.
Про CMake-таргеты не очень понятно. Конфигурации в CLion соответствуют таргетам в CMake, то есть как зададите в CMake, так и будет. Build All — дефолтовый CMake таргет — собирает все по умолчанию. Дальше — как настроите в CMake.
А теперь вопрос на миллион — возможность указать кастомную папку для билда в симейк-проектах, которую у вас на трекере просили чуть ли не с первого релиза, сделали? В роадмапе было, и этого я точно ждал больше всего остального — blog.jetbrains.com/clion/2016/03/clion-2016-2-roadmap (см. «Ability to specify the build/generation output directory»)
Не успели, к сожалению. По CMake много спланировали, но ресурсов не хватило. Но фича в самых ближайших планах.
Вот прямо поддержу. Реально раздражает что при старте CLion пытается собрать проект во временной папке Windows в разделе пользователя, а там — оп кириллические символы и всё ломается. Пришлось сделать отдельную учётку. Почему нельзя сделать ключик — использовать такой-то путь для временных файлов/сборок?
Можно поменять IDE system path в качестве воркэраунда пока.
Спасибо огромное! Я так и не смог придумать запрос в поисковик по этому вопрос :)
Да, наверное это не легко. Согласна. Наш недочет. Мы поэтому добавили ссылку на вокрэраунд вот сюда
>Множество проблем было решено (в частности, та самая с command timeout)
На сколько я понимаю вы хотели делать все IDE на Kotlin. CLion написан на Kotlin, или таки C++?
Я в восторге от поддержки Doxygen, особенно от возможности вызвать справку из диалога автодополнения.
Ух, удаленная отладка это очень здорово! Спасибо за здоровскую IDE!
Кстати, есть какте-то новости или подвижки в сторону add_custom_target?
Кстати, есть какте-то новости или подвижки в сторону add_custom_target?
Такой возможности сейчас нет. Можно закинуть фича реквест в трекер.
У нас прошлым летом во время Хакатона в разработке был интересный плагин — он умел вытаскивать стиль форматирования из отформатированного кода и соответственно сохранять его в наших настройках. К сожалению, дальше Хакатона дело не ушло, и сейчас плагин в нерабочем состоянии. Но может, мы как-то попробуем его оживить.
У нас прошлым летом во время Хакатона в разработке был интересный плагин — он умел вытаскивать стиль форматирования из отформатированного кода и соответственно сохранять его в наших настройках. К сожалению, дальше Хакатона дело не ушло, и сейчас плагин в нерабочем состоянии. Но может, мы как-то попробуем его оживить.
Из отформатированного кода — это все же более общий случай. А главное — это дало нам возможность добавить целый список заготовленных стилей — Google, GNU, Qt, и другие (вот с этим релизом еще LLVM и LLDB добавили).
> Да на самом деле хватило бы и возможности назначать хоткеи для External Tools. Насколько понимаю, этого нет вообще?
Есть. Идете в настройки Keymap. Там поиском находите external tools в списке и добавляете шорткат.
> Да на самом деле хватило бы и возможности назначать хоткеи для External Tools. Насколько понимаю, этого нет вообще?
Есть. Идете в настройки Keymap. Там поиском находите external tools в списке и добавляете шорткат.
Это всё с нуля делалось? CLion ведь Clang использует? Есть ведь ровно такой же инструмент — clang-format. И заготовленные стили там есть (LLVM, Google, Chromium, Mozilla, WebKit), на основе которых тоже можно свой конфиг делать.
@kloppspb, рекомендую взглянуть на инструмент, кстати. У него информации о структуре кода больше, чем у astyle/indent, поэтому чаще адекватнее форматирует.
Платформе, в которой это все реализовано, уже более 16 лет, так что с нуля в CLion, конечно, оно не делалось. Добавлялась специфика для C/C++, это да.
А clang-format мы думаем заинтегрировать к себе
А clang-format мы думаем заинтегрировать к себе
Будет ли вестись какая-нибудь работа по оптимизации IDE? Я понимаю, что Java и всё такое, но уж слишком прожорлив Clion (да и не только Clion).
О какой прожорливости вы говорите?
Оптимизациями мы, конечно, заняты постоянно. И по памяти, и по производительности. Но если разбираться чуть менее абстрактно, то что именно вас беспокоит? И на каком проекте? Присылали ли вы нам логи/дампы, чтобы мы посмотрели, проверили, что нет каких-то ошибок/утечек/фризов?
Прошу прощения за некропостинг, но ведутся ли какие-нибудь работы по интеграции clang'овского парсера, а не Вашего самопального? Clang имеет на порядок лучшую поддержку C++, и я думаю многие согласятся с тем, что свой велосипед тут писать не совсем уместно.
Вот этот issue: https://youtrack.jetbrains.com/issue/CPP-81
Вот этот issue: https://youtrack.jetbrains.com/issue/CPP-81
Давайте по порядку.
Во-первых, этот ишью не про то. А про интеграцию clang анотатора. То есть, чтобы ошибки, которые умеет детектить clang, показывать как часть встроенных code inspections. Так в AppCode сейчас сделано для Objective-C и для Swift (там SourceKit).
Во-вторых, про clang парсер. Мы бы и рады не писать велосипед, но к сожалению, в текущем состоянии clang не подходит, чтобы решить все задачи, которые IDE ставит парсеру. Почему?
Наверное, если бы мы несколько лет назад начали работу именно с того, что допилили в clang все, чего нам не хватает, это бы решило проблему (хотя у нас нет четкой уверенности, что там легко можно все нужное реализовать — мы честно изучали вопрос). Но тогда clang еще был слишком молод. Сейчас он гораздо более «дружелюбен» к IDE, конечно.
В тоже время, у нас в компании накоплена 16-летняя экспертиза по написанию такого рода инструментов, есть архитектура, в которую наше решение встраивается легко и команда, которая с интересом этим занимается (и при этом следит за развитием clang-а и clang-based инструментов).
Надеюсь, что смогла ответить на ваш вопрос.
Во-первых, этот ишью не про то. А про интеграцию clang анотатора. То есть, чтобы ошибки, которые умеет детектить clang, показывать как часть встроенных code inspections. Так в AppCode сейчас сделано для Objective-C и для Swift (там SourceKit).
Во-вторых, про clang парсер. Мы бы и рады не писать велосипед, но к сожалению, в текущем состоянии clang не подходит, чтобы решить все задачи, которые IDE ставит парсеру. Почему?
- IDE должна работать с некорректным и неполным кодом, то есть в отличие от парсера должна восстановить дальнейший парсинг после нахождения ошибки.
- У IDE и компилятора разные требования к знаниям о путях, по которым находятся те или иные сорс-файлы (у компилятора они ниже).
- IDE необходимо знание о всем проекте. Например, чтобы иметь рефакторинг, который работает на всем проекте, а не только на открытом файле, нужен project-wide кэш символов.
- Все это добро должно работать инкрементально, чтобы IDE имела приемлемую производительность.
Наверное, если бы мы несколько лет назад начали работу именно с того, что допилили в clang все, чего нам не хватает, это бы решило проблему (хотя у нас нет четкой уверенности, что там легко можно все нужное реализовать — мы честно изучали вопрос). Но тогда clang еще был слишком молод. Сейчас он гораздо более «дружелюбен» к IDE, конечно.
В тоже время, у нас в компании накоплена 16-летняя экспертиза по написанию такого рода инструментов, есть архитектура, в которую наше решение встраивается легко и команда, которая с интересом этим занимается (и при этом следит за развитием clang-а и clang-based инструментов).
Надеюсь, что смогла ответить на ваш вопрос.
Друзья, а есть ли какие-нибудь новости про плагин CLion для IDEA? Уж очень мне нравится, как у меня сейчас разработка для python/go/ruby/php в одной среде идёт :)
К сожалению, не могу вас ничем особо порадовать, кроме тикета, за которым можно следить и получать уведомления об обновлениях. В целом мы планируем делать плагин. Но сейчас это не выглядит приоритетной задачей, а ресурсов потребует много.
Sign up to leave a comment.
Релиз CLion 2016.2: удаленная отладка, поддержка формата Doxygen, новые возможности кодогенерации и многое другое