Comments 92
Может имеет смысл попробовать современную IDE, вместо того чтобы мучаться с VIM и подобными?
Отказ от мышки повышает скорость работы с кодом в полтора-два раза. И как раз выучить приемы для работы достаточно просто.
Но как же муторно его настраивать для комфортной работы.
Но как же муторно его настраивать для комфортной работы.
Так там же заявляют vim-emulator плагин
Вы так говорите, будто в современной IDE нельзя отказаться от мышки.
Может и можно, но это сильно непросто.
Даже если получится отказаться от мышки — отказаться от использования стрелок практически невозможно.
Но вот например удобной работы с системой контроля версий и чтобы без мыши я в IDE чего-то ещё не видел. В той же Идее работа с гитом сделана ужасно. Консоль намного удобнее.
И кстати ещё раз об Идее. Вот надо поискать что-то в тексте проекта. Идея это умеет. Но только в результатах поиска придётся рыться мышкой. Такие дела. Поикать в результатах поиска тоже не выйдет. Даже банальный git grep получается удобнее, чем такой поиск потому, что результаты его работы можно отправить в less и просматривать сколько влезет и искать внутри этих результатов тоже можно.
Вот замечательно в Идее сделан поиск класса и файлов по названию. И символов по названию. Просто блеск. Но, как показывает автор статьи, воткнуть такой поиск в текстовый редактор не то чтобы совсем не сложно, но реализуемо в разумные сроки. А теперь так вообще доступно каждому, потому что автор всё за нас уже сделал.
Даже если получится отказаться от мышки — отказаться от использования стрелок практически невозможно.
Но вот например удобной работы с системой контроля версий и чтобы без мыши я в IDE чего-то ещё не видел. В той же Идее работа с гитом сделана ужасно. Консоль намного удобнее.
И кстати ещё раз об Идее. Вот надо поискать что-то в тексте проекта. Идея это умеет. Но только в результатах поиска придётся рыться мышкой. Такие дела. Поикать в результатах поиска тоже не выйдет. Даже банальный git grep получается удобнее, чем такой поиск потому, что результаты его работы можно отправить в less и просматривать сколько влезет и искать внутри этих результатов тоже можно.
Вот замечательно в Идее сделан поиск класса и файлов по названию. И символов по названию. Просто блеск. Но, как показывает автор статьи, воткнуть такой поиск в текстовый редактор не то чтобы совсем не сложно, но реализуемо в разумные сроки. А теперь так вообще доступно каждому, потому что автор всё за нас уже сделал.
UI для контроля версий часто ограничен, это верно. Но кто мешает переключиться в консоль, набрать git grep, затем назад переключиться в IDEA? Я пользуюсь Eclipse и команды для git нередко ввожу в открытом фаре (открытом с клавиатуры, конечно). Результаты отправляю не в less, а в edit:< в фаре, а там и макросы, и регекспы. Просто в IDE надо делать то, что удобно делать в IDE, а не стремиться делать абсолютно всё в одной программе.
Для git в vim отлично работает fugitive, который автор статьи как-то вскользь упомянул. В нём возможностей чуть ли не больше, чем в консольном клиенте git. grep, blame, commit, merge — что угодно, не выходя из редактора. Очень удобно.
git сам перенаправляет длинный вывод в PAGER, самому вызывать less даже не нужно.
Даже банальный git grep получается удобнее, чем такой поиск потому, что результаты его работы можно отправить в less и просматривать сколько влезет и искать внутри этих результатов тоже можно.
git сам перенаправляет длинный вывод в PAGER, самому вызывать less даже не нужно.
fugitive я всё никак не попробую. Наверное потому, что консоли пока хватает с головой. Но может это моё ретроградство, надо устроить себе неделю новых инструментов.
И да, git действительно перенаправляет длинный вывод в PAGER, тут я запутался из-за того, что в основном пользуюсь утилитой под названием ag (silver searcher), windows версия которой отстаёт чуть ли не на год. И вот она по умолчанию в less не вызывает. Кстати рекомендую, отличная штука. Если отказывались от grep в пользу ack, переход на ag для вас — острая необходимость.
И да, git действительно перенаправляет длинный вывод в PAGER, тут я запутался из-за того, что в основном пользуюсь утилитой под названием ag (silver searcher), windows версия которой отстаёт чуть ли не на год. И вот она по умолчанию в less не вызывает. Кстати рекомендую, отличная штука. Если отказывались от grep в пользу ack, переход на ag для вас — острая необходимость.
Да, ag я тоже использую. Его можно из vim вызывать с помощью плагина Ack.vim, указав ему что нужно использовать ag вместо ack:
Удобно тем, что результаты открываются в отдельном подокне vim.
Ещё есть ag для vim (просто в quicklist добавляет результаты).
git grep обычно работает быстрее ag (автор последнего признавался), и его можно из fugitive вызывать (Ggrep).
let g:ackprg = "ag"Удобно тем, что результаты открываются в отдельном подокне vim.
Ещё есть ag для vim (просто в quicklist добавляет результаты).
git grep обычно работает быстрее ag (автор последнего признавался), и его можно из fugitive вызывать (Ggrep).
Одна из первых вещей, которые я сделал, когда начал серьёзно пользоваться
git — это убрал нафиг перенаправление в PAGER, поставив core.page = cat. Мне часто нужно набрать в консоли что‐то, зависящее от вывода, перенаправленного в PAGER, но PAGER это делать мешает. Или посмотреть, что было выведено командой раньше, а что сейчас. Если мне нужен less, то написать после команды L (zsh: alias -g L='| less') не проблема, но если он мне не нужен (что чаще), то писать <code>|cat или эквивалентный alias неудобно.Дело привычки, для меня вывод в PAGER по умолчанию удобен.
Для себя повесил bindkey для "
zsh (~/.zshrc)
bash (~/.inputrc)
Для себя повесил bindkey для "
| less":zsh (~/.zshrc)
bindkey -s '^O' ' | less'
bash (~/.inputrc)
"\C-o": " | less"
Основные две проблемы с PAGER — это то, что git считает длинными командами всё («git сам перенаправляет длинный вывод» — это неправда, просто less’у можно сказать, чтобы он не возникал, если вывод не слишком длинный (= если он целиком помещается на экране)) и то, что после выхода less в терминале ничего не видно, при этом запустить команду в текущей оболочке из less не получится.
alias -g удобнее bindkey, потому что в истории останется alias и его легко удалить и заменить на что‐нибудь ещё.Обычно у меня проект открыт в нескольких окнах tmux, поэтому less устраивает. В одном окне его вывод, в другом vim/что-то ещё.
bindkey в данном случае просто вставляет строку "| less", когда вы его жмёте. То есть, в истории останется. Удалить/заменить — Ctrl-w или fc, никаких проблем.
bindkey в данном случае просто вставляет строку "| less", когда вы его жмёте. То есть, в истории останется. Удалить/заменить — Ctrl-w или fc, никаких проблем.
Да, если считать по количеству клавиш на удаление, то почти одинаково. Количество клавиш на ввод так совсем одинаково.
Кстати, zsh при использовании emacs варианта раскладки использует widget для
alias -g всё же имеет преимущество, т.к. все удобные <C-…> у меня уже заняты, да и результат выглядит компактнее. Недостаток — может испортить скрипты, загруженные после создания alias’а.Кстати, zsh при использовании emacs варианта раскладки использует widget для
<C-w>, который считает, что | следует непременно удалять вместе с предшествовавшим словом (даже если оное отделено пробелом).UFO just landed and posted this here
Вот когда ее доделают…
Пока что есть только EAP, который становится тыквой через 60 дней.
Пока что есть только EAP, который становится тыквой через 60 дней.
> Может имеет смысл попробовать мучаться с современнуюой IDE, вместо того чтобы мучаться с VIM и подобными?
fixed :)
fixed :)
Миллионы людей по всему миру платят за современные IDE явно не потому что они мазахисты и им не хватает мучений.
Лично я на столько привык к VIM, что с другими редакторами и IDE приходится мучится.
UFO just landed and posted this here
Да, я слежу за CLion, и даже был на приватной бете с ее самого начала. CLion пока что не так хорош, как другие среды Jet Brains, и немного неповоротлив. Сегодня, если бы я работал в графической среде, я бы по прежнему выбрал QtCreator, но я тоже верю, что у CLion большое будущее.
В любом случае, отвечая на ваш вопрос, я часто работаю удаленно, и мне удобно, когда я могу подцепиться по SSH, запустить Vim и работать так.
В любом случае, отвечая на ваш вопрос, я часто работаю удаленно, и мне удобно, когда я могу подцепиться по SSH, запустить Vim и работать так.
Не нужно «работать удаленно», нужно так настроить окружение, чтобы «удаленная работа» не требовалась — это само по себе даст огромный прирост в производительности, причем всем членам команды, а не только вам. Получается, вы пользуетесь vim не потому, что он удобнее, а потому, что при удаленной работе по SSH у него нет и близко никаких сколь-нибудь похожих по удобству аналогов. Т.е. перепутаны причина и следствие как бы, происходит личение симптомов, а не болезни.
Согласен, но я не хочу пользовать git и сборщиком для обслуживания корпоротивного сайта моей компании. Когда мне нужно поменять background-color в css сайта, я захожу на сервер и меняю его с помощью vim. С другой стороны, все это можно сделать и с помощью ed или nano, но с vim привычнее и быстрее получается.
А что Вам мешает запускать ssh с ключем -X и QtCreator на удаленной машине с X11 Forwarding? Или он так тормозит?
Вообще он пока не очень пригоден, тк умеет только проекты с CMake
Вы так говорите, будто vim и прочие emacs устарели.
Судя по тому, что в них практически «из коробки» (я имею в виду, в виде плагинов, которые можно установить за 10 секунд, а не как у автора топика) нет таких очевидных и нужных вещей, как поиск по символам, отладка и т.д., они и правда либо устарели (устаревают), либо же их подавляющее большинство людей используют для других целей. Как еще объяснить логически описанную автором обстановку?
Vim выбирают те, кому не нужна эта ваша «коробка», он не для беспомощных юзеров, неспособных настроить инструмент под себя. И он не старается стать bloatware-комбаином, имеющим дистрибутив в 200Мб, содержащий всё-всё-всё. Отдельные нужные фичи разрабатываются в виде плагинов и подключаются по мере надобности. И я не увидел никаких смертельных препятствий по их установке в топике.
Простите, но я не верю про «не для беспомощных юзеров». Популярные проекты обычно развиваются в сторону упрощения своего использования, потому что если сильно популярный проект сложно использовать, то рано или поздно основные усилия (даже неосознанно) начинают тратиться на поддержку пользователей (пусть даже и на ответы в листе рассылки). Представьте себя на месте разработчиков: если им приходит 100 обращений от пользователей с сообщением о неудобстве чего-то, то разработчику даже морально трудно это «что-то» не улучшить (в живом проекте). Если же жалоб на неудобство не приходит при объективном их наличии, то либо этих неудобств нет (т.е. продукт используют в контексте, где неудобства не возникают), либо же продукт не так уж и популярен на самом деле. О чем я и писал.
Я не хочу сказать, что vim плохой — он хороший. Но только используют ли его массово для написани c++-кода в здоровом проекте без боли? Судя по описанному в статье состоянию с плагинами — вряд ли массово. (А вот чтобы «разово зайти на сервер корпоративного сайта напрямую изаговнокодить поправить 1 строчку в css» — это очень даже используют, тут вопросов нет.)
Я не хочу сказать, что vim плохой — он хороший. Но только используют ли его массово для написани c++-кода в здоровом проекте без боли? Судя по описанному в статье состоянию с плагинами — вряд ли массово. (А вот чтобы «разово зайти на сервер корпоративного сайта напрямую и
Я таким образом пытался пересесть с Qt Creator на emacs. Но так и не смог настроить в последнем удобную IDE с поддержкой cmake проектов для C++. Вроде как плагинов много, но все они какие-то кривые.
А насчет интеграции с GDB, мне нравится CGDB консольная обертка с довольно приятным интерфейсом.
А насчет интеграции с GDB, мне нравится CGDB консольная обертка с довольно приятным интерфейсом.
UFO just landed and posted this here
Извините, Александр, я не увидел, или вы не написали, зачем же вам всё-таки приходится работать в VIM, а не в практически прекрасном CLion?
Ну потому, что VIM лучше, вроде очевидно.
CLion ещё очень далеко от понятия «прекрасный».
Как минимум нетривиально запустить CLion на удаленном сервере или настраивать удаленную компиляцию или что-то такое.
А зачем настраивать удалённую компиляцию с помощью IDE, когда для этого есть другие инструменты (CI)?
Например, поправить пару строк, собрать, перезапустить бинарник на серваке и подебагать его. Неочевидно как такое сделать с IDE.
Удалённая компиляция это одно, а CI совершенно другое.
Что именно вы понимаете под удалённой компиляцией, чего какой-нибудь TeamCity не может?
Ну например есть код, который надо скомпилировать, но рабочий компьютер делает это медленно. Настраиваем компилятор на другом компьютере, который только компиляцией и занимается, собираем код там, запускаем у себя. Вот так как-то.
Team City он вообще про другое.
Team City он вообще про другое.
Разве это не тоже самое, что рабочий компьютер -> commit -> TS подбирает все изменения и билдит проект?
P.S. А почему мы вообще про удалённую компиляцию говорим? Что нам мешает сделать тоже самое из CLion?
P.S. А почему мы вообще про удалённую компиляцию говорим? Что нам мешает сделать тоже самое из CLion?
Нет, не тоже самое. Прежде всего потому, что результаты появятся прямо на рабочем компьютере, как будто именно на нём шёл процесс компиляции. Ну и комитить код для каждой компиляции — несколько экстравагантно :).
Разговор про удалённую компиляцию начал не я. Я просто отметил, что это не CI. Наверняка можно CLion настроить так, чтобы он это делал. Правда наверное это нетривиальная задача. Хотя кто его знает, я больше по Идее.
Однако с IDE вообще есть одна проблема — если поддержки чего-то там нет — то остаётся только сидеть и ждать, когда она появится. Если есть привычка обходиться консолью, мощным текстовым редактором и скриптами автоматизации — такой проблемы как правило нет.
Разговор про удалённую компиляцию начал не я. Я просто отметил, что это не CI. Наверняка можно CLion настроить так, чтобы он это делал. Правда наверное это нетривиальная задача. Хотя кто его знает, я больше по Идее.
Однако с IDE вообще есть одна проблема — если поддержки чего-то там нет — то остаётся только сидеть и ждать, когда она появится. Если есть привычка обходиться консолью, мощным текстовым редактором и скриптами автоматизации — такой проблемы как правило нет.
Вот кстати не совсем согласен с тем, что «если поддержки чего-то там нет — то остаётся только сидеть и ждать». Это уж точно не про продукты JB. Ведь есть прекрасный репозиторий плагинов. Кроме того, вы можете написать и свой плагин. Это, во-первых, решит вашу текущую задачу, а, во-вторых, увеличит шанс попасть к этим парням на работу. Насколько я понимаю, JB любит хантить тех, кто делает добро для них.
И, кажется, TS всё-таки умеет удалённую компиляцию — confluence.jetbrains.com/display/TW/How+to+make+a+remote+run+from+IntelliJ+IDEA
И, кажется, TS всё-таки умеет удалённую компиляцию — confluence.jetbrains.com/display/TW/How+to+make+a+remote+run+from+IntelliJ+IDEA
Вариант «сделать самому» есть всегда и везде. Тут вопрос в трудоёмкости задачи. Вот не не нравится вам как в Идее реальзован поиск класса по имени. Хотя нет, это плохой пример, этот поиск в Идее реализован прекрасно. А вот простой поиск в идее проблемный. И хочется его заменить на другой — хороший. И как быть дальше? Подсказываю — придётся программировать.
В случае с vim или emacs стронние поисковые утилиты прикручиваются на раз. На раз же, как показал автор, прикручивается и поиск классов и методов.
Ну а прикрутить к Идее текстовый редактор типа вима — вообще задача на годы.
P. S. То, что вы показали — не совсем то. Совсем то это distcc по моему.
В случае с vim или emacs стронние поисковые утилиты прикручиваются на раз. На раз же, как показал автор, прикручивается и поиск классов и методов.
Ну а прикрутить к Идее текстовый редактор типа вима — вообще задача на годы.
P. S. То, что вы показали — не совсем то. Совсем то это distcc по моему.
Она я думаю может сделать все что нужно, но это будет неудобнее, то есть нужно либо будет както собранный пакет или во что оно там соберет копировать на рабочий сервер, либо поднимать этот TeamCity на сервере, куда нужно быстро поставить дебажную версию программы. В общем целое дело. Собрать пакет из искодников прямо на целевом сервере с нужными правками сильно проще и быстрее.
У меня кофьюз случается вот на месте «собрать пакет из исходников на сервере». Я не особо знаком со спецификой продакшен разработки на С++, но как-то это не вяжется в моей голове, когда такое придётся делать.
Как мне всегда казалось, обычно всё проходит по следующему сценарию:
Коммиты -> CI-сервер -> build -> tests -> deploy. Но, видимо, и другие жизненные циклы случаются.
Как мне всегда казалось, обычно всё проходит по следующему сценарию:
Коммиты -> CI-сервер -> build -> tests -> deploy. Но, видимо, и другие жизненные циклы случаются.
Я конкртено описывал вариант, когда нужно что-то попробовать быстро и проверить, без обычного цикла и раскатки на тысячи серваков дебажного кода.
Ну, допустим, есть у меня embedded железка с linux на борту. Мне нужно отдебажить код на ней.
Закинув туда свой конфиг от emacs'а, я получаю по SSH редактов, идентичный тому, который использую на десктопе и могу полноценно работать на той железяке.
Разрекламированный в комментах CLion я, скорей всего, на этой железке даже запустить не смогу, не то, что получить его GUI через SSH.
Закинув туда свой конфиг от emacs'а, я получаю по SSH редактов, идентичный тому, который использую на десктопе и могу полноценно работать на той железяке.
Разрекламированный в комментах CLion я, скорей всего, на этой железке даже запустить не смогу, не то, что получить его GUI через SSH.
А чего Вам удалось со всем этим зоопарком добиться принципиально такого, чего нет в Qt Creator? Всё, что Вы так упорно настраивали, там есть из коробки, а Vim-режим включается в настройках. Этот режим чего-то нужного не эмулирует?
Включив FakeVim ломается Ctrl+B, Ctrl+R (билд и запуск проекта), нельзя с клавиатуры перенести фокус в область дерева исходников, ну и в этой области FakeVim уже не работает (например навигация j,k).
Vim-режим включается в настройках. Этот режим чего-то нужного не эмулирует?
Это сложно объяснить тому, для кого «модальное редактирование», имеет два состояния: бибикать после нажатия и все портить после .
vim — единственный на сегодня редактор, делающий упор на модальное редактирование. Современные IDE очень далеко шагнули в плане рефакторинга, навигации, дополнения кода — без всего этого они просто notepad.exe, а модальный режим там реализован убого и, скорее, «для галочки». Эти notepad'ные кишки постоянно вылезают в самое неподходящее время: в коде символ «some_long_function_name», а нужно сделать из нее «some_not_so_short_name»? Жмем «f_lc2t_not_so_short», чтобы перейти к началу «long», а затем удалить все до «_» перед «name» понадобилось всего три команды:
- найти «_» (f_)
- двинуться на символ вправо (l)
- удалить весь текст до второго «_» и перейти в режим редактирования (c2t_)
Когда начинаешь воспринимать редактирование не как «удалить 20 символов», а «удалить три следующих слова» или «очистить до «)», все становится значительно быстрее и, главное, ошибок становится меньше.
Ага, только вот как-раз эта привязка к уровню слов, абзацев, поиску до ")" и является тем камнем, который тянет на дно. Я хочу мыслить более высокоуровневыми терминами. Мне не нужно текст «some_long_function_name» заменить на «some_not_so_short_name». Мне нужно в классе А переименовать пол Х в поле У, причём так, чтобы это произошло и в заголовочном файле и в файле кода, и в 28 местах других файлов, где на это поле ссылаются, с учётом полиморфизма в классах-наследниках. И при этом чтобы поле с тем же именем Х у класса B и ссылки на него не поменялись.
Ещё мне нужно вынести часть кода метода в отдельный метод. И нет, не «вырезать эти 5 строк и вставить выше», а с автоматическим выводом передаваемых аргументов и типа возврата и правкой кода.
Ну-ка расскажите, как vim со своим отличным модальным редактированием всё это сделает? А IDE справляются.
Текстовый редактор — он как раз для текста. А код — это не столько текст, сколько отображение абстракций на плоскость терминов языка программирования. Vim может быть и даёт удобные средства ползания по этой плоскости, но поднять голову вверх и взглянуть, что же за сущности отбрасывают эти тени — не позволяет.
Ещё мне нужно вынести часть кода метода в отдельный метод. И нет, не «вырезать эти 5 строк и вставить выше», а с автоматическим выводом передаваемых аргументов и типа возврата и правкой кода.
Ну-ка расскажите, как vim со своим отличным модальным редактированием всё это сделает? А IDE справляются.
Текстовый редактор — он как раз для текста. А код — это не столько текст, сколько отображение абстракций на плоскость терминов языка программирования. Vim может быть и даёт удобные средства ползания по этой плоскости, но поднять голову вверх и взглянуть, что же за сущности отбрасывают эти тени — не позволяет.
Я долго пользоват продукцию Jet Brains (даже бесплатную лицензию для OpenSource проектов от них получил), восхищался автодополнением, системой рефакторинга, даже интеграция с git нравилась. После перехода (часть проектов я все еще пишу с помощью этих IDE) на vim я понял, что проекту с хорошей архитектурой не требуется изменят имена классов, их полей, методов и аргументов, так же им не требуется выносить часть кода в другие методы и так далее. Для «чистых» проектов, я пользую Vim и ни разу у меня не возникало проблем с рефакторингом, а для «грязных» пользую IDE.
Хорошо, конечно, жить, если в проекте не меняются требования и архитектура, только где же в реальном мире такие проекты взять?
Я не говорил, что требования и архитектура не меняется, это вы сказали.
Ну ок, и как в проекте, где по требованию заказчика на 40% была изменена вообще предметная область решаемой задачи обойтись без хороших инструментов рефакторинга?
На 40%? Вытащить из проекта компоненты, которые можно использоваться в новом и написать остальное заново.
А «вытащить компоненты» — это рефакторинг и есть. Ну и плюс всё, что случается в промежутке с изменениями требований от 0 до 20%.
Нет, это не рефакторинг. Рефакторинг это изменение архитектуры или структуры программы так, что внешне она кажется неизменной.
Вот только само по себе, «в вакууме» это не происходит, а делается для дальнейшего изменения\улучшения архитектуры.
Давайте называть вещи своими именами. Как уже было сказано выше, если клиент меняет требования кардинально, то часть ваших пакетов в неизменном виде (никакие имена не меняются) переносятся в новую структуру, и функциональности рефакторинга IDE здесь не нужно. Если в процессе XP вы решили изменить архитектуру пакета, то рефакторинг даст малую прибавку к скорости.
Переименование методов и переменных? Можно найти строннюю утилиту, которая этим занимается и прикрутить к редактору. Clang, кстати, по моему может. Вон в Go вообще из коробки такой функционал.
Выделение кода в метод мне удобнее делать руками. Это не сильно трудоёмкая операция.
Но вернёмся к переименованию методов и переменных. Зачастую бывает так, что названия методов и свойств java класса используются в хитром джаваскрипте и там они никак не привязаны к самим классам и инструмент для рефакторинга их проигнорирует. И собственно всё — уверенности в безопасности рефакторинга не больше, чем в случае с вимом.
Выделение кода в метод мне удобнее делать руками. Это не сильно трудоёмкая операция.
Но вернёмся к переименованию методов и переменных. Зачастую бывает так, что названия методов и свойств java класса используются в хитром джаваскрипте и там они никак не привязаны к самим классам и инструмент для рефакторинга их проигнорирует. И собственно всё — уверенности в безопасности рефакторинга не больше, чем в случае с вимом.
UFO just landed and posted this here
Ещё мне нужно вынести часть кода метода в отдельный метод
А еще не помешало бы научиться читать и усваивать прочитанное: русским по белому было написано, что рефакторинг и навигация в IDE (пока) лучше.
Да, например, почти никто не использует Vim, чтобы писать на Java. Потому что у нее есть хорошая среда, возможности которой покрывают удобство привычного текстового редактора.
Но в С++ все эти рефакторинги работают не очень хорошо, особенно если есть templates. Поэтому привычный Vim с плагинами более чем достаточен для того, чтобы разрабатывать на С++.
Ну и добавить рефакторинги в CtrlK — это, скажем, не так сложно. Просто никто пока не сделал.
Но в С++ все эти рефакторинги работают не очень хорошо, особенно если есть templates. Поэтому привычный Vim с плагинами более чем достаточен для того, чтобы разрабатывать на С++.
Ну и добавить рефакторинги в CtrlK — это, скажем, не так сложно. Просто никто пока не сделал.
Вообще-то в одной известной IDE упомянутое вами весьма толково реализовано с помощью внешнего дополнения (где не надкушенное яблоко, а целый помидор). Равно как и в vim также можно подключать всевозможные плагины. Сейчас, конечно, они пытаются сделать свой вариант, но имхо добраться до уровня того дополнения им пока не удалось.
Единственная проблема — что конкретно толкового дополнения для рефакторинга пока нет. Но проблема, думаю, там не в vim а в маркетинге (как-то нужно будет мотивировать любителей vim купить такой плагин)
Единственная проблема — что конкретно толкового дополнения для рефакторинга пока нет. Но проблема, думаю, там не в vim а в маркетинге (как-то нужно будет мотивировать любителей vim купить такой плагин)
Ага, он не эмулирует Vim.
Эмулятор в Qt Creator слабый, но он развивается. Когда я пересаживался на vim, я открыл баги на некоторые вещи, которых тогда не хватало, их к следующему релизу добавили.
Задача была не в том, чтобы сделать лучше, чем Qt Creator, задача была в том, чтобы сделать достаточно для нормальной работы.
Как я выше сказал, один из больших плюсов Vim — это возможность зайти по SSH, запустить его и работать. Помимо этого, мне просто удобнее работать в полноценном Vim, с макросами, Easy Motion и другими плюшками.
Задача была не в том, чтобы сделать лучше, чем Qt Creator, задача была в том, чтобы сделать достаточно для нормальной работы.
Как я выше сказал, один из больших плюсов Vim — это возможность зайти по SSH, запустить его и работать. Помимо этого, мне просто удобнее работать в полноценном Vim, с макросами, Easy Motion и другими плюшками.
Понял все прелести Vim после месяца работы с ним. Теперь ощущение, что мой мозг сам принимает решения о том, как сделать манипуляции с текстом минимом клавиш. А скорость работы такая, что самое медленное в написании кода, это я, а не редактор.
Исторически сложилось так, что pip package для ctrlk принадлежит не мне. В текущем package есть две недоработки — не указана зависимость от ez_setup, ее можно разрешить рукамиЕсли вас не устраивает текущий владелец пакета, а добавить вас в качестве владельца он отказывается, то вы можете попросить людей из PyPI, чтобы они добавили вас сами: по этой ссылке я делал такое для
powerline-status.
/me никогда не умел готовить CTags, еще со времен сидения на emacs (до того был немодный gvim), и вот в чем дело: словарный автокомплит и переходы по коду оно-то умеет, но вот контекста, определения того, что можно сделать с только что введенным токеном, — у него нет. Или я ошибаюсь? )
Да, именно эту проблему и решает CtrlK, он использует libclang чтобы проиндексировать все файлы, и его же, чтобы понять контекст в текущем файле, поэтому переходы и поиск упоминаний семантические.
YouCompleteMe, плагин для автодополнения, тоже использует libclang, поэтому автодополнения у него тоже семантические, с пониманием контекста.
YouCompleteMe, плагин для автодополнения, тоже использует libclang, поэтому автодополнения у него тоже семантические, с пониманием контекста.
Не осилил установку CtrlK. Не понимаю как мне согласовать pip, vundle и мой пакетный менеджер (emerge в gentoo) — простите, питонист из меня пока плохой.
gdb-шный плагин интересный. Пальцы кровоточат от разных хоткеев переключения между окнами (ctrl-b+стрелки для tmux, winkey+«hjkl» для awesome-wm и Ctlr-o+«hjkl» для vim-а), но главное сама идея.
gdb-шный плагин интересный. Пальцы кровоточат от разных хоткеев переключения между окнами (ctrl-b+стрелки для tmux, winkey+«hjkl» для awesome-wm и Ctlr-o+«hjkl» для vim-а), но главное сама идея.
Автор плагина для GDB проблему с хоткеями частично решил, сделав, что хоткей для переключения в vim между окнами и для tmux одинаковый. При этом в виме если переключиться левее самого левого окна, он переключится в следующее окно слева в TMux. Смотрите в этом репозитории конфиг tmux, конфиг вима, и tmux_vim_intergration.sh в bin
https://github.com/ManOfTeflon/config
По-поводу CtrlK, надо сначала установить clang через пакетный менеджер, если его еще нет, затем leveldb, clang и ctrlk через pip (сейчас ctrlk должен устанавливаться без проблем), после чего добавить плагин в Vundle. Пишите в личку, если какой-то шаг не работает, помогу разобраться.
https://github.com/ManOfTeflon/config
По-поводу CtrlK, надо сначала установить clang через пакетный менеджер, если его еще нет, затем leveldb, clang и ctrlk через pip (сейчас ctrlk должен устанавливаться без проблем), после чего добавить плагин в Vundle. Пишите в личку, если какой-то шаг не работает, помогу разобраться.
cd ~/devel/my-project
mkdir build
cd build
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON ..
gvim ../src/mysource.cpp
Именно так, чтобы можно было из vim-а делать mak, не мусоря в корне проекта.
В gvim'е: CtrlK — работает как часы, от F2 и F12 никакой реакции.
F3:
Index: Initializing / Current: Initializing / Jump: normal
Что я делаю не так? И что я должен бы делать?
При попытке:
gvim мертво виснет ctrlk_server.py вот уже 7 минут жрёт 100% одного из ядер CPU и под 120Мб оперативки.
Простите, пока придётся остаться на связке Indexator+CtrlP. Но очень заинтересовали и буду рад, если починитесь.
cd ~/devel/my-project
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON ..
gvim ../src/mysource.cpp
gvim мертво виснет ctrlk_server.py вот уже 7 минут жрёт 100% одного из ядер CPU и под 120Мб оперативки.
Простите, пока придётся остаться на связке Indexator+CtrlP. Но очень заинтересовали и буду рад, если починитесь.
Все действия, которые вы сделали, выглядят правильно. Проблему попробую воспроизвести и исправить.
Пробовал на трёх разных проектах — везде одно и то же.
версии используемого ПО
☭ tmp/survey/build [devel] clang --version
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
☭ tmp/survey/build [devel] python --version
Python 2.7.7
☭ tmp/survey/build [devel] pip --version
pip 1.4.1 from /usr/lib64/python2.7/site-packages (python 2.7)
☭ tmp/survey/build [devel] gvim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 29 2014 02:48:34)
Заплатки: 1-527
С изменениями, внесёнными Gentoo-7.4.527
Скомпилирован hoxnox@localhost
Огромная версия с графическим интерфейсом GTK2. Включённые (+) и отключённые (-) особенности:
+acl +farsi +mouse_netterm +syntax
+arabic +file_in_path +mouse_sgr +tag_binary
+autocmd +find_in_path -mouse_sysmouse +tag_old_static
+balloon_eval +float +mouse_urxvt -tag_any_white
+browse +folding +mouse_xterm -tcl
++builtin_terms -footer +multi_byte +terminfo
+byte_offset +fork() +multi_lang +termresponse
+cindent +gettext -mzscheme +textobjects
+clientserver -hangul_input -netbeans_intg +title
+clipboard +iconv +path_extra +toolbar
+cmdline_compl +insert_expand +perl +user_commands
+cmdline_hist +jumplist +persistent_undo +vertsplit
+cmdline_info +keymap +postscript +virtualedit
+comments +langmap +printer +visual
+conceal +libcall +profile +visualextra
+cryptv +linebreak +python +viminfo
+cscope +lispindent -python3 +vreplace
+cursorbind +listcmds +quickfix +wildignore
+cursorshape +localmap +reltime +wildmenu
+dialog_con_gui +lua +rightleft +windows
+diff +menu -ruby +writebackup
+digraphs +mksession +scrollbind +X11
+dnd +modify_fname +signs -xfontset
-ebcdic +mouse +smartindent +xim
+emacs_tags +mouseshape -sniff +xsmp_interact
+eval +mouse_dec +startuptime +xterm_clipboard
+ex_extra -mouse_gpm +statusline -xterm_save
+extra_search -mouse_jsbterm -sun_workshop +xpm
общесистемный файл vimrc: "/etc/vim/vimrc"
пользовательский файл vimrc: "$HOME/.vimrc"
второй пользовательский файл vimrc: "~/.vim/vimrc"
пользовательский файл exrc: "$HOME/.exrc"
общесистемный файл gvimrc: "/etc/vim/gvimrc"
пользовательский файл gvimrc: "$HOME/.gvimrc"
второй пользовательский файл gvimrc: "~/.vim/gvimrc
"
общесистемный файл меню: "
$VIMRUNTIME/menu.vim"
значение $VIM по умолчанию: "/usr/share/vim"
Параметры компиляции: x86_64-pc-linux-gnu-gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -O2 -pipe -fomit-frame-pointer -mtune=native -march=native -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Сборка: x86_64-pc-linux-gnu-gcc -Wl,-E -Wl,-O1 -L/usr/local/lib -Wl,--as-needed -o gvim -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfreetype -lfontconfig -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -lncurses -lelf -lacl -lattr -ldl -L/usr/lib -lluajit-5.1 -Wl,-E -Wl,-O1 -Wl,--as-needed -L/usr/lib64/perl5/5.18.2/x86_64-linux/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lc -L/usr/lib64/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic
Sign up to leave a comment.
Об удобной навигации и отладке C++ кода в Vim