У вас какое-то очень странное представление о том, как в VIM работать с несколькими файлами, или с проектом с развитой структурой. VIM сам по себе достаточно удобен для работы со многими файлами. А с помощью плагинов он может ещё больше: от банального древовидного каталога и выбора файла с помощью чего-то типа NERDTree:
до совершенно бесподобных штук с нечетким поиском типа fzf или ctrl-p:
Во втором случае, открытие другого файла мгновенно, и никакая IDE без аналогичного функционала (или с любым "мышечным" способом открытия файлов) не сможет соревноваться с VIM в этом вопросе.
Ну это надо не забывать, ещё про такие штуки как go to definition и перескачка между файлом и соответствующим тестом, quickfix с ошибками или упавшими тестами (т.е. открытие нужного файла на позиции ошибки) и т.п. Всё это в VIM есть и очень удобно.
А как я поставил вопрос? С моей точки зрения я написал, что-то типа такого: "у VIM есть ряд преимуществ перед IDE, если вас какое-то из них заинтересовало — попробуйте VIM". А что вы увидели?
Вообще, если смотреть внимательно на скриншот — человеку не только в команде не работает, он еще и делает проекты — самоделки с коротким жизненным циклом. Вобщем он сам себя проклял вечной поддержкой своих исодников в одиночку.
Парное программирование — шутите?
Черезмерное обилие коментариев и одно окно — укзаывает на простую вещь — тестов нет (т.е. идеология когда тесты как документация к системе). В той-же Java переход от кода к тесту выполняется в 1 шорткат (это при том, что тесты расположены в совсем другой части файловой системы).
К сожалению для вас, всю вашу спесь и желчь вы изливали не на того человека. Быть может даже автор того, что на снимке экрана, вовсе не пишет в VIM (хотя что это я?! Конечно же пишет — он автор vim-go).
Возможно, вы редко встречаетесь с Open Source, но в этом мире принято документировать свои "самоделки", особенно, если это библиотека, предназначенная для использования сообществом. Конкретно на скриншоте — главный файл библиотеки color.go, у которой 932 звезды и 74 форка на гитхабе, много ли ваших проектов в той же степени заинтересовали сообщество?
По остальным претензиям к этому снимку экрана, замечу, что "короткий жизненный цикл" на данный момент превышает 2.5 года, на протяжении которых совершаются регулярные коммиты, а поддержку исходников автору помогают осуществлять ещё 11 программистов, согласно статистике репозитория. Тесты, конечно же, есть.
Этот чужой снимок экрана я привёл потому, что на нём: автодополнение с учётом семантики, структура файла и докментация к слову под курсором.
По всему остальному вашему комментарию: удобные коммиты есть, рефракторинг есть, автодополнение и, следовательно, длинные имена переменных есть.
как и для комфортной разработки ПО вообще
«мощная» == «с как можно бо́льшим кол-вом RAM и как можно более быстрой долговременной памятью»
Ну я в посте привёл пример, как можно обойти эту зависимость с помощью VIM (записал наличие такой возможности в преимущества). Ваш компьютер — тонкий клиент к мощному серверу. На нём всё летает (тесты, компиляция и т.п.) и много памяти. Локально только ssh и браузер. связка рабочая и комфортная, проверено на себе.
А что, если не создавать IDE с ноля, а написать плагин для существующей IDE?.. Да ну, глупости какие, никто так не делает.
Такой подход тоже возможен, но я почему-то чаще вижу плагины для VIM'а (или другого редактора), но не плагины для IDE (применительно к редким ЯП или редким системам). Очень интересно будет увидеть плагины для IDE (хотя бы для подсветки синтаксиса, хрен бы с обработкой ошибок и прочим) для систем компьютерной алгебры GAP и Magma, упомянутые в посте. Ну и для Sage тоже, чтобы установил что-то и завелось.
Это же ведь только vim весь клавиатурно-ориентированный, откуда тупым разработчикам ненужных IDE знать, что программистам может быть удобно не пользоваться мышью. А 54 страницы действий, доступных для биндинга, плагины поддержки vi и emacs modes, поддержка биндинга на две последовательные комбинации клавиш для тех, кому не хватает всей клавиатуры (в IDEA, по крайней мере) — это… это агония, вот!
Мой опыт работы в VIM и обощённых IDE говорит о том, что работа без мыши в VIM комфортнее. Но я как я отмечал в посте, такие вещи — вкусовщина чистой воды. Кому-то комфортнее без мыши в IDE. Конкретно про VIM, то я думаю, что связано это моё удобство с тем, что VIM изначально затачивался на работу без мыши, а для IDE работа без мыши — некоторая отдельная фича. Ну и по мне, так сложнее запомнить 54 страницы горячих клавиш, чем запомнить ограниченное число действий VIM, которые повторяются в различных вариантах.
Всем известно, что обратной дороги из IDE нет: к пользователям IDE, дерзнувшим воспользоваться блокнотом, на дом выезжает наряд полиции IDE (два огнемётчика и собака; собака внимательно слушает ваши оправдания перед тем, как огнемётчики начнут вас запекать).
Такое ощущение, что вы очень выборочно читали то, что я писал. Как только вы воспользовались блокнотом после IDE, у вас в арсенале оказались два инструмента, которые надо использовать и осваивать. Дальше вам нужен ещё один ЯП, и под него вам нужен третий инструмент. Никакой крамолы в этом нет, но пользователю VIM не понадобится три инструмента для трёх задач (хотя могут понадобится 3 разных плагина), я считаю эту унификацию, которую можно достичь с помощью VIM преимуществом. А вы?
Вот вам пример intellisense в vim для Java, C++, C#, JSP, XML, HTML, SQL:
Интерактивная помощь по параметрам функции в VIM есть для очень многих языков (не только как на картинке).
Ваши слова имеют смысл особенно в части "если вас устраивает, то и ладно". Полностью согласен. Но я бы назвал некорректной вашу аналогию Vim-IDE и велик-феррари. Vim всё-таки не велик, а условная Нива с движком от феррари, коробкой передач от BMW. И ездить вам не только по автобанам надо, но иногда и по бездорожью.
Local History — это круто выглядит, но хз насколько полезно. В любом случае, это отдельная от git-фича, я бы не назвал её глубокой интеграцией с git. Насколько я понял, её можно реализовать с помощью eclim. Справедливости ради, я eclim в своё время не освоил, не очень удобно прикручивается.
А расширенный анализ есть, например, для python. Думаю можно найти и для других языков.
Я не утверждал, что VIM может всё, что может любая IDE в том же виде. Конкретно с шейдерами, какой-то костыль, вероятно, возможен, но вы правы — не имеет особого смысла.
Я повторюсь, я не призывал всех переходить на VIM, я призывал обратить на него своё внимание!
Дебаг для многих языков есть (есть Vdebug сразу для многих языков: PHP, Python, Ruby, Perl, Tcl and NodeJS, но бывает, что и конкретно под один язык плагинчик). Насчёт графа зависимостей, чтобы прямо в VIM не скажу, чтобы вывел в файлик — это бывает.
По личному хобби неотвечу — много слов незнакомых. Но в целом, с вашим утверждением согласен. Не всё можно сделать в консоли, а, следовательно, не всё можно сделать в VIM.
У вас какое-то очень странное представление о том, как в VIM работать с несколькими файлами, или с проектом с развитой структурой. VIM сам по себе достаточно удобен для работы со многими файлами. А с помощью плагинов он может ещё больше: от банального древовидного каталога и выбора файла с помощью чего-то типа NERDTree:
до совершенно бесподобных штук с нечетким поиском типа fzf или ctrl-p:
Во втором случае, открытие другого файла мгновенно, и никакая IDE без аналогичного функционала (или с любым "мышечным" способом открытия файлов) не сможет соревноваться с VIM в этом вопросе.
Ну это надо не забывать, ещё про такие штуки как go to definition и перескачка между файлом и соответствующим тестом, quickfix с ошибками или упавшими тестами (т.е. открытие нужного файла на позиции ошибки) и т.п. Всё это в VIM есть и очень удобно.
Калькулятор в режиме вставки — это что конкретно вы имеете ввиду?
А как я поставил вопрос? С моей точки зрения я написал, что-то типа такого: "у VIM есть ряд преимуществ перед IDE, если вас какое-то из них заинтересовало — попробуйте VIM". А что вы увидели?
http://vimcasts.org/episodes/ — 68 видео на данный момент.
В посте я приводил возможные причины:
К сожалению для вас, всю вашу спесь и желчь вы изливали не на того человека. Быть может даже автор того, что на снимке экрана, вовсе не пишет в VIM (хотя что это я?! Конечно же пишет — он автор vim-go).
Возможно, вы редко встречаетесь с Open Source, но в этом мире принято документировать свои "самоделки", особенно, если это библиотека, предназначенная для использования сообществом. Конкретно на скриншоте — главный файл библиотеки color.go, у которой 932 звезды и 74 форка на гитхабе, много ли ваших проектов в той же степени заинтересовали сообщество?
По остальным претензиям к этому снимку экрана, замечу, что "короткий жизненный цикл" на данный момент превышает 2.5 года, на протяжении которых совершаются регулярные коммиты, а поддержку исходников автору помогают осуществлять ещё 11 программистов, согласно статистике репозитория. Тесты, конечно же, есть.
Этот чужой снимок экрана я привёл потому, что на нём: автодополнение с учётом семантики, структура файла и докментация к слову под курсором.
По всему остальному вашему комментарию: удобные коммиты есть, рефракторинг есть, автодополнение и, следовательно, длинные имена переменных есть.
Ну я в посте привёл пример, как можно обойти эту зависимость с помощью VIM (записал наличие такой возможности в преимущества). Ваш компьютер — тонкий клиент к мощному серверу. На нём всё летает (тесты, компиляция и т.п.) и много памяти. Локально только ssh и браузер. связка рабочая и комфортная, проверено на себе.
Такой подход тоже возможен, но я почему-то чаще вижу плагины для VIM'а (или другого редактора), но не плагины для IDE (применительно к редким ЯП или редким системам). Очень интересно будет увидеть плагины для IDE (хотя бы для подсветки синтаксиса, хрен бы с обработкой ошибок и прочим) для систем компьютерной алгебры GAP и Magma, упомянутые в посте. Ну и для Sage тоже, чтобы установил что-то и завелось.
Мой опыт работы в VIM и обощённых IDE говорит о том, что работа без мыши в VIM комфортнее. Но я как я отмечал в посте, такие вещи — вкусовщина чистой воды. Кому-то комфортнее без мыши в IDE. Конкретно про VIM, то я думаю, что связано это моё удобство с тем, что VIM изначально затачивался на работу без мыши, а для IDE работа без мыши — некоторая отдельная фича. Ну и по мне, так сложнее запомнить 54 страницы горячих клавиш, чем запомнить ограниченное число действий VIM, которые повторяются в различных вариантах.
Такое ощущение, что вы очень выборочно читали то, что я писал. Как только вы воспользовались блокнотом после IDE, у вас в арсенале оказались два инструмента, которые надо использовать и осваивать. Дальше вам нужен ещё один ЯП, и под него вам нужен третий инструмент. Никакой крамолы в этом нет, но пользователю VIM не понадобится три инструмента для трёх задач (хотя могут понадобится 3 разных плагина), я считаю эту унификацию, которую можно достичь с помощью VIM преимуществом. А вы?
Неплохо. В VIM как-то так:
Конкретно теми, что по ссылке — нет. Но в интернетах хвалят.
см. выше про анализ кода и JS.
Насколько я понимаю, вам поможет tern_for_vim или tern, интегрированный в YouCompleteMe.
Вы правы, похоже на старье (не обратил внимание, т.к. не пишу на Java). Народ хвалит eclim: http://eclim.org/vim/java/complete.html
Что за язык?
Есть ещё, кстати jedi, мною упомянутый: http://jedi.jedidjah.ch/en/latest/docs/features.html
А это что у вас на картинке, не подскажете?
Ну, что сходу нашёл — на то ссылку дал :) Не ставил перед собой целью собрать максимально полный список. Подозреваю тот, что по ссылке — не полный.
Ну это особенности внутренней архитектуры, которые меня, если я только не пишу дополнения к этому редактору/IDE, особо не должны волновать.
Вот вам пример intellisense в vim для Java, C++, C#, JSP, XML, HTML, SQL:
Интерактивная помощь по параметрам функции в VIM есть для очень многих языков (не только как на картинке).
Ваши слова имеют смысл особенно в части "если вас устраивает, то и ладно". Полностью согласен. Но я бы назвал некорректной вашу аналогию Vim-IDE и велик-феррари. Vim всё-таки не велик, а условная Нива с движком от феррари, коробкой передач от BMW. И ездить вам не только по автобанам надо, но иногда и по бездорожью.
Local History — это круто выглядит, но хз насколько полезно. В любом случае, это отдельная от git-фича, я бы не назвал её глубокой интеграцией с git. Насколько я понял, её можно реализовать с помощью eclim. Справедливости ради, я eclim в своё время не освоил, не очень удобно прикручивается.
А расширенный анализ есть, например, для python. Думаю можно найти и для других языков.
Я не утверждал, что VIM может всё, что может любая IDE в том же виде. Конкретно с шейдерами, какой-то костыль, вероятно, возможен, но вы правы — не имеет особого смысла.
Я повторюсь, я не призывал всех переходить на VIM, я призывал обратить на него своё внимание!
Дебаг для многих языков есть (есть Vdebug сразу для многих языков: PHP, Python, Ruby, Perl, Tcl and NodeJS, но бывает, что и конкретно под один язык плагинчик). Насчёт графа зависимостей, чтобы прямо в VIM не скажу, чтобы вывел в файлик — это бывает.
По личному хобби неотвечу — много слов незнакомых. Но в целом, с вашим утверждением согласен. Не всё можно сделать в консоли, а, следовательно, не всё можно сделать в VIM.