Pull to refresh
Comments 401
IDE значительно тяжелее VIM (даже с плагинами)


При всей любви к VIM… Был у меня один знакомый евангелист, дал свой vimrc. Ну и оказалось, что запускается по времени примерно столько же, сколько обобщенная IDE, а переименовать функцию, не грепая вручную по всем исходникам, по-прежнему нельзя.

VIM я правда люблю и ни за что не променяю на nano или emacs. Но делать из него IDE — ну только если вы правда сегодня на Python, завтра на Clojure, послезавтра на Magma. Плюс для некоторых обобщенных IDE тоже есть туча плагинов.

А что значит по-вашему "делать IDE"? При работе с большинством ЯП я добиваюсь в минимальном варианте того, чтобы были:


  • Подсветка синтаксиса
  • Автодополнение
  • Проверка синтаксиса
  • Сборка и прогон тестов
  • Автоотступы
  • Форматирование кода (в соответствии с правилами языка)
  • Сниппеты

Чаще всего половина этого уже есть в базовой поставке VIM. Остальное 1-2 плагина для языка.


Это — IDE?

Нет, это всего-навсего уважающий себя редактор.

Рефакторинг — переименование функций, методов, классов, переменных, параметров, файлов (перименовал/перенес файл — везде поменялись импорты), вещи типа extract variable/method/parameter.


Умная навигация, как минимум «Jump to definition».


Кодогенерация (типа сгенерировать моки для этого класса), хотя это отчасти решается сниппетами.

В VIM встроенная навигация по тегам. Чаще всего "Go to definition" реализуется именно так. Но для некоторых языков есть отдельное "go to definition".


Для рефакторинга есть много инструментов. Вот тут обсуждаются для нескольких языков и в "общем случае".


Т.е. в целом от "уважающего себя редактора" до IDE в вашем определении отделяет одно дополнение с поддержкой рефакторинга? По-моему не такое уж и преступление вкатить плюс один плагин и сделать из вима IDE.

Ну, в целом, да, рефакторинг для меня самое важное (он не исчерпывается переименованием, кстати). Хотя вот ниже еще указали глубокую интеграцию с VCS, это тоже очень полезно. И не забудьте, вы обещали это для любого языка, а по вашей ссылке список весьма скудный:)

Ну, что сходу нашёл — на то ссылку дал :) Не ставил перед собой целью собрать максимально полный список. Подозреваю тот, что по ссылке — не полный.

UFO landed and left these words here
Принципиально IDE от редактора отличается тем, что IDE оперирует синтаксическим деревом редактируемого кода на целевом языке (или неким к нему приближением), а редактор оперирует символами и строками.

Ну это особенности внутренней архитектуры, которые меня, если я только не пишу дополнения к этому редактору/IDE, особо не должны волновать.

Разумеется, само по себе понятие о синтаксической структуре редактируемого кода, без конкретной цели, было бы бесполезно, разве что помещение обогревать. Нормальная IDE позволяет организовать навигацию по проекту в различных направлениях и контекстах, производить различные виды рефакторинга, человеческий автокомплит с пониманием контекста, анализирует код на ошибки — от банальных опечаток типа неопределенных переменных до некоторых видов статического анализа, которые осуществимы в реальном времени. Чем больше проект, тем важнее все это становится. В редакторе же все сводится к регулярным выражениям, чего для подавляющего большинства языков программирования недостаточно.

Ну и, конечно, для любой нормальной IDE есть vim-плагин, я, например, без IdeaVIM не представляю, как работать :)
В теории и для основным языков (java, c++) это действительно так. Когда я работал в проекте, где основным backend была java это работало.
Правда в том же проекте фронтендщики работали на JS. И для JS этот функционал был неюзабелен. Батарейка ноутбука съедалась мгновенно, и даже автоподстановка для JS подтормаживала.

Если же выключить этот функционал, которые генерировал синтаксические деревья, то вся огромная и дорогая идея для JS становилась не очень хорошим клоном вима.
По моему IDE принципиально отличается тем, что поддерживает отладку. IDE без отладки — и есть всего-лишь редактор.
Но редактор с отладкой не становится IDE, это недостаточное условие. К vim-у или emacs-у отладчик прикрутить — не проблема совсем.
В начале 90-х по сути это было достаточным условием (плюс навигация, плюс запуск билда).
Расширенный анализ кода, навигация, переименование, глубокая интеграция с git.

По навигации и переимнованию, отвечал в других комментах.


А что такое глубокая интеграция c GIT, такая интеграция достаточно глубока? И что такое расширенный анализ кода?

Не знаю, мне лень изучать всё, что там написано. Вот глубокая интеграция, а всякие git checkout master я и сам из консоли делаю обычно.

Самый простой пример расширенного анализа — когда IDE находит переменные, которые используются до присвоения. Или когда проверяет, можно ли библиотеку импортировать, нет ли опечатки в её названии.
Не знаю, мне лень изучать всё, что там написано

Пастернака тоже осуждаете?
Нет, просто в IDE всё это реализуется парой кликов мыши, и время на чтение тратить не нужно.
Так в GVim тоже есть менюшки, кнопочки, иконки и другие рюшечки, все для мышко-программинга.
Вы хотите чтоб git был частью vim? Вам тогда надо смотреть в сторону emacs, если сильно постараться, то можно впихнуть в него ОСь.
Если мне куда-то и надо смотреть, то только в сторону кнопки закрытия браузера, чтобы перестать тратить время на бесполезный холивар.
Забавно читать подобный коммент от пользователя с вашим ником =)
Я не говорил, что с ним что-то не так. Просто он вызывает ассоциации с языком Delphi, IDE для которого известна своей ориентированостью на «мышко-программистов».
Это ложная ассоциация, мой ник никак с Delphi не связан, поверьте )

Local History — это круто выглядит, но хз насколько полезно. В любом случае, это отдельная от git-фича, я бы не назвал её глубокой интеграцией с git. Насколько я понял, её можно реализовать с помощью eclim. Справедливости ради, я eclim в своё время не освоил, не очень удобно прикручивается.


А расширенный анализ есть, например, для python. Думаю можно найти и для других языков.

Реально полезно, если ветки криво смержились, по локал-хистори можно быстро восстановить не попавшие в мерж куски кода.

Не сочьтите занудой, но я помню, что когда работал с идеей, мне проще было сделать мерджи в коммандной строке.

То ли я не знал как, то ли в идее были какие-то проблемы, но мерджи были головной болью, пока не пересел на консоль почти полностью.
За последние лет 4-5 никаких проблем с мерджем в Идее не встречал. Вернее там есть/были мелкие баги, которые проявляются при определенных условиях, но явно нет смысла использовать консоль.
последние как минимум N (N=7) лет лучшая мержилка на планете (не считая SemanticMerge и, возможно, Visual Studio, про которую я ничего не знаю) как раз в IDEA
Очень полезно, когда надо выяснить, откуда у данного куска кода растут ноги.

Автоматический вызов pyflakes, или чего оно там использует, меня не очень интересует, это я и сам могу сделать. Вот этот списочек покруче будет.
В смысле? Окно настройки проверок в PyCharm, конкретно — проверка на совместимость с разными версиями питона.
У меня процессор AMD A8-6600K. Не могу пользоваться PyCharm — слишком сильно тормозит.
У меня на Semprone X2 прекрасно работал PyCharm. Не надо жопить пару тысяч на память, и будет прекрасно работать.
Ну, к примеру, в Студии это выглядит так:
image

Коммиты по методу/классу, можно посмотреть сами изменения. Очень удобно.
Шейдеры в VS. Слабо на виме? (Справедливости ради, с шейдерами всегда туго, до VS везде далеко, приходится кусать локти для WebGL).

Профайлинг, дебаг (ага, можно дебажить и в других местах, теряя все удобства редактора под рукой), построение графа зависимостей — да полно задач, которые vim не сможет сделать либо чисто по техническим причинам (шейдеры в cli даже не смешно), либо из-за большой сложности.

А еще из личного хобби — blueprint в quartus, simulink в matlab, waveforms приходится отображать в других средах.

Я не утверждал, что VIM может всё, что может любая IDE в том же виде. Конкретно с шейдерами, какой-то костыль, вероятно, возможен, но вы правы — не имеет особого смысла.


Я повторюсь, я не призывал всех переходить на VIM, я призывал обратить на него своё внимание!


Дебаг для многих языков есть (есть Vdebug сразу для многих языков: PHP, Python, Ruby, Perl, Tcl and NodeJS, но бывает, что и конкретно под один язык плагинчик). Насчёт графа зависимостей, чтобы прямо в VIM не скажу, чтобы вывел в файлик — это бывает.


По личному хобби неотвечу — много слов незнакомых. Но в целом, с вашим утверждением согласен. Не всё можно сделать в консоли, а, следовательно, не всё можно сделать в VIM.

Для шейдеров хотелось бы профайлер и автотестер, который бы мог на CPU выполнить код и выдать его в виде текстуры, подсчитав количество операций, с учетом версий языка, и возможных особенностей оборудования, вроде наличия тесселятора.

Визуально на картинку смотреть интересно, но не всегда полезно.
UFO landed and left these words here

Вот вам пример intellisense в vim для Java, C++, C#, JSP, XML, HTML, SQL:


image


Интерактивная помощь по параметрам функции в VIM есть для очень многих языков (не только как на картинке).


Ваши слова имеют смысл особенно в части "если вас устраивает, то и ладно". Полностью согласен. Но я бы назвал некорректной вашу аналогию Vim-IDE и велик-феррари. Vim всё-таки не велик, а условная Нива с движком от феррари, коробкой передач от BMW. И ездить вам не только по автобанам надо, но иногда и по бездорожью.

Ещё подкорректиную аналогию:
VIM — это набор запчастей для условной нивы + попадаются запчасти более высокого качества (но их надо проверять),
хорошая IDE — условный новенький хаммер из магазина с полным фаршем.
обычная IDE — условная шевроле нива
Похоже, этот плагин:
1) Windows-only. http://insenvim.sourceforge.net/portlinux.htm — тут, в сломанном HTML, можно прочитать: «We don't have for Linux, but want to port. It
may be tough, but any help is appreciated.». Увы.
2) Не обновлялся с 2006 года, уже 10 лет.

Боюсь, даже если он заведётся и будет работать с современным вимом, вряд ли там будет поддержка возможностей языков, которые они получили за последние 10 лет. А у Java уже две версии как минимум вышли…
Да, набор возможностей выглядит неплохо. Но отсутствие коммитов с марта настораживает, да и рефакторинг возможен лишь на уровне переименования и вытаскивания классов. Тем не менее, инициатива хорошая, и получилось что-то явно более продвинутое, чем обычный плагин для подсветки синтаксиса.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Автор заявил, что vim всех рвет


Вы, пожалуйста, прежде чем такое писать, внимательно прочтите, что такого "автор заявляет". Моя основная мысль состоит в следующем: даже, если вы пользуетесь IDE, то обратите внимание на VIM — у него масса достоинств по сравнению с вашей IDE.

Совершенно точно, можно утверждать и обратное: у IDE есть достоинства по сравнению с VIM. Я нигде не утверждал обратного.
UFO landed and left these words here
alexkuin уже и сам Вам ответил, но я не смог пройти мимо: его комментарий вообще не о том. Смысл не в том, что кто-то должен всё это настроить, а в том, что многие вещи настроить от «очень тяжело» до «невозможно», при этом IDE всё это уже умеет. Сразу. Ну и зачем vim? «Не было печали – купила баба порося» :) Сиди – знай себе настраивай)
UFO landed and left these words here
Большинство плагинов к редакторам работают на уровне текста, как правило пытаясь парсить его регулярками.
А что тогда IDE?

Дебаг, деплой, статический/динамический анализ, профилирование.
Мне всегда казалось, что IDE — это редактор + сборка + отладка.
Понятие IDE сильно изменяется со временем. В конце 80-х-начале 90-х стандартом для IDE де-факто было — навигация по файловой системе, редактирование исходников (практически без поддержки синтаксиса), компиляция и сборка (не для интерпретируемых языков, конечно), запуск и запуск в режиме отладки. По сути, главным было редактирование и отладка без переключения в другую программу (в те времена в доминирующей однозадачной ОС переключением было выход из одной программы и запуск другой). Верю, что сейчас это vim может обеспечить практически из коробки. Но сейчас обязательными элементами IDE являются синтаксический анализ на лету (полноценный, а не в первом приближение регулярками), навигация по сущностям языка (опять же по результату полноценного синтаксического анализа), автодополнение с учётом контекста, простейшие методы рефакторинга типа переименования, выделения в метод и т. д.
Есть масса примеров когда текстовый редактор доводят до уровня редактора кода. Однако IDE (среда разработка) в отличии от прочих редакторов работает с проектом, а не отдельными сущностями…
Больше похоже на файловый менеджер, чем на IDE. В IDE зачастую можно работать вообще не думая о файлах, оперируя сущностями языка типа модуля, класса, нэймспэйса. Решаем задачу не «отредактировать код в файле таком-то», а «отредактировать код класса такого-то».
Я ответил конкретно на это высказывание
Однако IDE (среда разработка) в отличии от прочих редакторов работает с проектом, а не отдельными сущностями
Проект — нечто большее, чем совокупность файлов в одном каталоге. Так бы и mc хватило. Главное в проекте — содержимое файлов. IDE должна быть заточена на анализ содержимого.
Это вы перечислили только одну вкладку Editor вк примеру в phpstorm

Ну понятно, что испортит можно всё, что угодно. Можно написать плагин, который будет делать sleep 10000 и удивляться, чего это VIM такой тормозной :) Если следовать пути, который я указал, и ставить плагинчики через vim-plug (который умеет ленивую загрузку, т.е. грузит, только когда потребуется), то всё будет быстро.


А насчёт переименовать, то вот вам плагин на тему, vim-esearch: NeoVim/Vim plugin performing project-wide async search and replace, similar to SublimeText, Atom et al.


Ну и, например, для того же Python в Jedi-vim есть соответствующая команда.

vim-go+gorename — работает отлично.
Это все таки задача плагина, а не vim'а, кмк.
а переименовать функцию, не грепая вручную по всем исходникам, по-прежнему нельзя

CtrlSF Правда?

признаю, я дальше гифок по ссылке и исходников ag не смотрел, так что вот пару простых вопросов навскидку


  • отсеиваются ли ложные срабатывания в виде ф-ций с одинаковым именем в разных модулях/классах?
  • отсеиваются ли ложные срабатывания в виде названий переменных с именем, идентичным имени переименовываемой функции?
  • что произойдёт, если при «переименовании» зажать клавишу Del/BackSpace?
  1. Нет
  2. Нет

По первым двум пунктам речь идёт о статическом анализе кода. Вообще это сильно зависит от языка, с которым вы работаете, и где-то такой анализ просто мешает и раздражает, плохо применим. Вот например у некоторых коллег по работе — WebStorm, от чего-то они его так любят, но он ужасен, его встроенный линтер JavaScript/TypeScript, который, как я понимаю, пытается анализировать код, делает это отвратительно, постоянно сыпя ошибками там, где их в действительности нет, не говоря уже о том, что то и дело врубается форматтер, из-за которого нарушаются стайл-гайды и пулл-реквесты отправляются на доработку (но это уже другая история про хвалёные IDE). CtrlSF же находит вхождения и выводит их в один буфер, который ведёт себя как и любой другой vim-буффер, и всё что ты знаешь о редактировании в vim, — применимо, ты просто рассматриваешь чанки, делаешь в них изменения и затем коммитишь (просто как обычно для vim сохраняешь буффер), можно просто сделать автозамену с подтверждениями по вхождению (что обычно и происходит в моём случае, лично мне этого хватало пока с лихвой). Нужно иметь в виду что я описал только узкий пример возможностей, можно открывать отдельные файлы из буфера вхождений и работать с ними более детально например.

А вот вопрос третьего пункта я вообще не понял, к чему он? Возможно я уже дал на него ответ выше, описав механизм работы, и результат будет зависеть от того, в каком режиме вы находитесь, в каком месте буфера с вхождениями, и вообще от вашего vim-конфига, вы в конце-концов можете забиндить эти клавиши на что угодно.
не говоря уже о том, что то и дело врубается форматтер, из-за которого нарушаются стайл-гайды и пулл-реквесты отправляются на доработку

Если style guide написан разумными людьми и настроек IDE не хватает, чтобы настроить автоформатирование согласно style guide'у, то стоит написать в багтрекер соответствующей IDE. Естественный вопрос: каких настроек не хватило?

Честно говоря — понятия не имею, я знаю как минимум пятерых пользователей WebStorm (из разных компаний), и от всех от них постоянно какие-то проблемы, их IDE постоянно портит им работу, как её укротить они по всей видимости не знают, может быть это невозможно, может быть это слишком сложно и проще написать плагин для vim (как это сделал однажды я например, чтобы соответствовать стайл-гайду, после чего у меня никаких проблем не было), может быть стоит усомниться в компетенции разработчиков, кого винить, я не знаю, меня это мало интересует, я вижу лишь тенденцию среди пользователей этой IDE, которая убеждает меня в том, что я как минимум ничего не теряю, не используя её.

Судя по коду вашего "плагина" он режет пробельные символы не в конце файла (EOF), а на концах строк (EOL).


думаю, картинка скажет всё

Это тенденция не среди пользователей IDE в общем или IDE от JetBrains в частности, а симптом left-pad'а среди фронтэндеров, к сожалению.

Нет, вы неправильно поняли идею плагина. Он режет пробелы/табы на концах строк, но не режет их если в строке ничего кроме табов нет (когда отступы оформляются в виде табуляции), при этом режет пробелы, на концах строк, где есть отступы табами (не трогая при этом табы). При этом не режет табы (но пробелы режет) в закомментированных кусках, т.к. коммент — это уже не пустая строка. В общем в одно предложение суть мне сложно уложить, но делает оно именно то, что я хотел, я уверен, ни в одной IDE нет столько отработанного механизма по крайней мере из коробки.

Думаю, что нет. Style guide, допускающий смесь табов и пробелов в отступах в рамках одного файла, является, мягко говоря, странным.


Требование наличия отступов в пустых строках тоже выглядит странно: автоотступ умеют почти все нормальные редакторы (e. g., set cindent).

Вы опять неправильно поняли суть, не допускает стайл-гайд смеси табов и пробелов, а плагин режет просто мусор, не трогая при этом того, что резать не нужно.

Требование наличия отступов в пустых строках тоже выглядит странно: автоотступ умеют почти все нормальные редакторы (e. g., set cindent).

Это не требование, по стайл-гайду мы оставляем табы на пустых строках (например для того, чтобы при подсвеченых символах таба визуально видеть цельный не раздробленный блок), а в комментариях я их не вырезаю именно чтобы потом снова их не добавлять, в случае если код будет раскомментирован. То-есть опять же вы всё поняли неправильно.
> в комментариях я их не вырезаю именно чтобы потом снова их не добавлять, в случае если код будет раскомментирован.

Простите что? Т.е. с тем, что закомментированный код в версионном хранилище — адовый антипаттерн вы не знакомы?
Почему у вас поведения для комментов для пробелов и для табов различается?

PS если вам надо:
— не чистить комменты от пробельных символов (там они имеют совсем другое значение, нежели в коде...) (комментированный код — зло)
— чистить в конце строк пробельные символы (trim-end)
— не чистить пустые строки
то всё это умеет Idea (а значит и WebStorm) из коробки (максимум пару-тройку галок перекинуть).

И именно ваши объяснения и вызвали такую бурю (как выражаетесь, так вас и понимают). И, с учётом вышеозначенного, где бонус вима перед IDE?
В кривых руках пользователей не IDE виновата.

PPS стайл гайд — делающий различие между пробелами и табами (всё это пробельные символы форматирования) на концах строк — говённый стайл гайд. К выводу о том, что ваш стайл-гайд такой я пришёл на основании ваших же путанных объяснений. И причём тут «ограниченная IDE» (которая мешает говнокодить тем, что не поддерживает такой вот говнокод)?
В моём случае недостаточно просто не резать непробельные символы на пустых строках.

Простите что? Т.е. с тем, что закомментированный код в версионном хранилище — адовый антипаттерн вы не знакомы?

Данные решения принимал не я, сам бы так делать не стал, но я продемонстрировал что мой редактор позволяет мне подстроиться под заявленные требования, я сейчас не обсуждаю идеологические подходы, а лишь возможности редактора.

И, с учётом вышеозначенного, где бонус вима перед IDE?

Гибкость например. И я уверен, что то, что я описал на примере вырезания пробельных символов определённым образом, по прежнему не реализована в том же WebStorm или Idea, и это не связано с кривостью рук, если мне вдруг станет скучно, — может я и набросаю какой-нибудь пример с мусорными пробельными символами, покажу вам скринкаст, как с ними справляется вим, а вы в свою очередь можете попробовать доказать мне, что IDE способна на тоже самое, предоставив свой скринкаст.
> Данные решения принимал не я, сам бы так делать не стал, но я продемонстрировал что мой редактор позволяет мне подстроиться под заявленные требования, я сейчас не обсуждаю идеологические подходы, а лишь возможности редактора.

Данные подходы расходятся с best-practice, поэтому могут быть не реализованы в IDE (и я буду рад, если выяснится, что они не реализованы — не надо поощрять говнокод).
До кучи — они ещё и проблемы могут принести (как вам такая радость — в генерируемом xhtml в закомментированном участке поймать "--" из переменной? А ведь все xml-валидирующие парсеры дружно прервут парсинг с ошибкой/исключением...).

По поводу примера — можно и без скринкаста (зачем он вообще? вопрос доверия решать? Вас FullHD устроит?)

PS ну и напоследок — в очередной раз: гибкость, облегчающая возможность говнокода — это вред.
> При этом не режет табы (но пробелы режет) в закомментированных кусках, т.к. коммент — это уже не пустая строка

Это что за бредовый стайл-гайд? Во-первых: коммент это коммент (туда может и пустая форматированная строка угодить, ага), не надо его считать куском кода! Во-вторых какие нахрен пробелы/табы на концах строк? Вы уж определитесь в своём стайл-гайде и используйте или то или другое. Иначе получаем бред.

И по IDE от JetBrains (включая вебшторм): by default пробелы в пустых строках не режутся, пробелы в конце кода режутся, пробелы в комментах не режутся. Под пробелами я понимаю настроенный символ (таб или пробелы), используемый для форматирования (by default символ — это пробелы, by default — форматирует отступом по 4).

PS знаете, можно через одно место написать стайл-гайд, а потом жаловаться, что то или иное средство его не поддерживает… но это будет не проблема средства, а проблема стайл-гайда.
Посмотрите мой комментарий выше, где я объясняю в чём суть. Вы также всё неправильно поняли и додумали свою версию того, что в стайл-гайде, которая ничего общего не имеет с реальностью, а плигин режет мусор и пробелы на концах строк, где отступы табами, являются мусором, как и табы на концах не пустых строк, за исключением комментариев (опять же смотрите ссылку на мой другой комментарий.

Вы выдумали какие-то свои аргументы, основываясь на выдуманных обстоятельствах, но тем не менее оправдывать ограниченность своей IDE плохим стайл-гайдом, потому что IDE не может под него подстроиться, — я не уверен, что это сколько-нибудь положительный или хотя бы оправдывающий пункт для обсуждаемой IDE.
По первым двум пунктам речь идёт о статическом анализе кода.

получается, что «грепы для программистов» на самом деле не парсят исходники? тогда чем оно лучше проиндексированного IDEA AST исходников?


где-то такой анализ просто мешает и раздражает, плохо применим

«не работает везде» ⇒ «не нужен вообще»?


его встроенный линтер JavaScript/TypeScript, который, как я понимаю, пытается анализировать код, делает это отвратительно, постоянно сыпя ошибками там, где их в действительности нет

Enjoy your dynamic typing. Справедливости ради, линтер в IDEA можно выборочно заткнуть «здесь, здесь и вот здесь» не сходя с места.


то и дело врубается форматтер, из-за которого нарушаются стайл-гайды и пулл-реквесты отправляются на доработку

  1. форматтер конкретно JS/TS/CoffeeScript настраивается довольно гибко и практически на любой вкус
  2. конфигурация форматтера хранится в текстовом файле, пригодном для распространения вместе с проектом. Единственное «но» — не поддерживается импорт стиля кода из *lintrc
  3. автоформатирование по мере ввода/генерации исходника отключается

А вот вопрос третьего пункта я вообще не понял, к чему он?

К тому, что IDEA при переименовании на месте не даёт редактировать исходник за пределами имени переменной/функции/поля/etc. даёт и при этом немножечко идёт вразнос. Снимаю вопрос, пойду зарепорчу баг.

По поводу «умного» статического анализа, — для некоторых языков это реализовано тем или иным образом в vim, вот пример для ознакомления: http://ternjs.net/

То есть вы утверждаете, что этот евангелист нарочно подсунул мне такой плагин в конфиг?:) Простите, трудно в это поверить:)


Это понятно, что испортить можно что угодно. Просто обобщенные IDE весят так много не потому, что они такие вредные или кто-то там вставляет sleep 10000, а потому что они умеют много. Бесплатной функциональности не бывает, любая фича занимает место на винте, в памяти и процессорное время для своей работы. (Другое дело, что в VIM ты ставишь только то, что тебе нужно.)


Search&replace это хорошо, но если мне надо переименовать метод в одном классе, а в другом одноименный оставить как есть — это не search&replace. Для Python такая команда есть, ок, а для всего остального?

Для go тоже команда (см. комментарий выше), я думаю для большинства языков будет такая возможность.


А насчёт евангелиста, ну я к тому, что тот факт, что кто-то создал какой-то адски тормозной конфиг, не отменяет того, что у нормальных людей VIM при той же функциональности быстрее многих (а думаю, что и любой) IDE.


Плюс столько же времени грузится != настолько же тяжелый. Есть ещё потребление памяти, скорость работы и т.п.

Ну я рад за питонистов и гоферов. Но вы, кажется, обещали функциональность уровня IDE для любого языка?
у нормальных людей


Вот вы сейчас оскорбили совершенно вам незнакомого человека. Если бы я имел причины сомневаться в конфиге того человека, я бы не завел это обсуждение вообще.
при той же функциональности быстрее многих


Согласен. Однако функциональность еще не факт, что дотягивает, а скорость… ну запускается оно 10 секунд, а не 20 — погоды это не делает.

Нормального в смысле "среднестатистического", не хотел никого обидеть. Выбрал неудачное слово, прошу прощения.


Моя мысль была в том, что IDE жрут (как при запуске, так и во время работы) больше VIM, из-за чего на слабых и средних машинах работа с ними может быть некомфортной.


Ну, во-первых, я не обещал IDE для любого языка, я привёл аргументы почему с моей точки зрения VIM имеет преимущество, а IDE недостаток. Я уверен, можно сколотить подобный список, где конкретное IDE берёт верх над VIM (навскидку отсутствие необходимости в конфигурации, лёгкость входа, полная поддержка языка из коробки и т.п).


Но опять же, для большого числа языков, я убеждён, VIM можно нарастить по набору фич до IDE в вашем понимании.

Но опять же, для большого числа языков, я убеждён, VIM можно нарастить по набору фич до IDE в вашем понимании.
Склонен скорее согласиться. Но будет ли он в результате *критично* быстрее этой IDE? Ну немного быстрее, ну фич почти хватает… шило на мыло.

на слабых и средних машинах работа с ними может быть некомфортной
На слабых и средних машинах работа вообще не может быть комфортной:) Кроме редактора еще нужен браузер, а иногда и офисный пакет, не помешает музыка, ну и всякие там компиляторы-трансляторы тоже кушать хотят.

Прямо сейчас я могу поправить файлик на проде в VIM — закрыть баг костылем, что-то вывести в лог, поправить грамматическую ошибку, все это с подсветкой синтаксиса, с отступами, без тормозов. И это прекрасно! Но ставить 30 плагинов в надежде, что он догонит IDE и не будет тормозить — я оставляю другим:)
Так купите себе нормальный инструмент для работы! Господи, ну и аргументация. Аш трисёт!
да истории про «слабые машины» и «ide жрут». я тут грубовато сейчас выскажусь, извиняюсь, но вот эту тягу наколхозить из говна и палок, чтобы абы как ездило, вместо того чтобы купить нормальный инструмент — я считаю ущербной и тупиковой. рано или поздно всё развалится.

Во-первых, это только один из девяти аргументов. К остальным претензий нет?
Во-вторых, я не до конца вас понимаю: вы считаете, что то, что VIM потребляет меньше ресурсов и менее требователен к рабочей станции, минусом?

Добавлю слово про производительность vim, как-то в одном jabber-чатике люди обсуждали у кого на сколько редакторы лагают открывая один большой SQL файл (в миллион строк или что-то около того), я открыл для фана в vim, с подсветкой, свободно перемещался в начало-конец, осуществлял поиск и совершенно никаких лагов не заметил.

Откройте xml на 10-100MiB в одну строку. Хотя современный vim, вроде просто подсветку начинает отключать после скольких-то десятков килобайт в одной строке. До этого видел его уход в себя.

Ну дадите ссылку на такой xml, я может и проведу из любопытства эксперимент.
d=$(for (( i=0; i<1000; i=i+1 )) ; do echo -n '<test></test>' ; done)
for (( i=0; i<1000; i=i+1 )) ; do echo -n $d ; done > test.xml

Примерно 13 MiB выхлопа. Ну или наберите в vim'е 1000000i<test></test> или 1000i<test></test>\[^y$$999p, если не хочется ждать несколько минут.


Перемещение в конец строки, всякие w/b в конце строки тормозят адски на 7.4.

В JetBrains IDEA тормозит при первом открытии (т. к. идёт разбор AST), но потом навигация работает шустро и в обычном, и в ideavim режимах. Ну и подсветка синтаксиса тоже работает корректно.


Правда, слишком большие файлы (типа 100MiB xml) уже не индексируются, насколько помню.

Ни один из этих аргументов не релевантен. Пользуюсь vim'ом.
Не вы ли писали посты про nano, где одна из причин их появления біла: «vim, увы, есть не везде»?
Это аварийные ситуации. В реальной жизни всё-таки это живые системы. А что можно ещё в качестве редактора на сервере иметь?
Среда, в которой есть только nano и нет возможности поставить vim — аварийная.
а много у вас свистоперделок к виму прикручено? и сколько хоткеев и функций в рутине обычно используете?
Лично у меня порядка 50-и плагинов (туда же входят плагины подсветки синтаксиса различных ЯП), из постоянно и часто-используемых плагинов (именно которые добавляют функционал), штук 15 перечислить по памяти могу, много кастомных хоткеев, большинство так или иначе регулярно использую, но обращаю внимание, что соль работы в vim (за что его многие и любят), — это не 5-и ступенчатые аккорды, а гибкие и мутабельные последовательности, таким образом какие-то несколько даже базовых приёма могут быть использованы в разных комбинациях, получая в итоге разный эффект. А вообще набор основных комбо в итоге превращается в набор рефлексов.

Вот чисто для примера w — это перемещение через слово, окончание iw обычно означает «слово», и d — удаление, v — визуальный режим (выделение), c — удаление и переход в режим ввода, далее фантазируем (на самом деле регулярно используемые комбо, которые под коркой отбиваются на автомате):
  • diw — удалить слово
  • ciw — заменить слово, что-нибудь набрав
  • viw — выделить слово

p/P — вставка из буфера обмена перед/после, таким образом viwp — заменить слово тем, что в буфере.
Окончание i+кавычка или скобка — обычно означает всё, что внутри кавычек/скобок, таким образом не уходя от выше-приведённых примеров:
  • di' — удалить всё что между одинарных скобор
  • ci} — заменить всё, что внутри фигурных скобор, что-нибудь набрав
  • vi) — выделить всё, что в пределах круглых скобок

Также взять числовой префикс повторений, Y — скопировали строку, и 10p продублировали её 10 раз.
Как видите, сказать о кол-ве «хоткеев» довольно сложно, у вас есть небольшой набор базовых рефлексов, которые могут свободно комбинироваться между собой.
Vim может работать в режиме только консоль.

А теперь смотрите, сколько в этом режиме надо времени, нервов и костылей, чтобы просто найти кусок кода в несколько строк.

Вроде особых проблем нет. Конкретно у меня проблема не возникла бы, ибо стоит плагин vim-visual-star-search.

Дописать (скопипастить) 1-2 строчки в vimrc? Ужас какой
Да, ужас. Потому что я их должен сначала найти (точнее, вырвать у очень доброжелательного сообщества), а потом запомнить, как ими пользоваться. А потом перенести на сервер, если поиск мне понадобится там. И всё это вместо ctrl+c, ctrl+f, ctrl+v.
Давайте ещё по всему багтрекеру пройдёмся, может ещё какой косяк найдём. Да, указанных хоткеев недостаточно, перед тем как жать ctrl+f надо пару строк выделить мышью, чтобы многострочный режим активировать.

Я просто не в курсе, как это делается в IDEA. Там пишут что-то про alt+m и т.п. Если всё происходит автоматически путём анализа буфера обмена, то вопрос снимается.

Не совсем так. В других редакторах достаточно просто скопировать текст, открыть окно поиска и вставить его туда, в IDEA с некоторых пор по ctrl+f открывается однострочное окно поиска, а для того, чтобы открылось многострочное, надо перед нажатием ctrl+f выделить несколько строк. При нажатии сочетания выделенные строки попадут в окно поиска, где их нужно заменить на интересующий фрагмент.
https://youtrack.jetbrains.com/issue/IDEA-145720
Слушайте, а вы вообще сидели за нормальной IDE с десятком активных проектов одновременно? За нормальным современным компьютером, где от 16гб оперативки и ссд под систему? А то как-то всё взгляд у вас однобокий.

Сидел несколько лет назад, тогда правда 16гб не было стандартом нормального компа, это было 4-8Гб. NetBeans, Aptana, Eclipse — это нормальные IDE с вашей точки зрения?


P.S. После комментариев к этой статье, я увидел, что некоторые IDE, особенно от JetBrains, сильно продвинулись. Возможно, попробую их поставить и для себя сравнить их удобство с VIM. Но, как я писал выше, для некоторых моих задач просто нет такой опции "IDE".

Лично мне, помимо описанных плюшек, IDE доставляет контролем над проектами. Есть десятки серверов, на которых в десятках мест крутится различный код, и JB позволяет мне весь этот код консолидировать в одном месте, в нескольких локальных проектах, переключаясь между которыми я держу руки на пульсе у всей системы, не шарахаясь с безумными глазами по SSH если что-то где-то надо поменять.

Не совсем понимаю вашу проблему. Вы выступаете в роли администратора или разработчика? Во втором варианте, мне пока неясно, в какой ситуации вам надо в одном месте консолидировать код с 10-ти разных мест и что-то с ним делать. Такое ощущение, что у вас как-то не так деплой налажен, но могу ошибаться.

Ну вот опять вы начинаете декомпозицию общей проблемы и каждому элементу пытаетесь применить свой способ решения. В этом можно упражняться до бесконечности, но разговор про то, что специализированная IDE всё это уже делает за вас.

Ну мы обсуждаем преимущества и недостатки IDE и VIM для разработчика. Вы формулируете ситуацию, в которой с вашей точки зрения IDE удобнее. Я вам указываю, что ситуация нетипичная для разработки, более того, если я правильно понял, что вы имеете ввиду (правка кода на боевых серверах), противоречит общепринятым стандартам. Грубо говоря, удобство IDE в такой ситуации безусловный плюс, но относится ли это к делу?

То есть по-вашему я пользуюсь «нетипичным» функционалом, иными словами некими костылями, для того чтобы управлять процессом разработки отличающимся от каких-то ваших «общепринятых стандартов»? И по какому-то невероятному стечению обстоятельств IDE покрывает этот функционал. Нет, я всё понимаю, ребята из jetbrains сидели со мной в одном здании, но мамой клянусь, они сами догадались что именно это мне и нужно.

простите но мне кажется вы в плену собственных «типичных» шаблонов и продолжать ломать копья тут нет смысла

В VIM есть неплохой плагин для TODO. VIM покрывает и этот функционал. Есть функционал календаря, и тоже неплохо работает. И т.д. и т.п… И да, это как-то отдалённо можно связать с разработкой (ведь разработчику надо где-то записывать задачи и планировать свой день), но это не имеет никакого отношения к дискуссии.


До того, как вы упомянули о озвученной функции, мне тоже казалось, что она не имеет отношения к дискуссии, т.к., мне казалось, не должно иметь отношения к процессу разработки. И под управлением проектом, я понимал что-то другое. Но я не истина в последней инстанции, безусловно. И в вашем, например, случае я ошибался. Если вам удобно так работать и IDE решает вашу проблему — то я очень за вас рад.


Отмечу только, что для VIM есть несколько плагинов для решения вашей проблемы (если, повторюсь, я её верно понял), вот например с видеодемонстрацией.

На мой взгляд, основная проблема использования Vim/Emacs вместо IDE в том, что они не понимают язык, с которым работает программист. Для редактора это всего лишь текст, он не понимает функции, не понимает синтаксис, не может вывести типы и подсказать параметры для конструктора или метода. Один этот печальный факт для меня перечёркивает все остальные достоинства. Да, Vim быстрый, удобный (если привыкнуть), есть масса плагинов для всего на свете, как и у емакса, подсветка синтаксиса и прочее. Но когда поработаешь достаточно долго в Eclipse или Qt Creator, понимаешь, сколько времени и сил может сэкономить умная IDE.

Например, помимо уже упомянутого переименования с учётом контекста (переменная i превращается в counter только в текущей области видимости, а не по всему коду), и в Eclipse CDT, и в Qt Creator можно выделить фрагмент кода и вырезать его в отдельную функцию. При этом IDE автоматически выведет необходимые параметры для функции и даст им имена, а также выведет тип возвращаемого значения, на месте же фрагмента кода появится вызов новой функции со всеми нужными параметрами. Ваш редактор такое может? (смайлик) На самом деле, редактор такое и не обязан уметь по определению, он всего лишь работает с текстом и не разбирается в том, что в каких-то языках есть строгая типизация, в каких-то нет, и в некоторых случаях можно попытаться угадать, что в данном месте можно написать, учитывая информацию из стандартной библиотеки, синтаксиса языка и видимости функций, переменных и классов в данной точке кода. Простая подсказка по аргументам функции сама по себе здорово экономит время и нервы, т.к. в хорошем коде по именам параметров и их типу уже ясно, что функция хочет. В документацию лезть приходится в разы реже.

Конечно, тут можно привести много контраргументов, например, можно выдавать подсказки по javadoc/jsdoc/phpdoc/etc., а если таковой док не написали, значит, программа/программист плохи, код не документирован и вообще, ваша проблема не в этом. Тем не менее, к хорошему быстро привыкаешь, как вы сами заметили, и хочется носить свой комфорт с собой. Как бы ни тормозили IDE, они тормозят с благой целью. Постоянно поддерживать актуальные знания о всём коде — не самое дешёвое занятие. Поэтому лучше проапгрейдить железо, переехать на SSD, но сохранить удобство понятливой IDE, чем мириться с отсутствием рефакторинга и банального поиска по коду с учётом языка. Например, нужно найти все вызовы метода run() у объектов класса SomeDataProcessor и только у них. Таких методов может быть масса у самых разных классов, включая системные, и редактор для этой задачи бессилен.

Так что я использую Vim по его первоначальному прямому назначению — для быстрого редактирования текстовых файлов, обычно конфигов. И с этим он справляется просто замечательно.

А для JavaScript?
Пользуюсь Idea, преимущество перед текстовым редактором — только в удобстве переименования переменных/функций.

Не пишу на JS, использую GWT, он пишет за меня. Разумеется, всё это очень субъективно. Например, в JS провести рефакторинг автоматически вряд ли возможно в принципе, так что тут и обычного редактора хватит. Слишком уж динамический язык. Зато поддержка удобного и быстрого деплоя и хорошая работа с DVCS будет плюсом. Хотя опять же, я ничего более функционального, чем EGit в Eclipse, пока не встречал. Git-Cola больше всех к нему приблизилась, но возможности ручного редактирования индекса в ней нет, к сожалению, да и push часто виснет намертво. Изредка бывает надо закоммитить что-то, чего нет в рабочей копии.

В целом же, после обвешивания плагинами Vim/Sublime/Emacs получится та же IDE. Не факт даже, что более быстрая при той же функциональности, а скорее всего, менее функциональная, и причины этого я уже описал. Так что стоит ли овчинка выделки, каждый решает сам.
Более функционального плагина для работы с гитом, чем Magit для емакса я не видел, хотя пользовался и Pycharm и vim-fugitive
Конечно, тут можно привести много контраргументов, например, можно выдавать подсказки по javadoc/jsdoc/phpdoc/etc., а если таковой док не написали, значит, программа/программист плохи, код не документирован и вообще, ваша проблема не в этом.


Тут может быть другой контраргумент — современные сайты это солянка из языков и технологий. Допустим для Idea можно собрать плагины для symfony+knockout+jQuery+requirejs+clojure+еще какая-то хрень, чтобы были доки и автодополнение. Но мы получим ту же проблему как если бы собирали свой конфиг для vim/emacs: часть плагинов кривые, каждый плагин делает IDE чуть медленнее. И все равно в итоге будут куски «кода в коде», на которых подсветка и рефакторинг сломается.
Но мы получим ту же проблему как если бы собирали свой конфиг для vim/emacs: часть плагинов кривые, каждый плагин делает IDE чуть медленнее.


первое изредка случается (как правило — нет), второе, скажем так, голословненько, замеров бы в студию.
все равно в итоге будут куски «кода в коде», на которых подсветка и рефакторинг сломается.


вот и продемонстрировали бы наглядно
По-моему, это уже более фундаментальная проблема индустрии, смешивание разнородных технологий и платформ. Некоторые называют это «каждой задаче свой инструмент», но если под задачей понимать слишком маленький юнит работы, получается вот такая солянка из пяти разных языков и парадигм. Зато если во всём этом разбираться, можно стать незаменимым и ценным сотрудником…

Для себя, как уже написал выше, я решил проблему использованием GWT, но понятно, что чаще всего, в случае коммерческой разработки в более-менее долгоживущей компании, выбор уже сделали за вас.
Кстати, как найти все вызовы метода у объектов определенного класса?
А как например синхронизироваться с Youtrack и ему подобными? Спасибо.
Несколько раз (2-3 точно) пытался начать использовать vim для написания кода (просто как текстовым редактором пользуюсь им регулярно). Все эти несколько раз мне это быстро надоедало. В IDE (WebStorm, Idea) все работает сразу из коробки: подсветка, автоформатирование, навигация, рефакторинг, vcs и многое, многое, многое… Джетбрейновские IDE настолько хороши, что ты их просто не замечаешь, я ни о чем не думаю и просто пишу код. Возня с vim — это непрерывный перебор плагинов, каждый из которых в чем-то ущербен, копание в конфигах и несовместимый ни с чем набор горячих клавиш. Не могу понять вимеров…
Вот короткий вопрос, какой плагин мне нужно поставить чтоб иметь такой автокомплит?
image
JavaScript. Если подскажете как получить такой же результат в VIM — сделаю еще одну попытку.

На деле же, tern работает через раз: иногда виснет, иногда выдаёт чушь.

Ок, нашел время на эксперимент. Помучился немного с установкой YouCompleteMe и…

image

Неплохо, честно признаюсь, не ожидал.
Попробуем что-нибудь посложнее:

image
image

Oops…

Нет, пока не вижу причин переходить на VIM.
Короткий контрвопрос: а если строчку с объявлением переменной p вынести в другой файл, а потом подключить его через php-шный инклуд, то вывод типов сработает?

А если допустим все даже будет в одном файле, но этот файл будет php-шаблоном и иметь такой вид:

let p = Promise.resolve(new Date({% if startDate is defined %}"{{startDate}}"{% else %}"2015-01-01"{% endif %});

p.then((d) => d.???


Может так конечно писать и нельзя, но ведь пишут же.
Естественно сработает, вы думали что для IDE весь проект пишется в одном файле?

Хотя да, для IDE многие проекты пишутся особым образом.

Ого. Похоже JetBrains далеко ушли от "подставить все слова, что есть в файле, в autocomplete" в JS. И часто подобная "магия" срабатывает?

Достаточно часто, чтобы имело смысл платить за WebStorm.
Подобный автокомплит для JS реализуется через Tern. Соответственно, наверняка есть плагин и для вим. Ах да, вот и он.
Джетбрейновские IDE настолько хороши, что ты их просто не замечаешь, я ни о чем не думаю и просто пишу код

Помнится на моей предпоследней работе меня пытались перевести на PHPStorm (до того около двух лет сидел на нем под свободной лицензией). Положил я мышку поближе, открыл проект, создал новый файлик для будущего класса, набираю, значить, «class », и ничего, IDE ставит мне табуляцию после ключевого слова. Ок — думаю я — забыл настроить. Залез в конфигурацию сниппетов, написал решение для генерации класса, сохранил. Радостно создал класс из снипета. Набираю дальше «pub» и ничего, IDE мне ставит пробел после pub. Точно уже не припомню, но вроде нашел плагин для автодополнения ключевых слов по пробелу. Довольный захожу в каталог models/Application/Services, создаю в нем файл MailService, открываю его и… IDE открывает мне пустой файл. Опять лезу в настройки, прописываю шаблон для php файлов, удивляюсь что шаблоны не завязаны на каталогах. Открываю файл для будущего сервиса повторно, а у меня там namespace не правильный. Злобно жму на клаве ":q", а IDE не реагирует. Ну и матерился же я тогда.
UFO landed and left these words here
Я для вас diff сделаю, чтоб было заметно:
Помнится, на предыдущей работе меня пытались посадить за праворульную тойоту-электромобиль (до этого трактор беларусь водил)

Помнится на моей предпоследней работе меня пытались перевести на PHPStorm (до того около двух лет сидел на нем под свободной лицензией)
UFO landed and left these words here
Только не понял, при чем тут :q в конце

Это я о привычках. Многие новички проклинают Vim за то, что в нем нет привычных команд. Вы в их числе? )
кстати, разве у него есть свободная лицензия?

Они раньше давали лицензию для Open Source проектов, не знаю выдается ли она сейчас. Вот у меня была такая.
вимовские паттерны вы и пытались применить к шторму

Что за вимосвкие паттерны? Сниппеты и шаблоны?
Кстати, трактор беларусь я не ругаю, никоим образом! Попробуйте легковой тойотой вспахать поле. ;) Вим — отличная штука. Шторм — отличная штука. Пользуюсь и тем и другим, счастлив и доволен.

Я не тот, кто с этим спорит )
UFO landed and left these words here
Только вы начали со шторма, а закончили вимом

А есть разница с чего я начал и чем закончил? Многие плюются на Vim потому, что в нем нет привычных функций, я вот плюнул на IDE потому что в ней нет привычной комбинации. Что я сделал не так?
что был шторм со свободной лицензией

Шторм, за лицензию которого я не платил — скажем так )
каких-то очевидных действий от шторма, к которым привыкли в виме. Например, шаблон нового файла, снипет, и т.д.

Ну как бы да, я привык к тому, что в каталоге Modules/ у меня все новые файлы заполняются таким шаблоном, а в каталоге Services/ другим, и namespace правильно выставляется. Это паттерн Vim? А более менее умные сниппеты тоже только в Vim существуют? Сомневаюсь.
И о чем тогда ваш комментарий? О том, что ваше рабочее место оказалось с затертыми дефольтными конфигами?

О том что IDE из коробки этого не может, как и Vim.
UFO landed and left these words here
Вы либо излагаете аргументы, а оппонент, пользуюясь общим с вами знанием человеческого языка и предметной области, их интерпретирует и отвечает контраргументами, или вы выдаете рандомные бессвязные фразы, и оппонет удаляется с поля брани

Это замечательно, что вы так полно излагаете свои мысли, но вы не можете ответить на мой вопрос, при этом ставите его во главу угла.
Но дефольтное поведение шторма — это не клик по «создать файл», после чего получается файл и в нем — магическим образом появляется определение класса

Я хочу магию, чтоб редактор знал что мне нужно в конкретном файле, конкретного каталога. Vim умеет, моя IDE (на тот момент) не умела. Так в чем проблема? Я плохой, что такое придумал?
никак не является паттерном шторма

Знаю, и это печально.
Поэтому я вообще не понимаю, как вы до этого работали на нем около двух лет, после чего сели за него же, и у вас ничего не получается

Так дело привычки, же. На Vim я привык к удобству и магии, а тут — на тебе, редактор без бубнов и плагинов не может даже файлик шаблоном заполнить. Не порядок!
Вим этого из коробки не может

Я о том и говорю что — тоже не может. Читайте внимательно, пожалуйста, мои комменты. Вы упускаете суть, а она важна.
. А вот ИДЕ как раз может из коробки создавать дерево файлов по вашим классам

Но не может заполнить файл шаблоном на основе каталога и сформировать namespace автоматически. И что это еще за дерево файлов по моим классам?
UFO landed and left these words here
А можете повторить тот вопрос, который я поставил во главу угла и на который не ответил?

А есть разница с чего я начал и чем закончил?

откуда у вас между двумя периодами работы в шторме поивились неожиданные для иде требования

Шторм -> Vim -> Попытка вернутся в Шторм.
Не на вим, а на настроенном вим с тучей плагинов и непростым конфигом

Ну так себе утверждение конечно, но да, и Шторм надо настраивать, и Vim. Почему многие приводят необходимость настроки среды разработки под себя, как некий минус этой среды?
Ну, просто дело делается не так, как для вас логично. Так и вим может работать не так, как кому-то логично

Не столько логично, сколько — Удобно. Зачем мне заполнять в Шторме имя класса, его namespace и т.д., если Шторм может это получить из файла и его расположения. Понимаете к чему я веду?
так уж совпало, что мои ожидания не были испорчены тем вим-плагином

У вас испорчены, у меня улучшены. Для вас есть только одна модель создания и заполнения класса, для меня их множество (контексто-зависимые). Видите, IDE вам диктует правила работы, а я свободный человек )
Если другие преимущества перевешивают это неудобство, то почему бы и не переучиться?

Да я прекрасно умею пользоваться Штормом. Переходить стоит от того, что IDE знает язык, на которым я пишу, а Vim нет, это серьезное отличие, особенно для человека, который пилит инструмент под себя.
Может, работодатель заставляет?

Все пытались, но не заставляли.
Речь о PSR-4.

А зачем это вообще может быть нужно? В смысле вы создаете классы, а IDE вам их по папкам расскидывает?
UFO landed and left these words here
это, по моему замыслу, поясняло разницу.

нисколько
Но еще раз о разнице: настройка иде — клики по галкам, настройка вима — плагины, конфиг, перезапуски, отладка конфига

Таки да, Vim не слишком графический редактор )
Т.е. удобно то, что привычно, что первое

Удобно это еще когда — захотел и сделал.
А где видно, что у меня только одна модель создания и заполнения класса?

Ну так — нажал «Создать класс», заполнил пару полей, доволен. Есть еще варианты в Шторме без подключения плагина?
Кстати, отверка вам диктует, как ее держать и как винтик крутить — вас это не напрягает?

Когда напрягает, я ищу подходящий инструмент.
А вим вам диктует модальность — не напрягает

Что за модальность такую диктует Vim?
Не напрягает — потому что привычно, а привычное — удобно

А еще привычное имеет свойство отрицать лучшее. В некоторых деталях это может быть важно.
В таком случае не ясно, почему возникли проблемы, и вы «матерились же тогда»

Так я же написал почему, перечисленного мной не было из коробки, а не из коробки я мог и Vim настроить.
Есть общепринятый стандарт

Давайте исключим слово — общепринятый — хорошо? )
Строго говоря, с точки зрения стандарта: рекурсивно создаете директорию неймспейса

Так дело не только в неймспейсе. Я, к примеру, хочу определенный шаблон для тестовых классов, классов моделей, контроллеров и сервисом.
UFO landed and left these words here
Этот диалог можно продолжать долго, но боюсь мы ни к чему не придем, видимо кто то из нас не хочет слушать собеседника.
UFO landed and left these words here
Хабр не лучшее место для этого, поверьте. Если вам действительно интересно, можно переговорить в скайпе.
UFO landed and left these words here
Хабр — не лучшее место для приобретения навыков?

Хабр это место, где тебе могут слить карму за то, что ты идешь против модного, современного, молодежного. Вы об этом не знали? Будьте в курсе. Если вы хотите приобретать навыки, то читайте статьи и общайтесь с коллегами, комментарии на хабре не лучшее место для этого.

Ну ок, как я понимаю, вам важнее ЧСВ, нежели диалоги. Дайте мне уже тогда конкретное решение тех тасков, что я привел в моем первом комментарии этой ветке. Не отмазки типа — а в IDE этого не нужно, это ваши шаблоны — а конкретное решение для IDE или Шторма (если вам так угодно). Это мой use case и я хочу чтоб это так работало.
UFO landed and left these words here
Вы сводите хабр к карме?

Слейте себе карму в -50, а потом напишите мне в комменты, что есть хабр, ок?
На счет настройки вашей иде

Слив засчитан. Наверно дело было в том, что " в огороду бузина, а в киеве дядька", верно? ))

А самое интересное во всем этом пустом диалоге то, что когда пользователь Vim говорит — мне это в редакторе не нужно — ему отвечают — не нужно потому что Vim не умеет, ахаха — но когда чего либо не умеет IDE (не умеет от слова «мастер не способен заточить инструмент»), то это проблема пользователя, а не IDE, это он плохие таски ставит перед инстументом )) Я не желаю продолжать больше этот монолог, он не имеет смысла и не несет для меня никакой пользы. Вам счастливо зарабатывать по 100 у.е. в час ;)
UFO landed and left these words here
У меня процессор A8-6600K и джетбрейновские IDE (конкретно PyCharm) виснут так сильно, что я просто не могу ими пользоваться — эти тормоза перекрывают все удобства. По сравнению с этим лагодромом даже IDLE удобнее.
UFO landed and left these words here
Нет, не пользуюсь. Я если честно вообще не люблю ничего настраивать, привычка использовать все дефолтное имеет свои плюсы, позволяет комфортно себя чувствовать за любой машиной, любой операционной системой, любым редактором (ну почти :) в emacs я немного теряюсь ))
Vim хорош тем, что в нём есть режим вставки, нормальный режим и режим выделения, а не плагинами и не легковесностью. Критика вима, соответсвенно, сводится к критике наличия этих режимов. Если вы сравниваете вим с IDE, то очевидно вы неправильно понимаете зачем вим вообще нужен.
Если бы вы сказали, что идея со включеным эмулятором вима лучше чем просто вим, или что блокнот лучше вима, потому, что там не надо переключаться между режимами — было бы понятно что вы имеете в виду.
А так ваша аргументация сводится к тому, что IDE лучше текстового редактора. Не обязательно вима, а вообще любого.
Обратите пожалуйста внимание на заголовок поста:
VIM: зачем, если есть IDE, и как?
Я может быть и сравниваю, но не я это начал :) И в первом своем комментарии, я указал на то что сравниваю я в контексте написания кода.
А так ваша аргументация сводится к тому, что IDE лучше текстового редактора. Не обязательно вима, а вообще любого.
Именно так, для написания кода в большом проекте — IDE лучше текстового редактора. Не обязательно вима, а вообще любого. Только приверженцы вима и емакса больше других склонны спорить с этим утверждением.
Мне кажется, что если дать определение IDE, то выяснится, что вим с набором плагинов этой самой IDE является. И соответственно можно будет сравнивать вим с конкретным набором плагинов с конкретной IDE, а не вим с IDE вообще. И это будет хорошее сравнение. Возможно не в пользу вима с конкретным набором плагинов.
Сильно зависит от определения. Например, включено ли в него обязательным пунктом полноценный синтаксический анализ в фоне.
Синтаксический анализ к виму прикручивается плагинами. Можно прикрутить clang для С++, для C# есть какой-то демон, который интегрируется с чем хочешь и есть для Go плагин, который использует стандартные тулзы.

Определением конечно можно поиграть и обратить внимание на то, что у вима вообще проблемы со словом бекграунд, но по моему они не то чтобы очень принципиальны в данном случае.
Вы под синтаксическим анализом что имеете в виду? Анализ на синтаксическую корректность или полное построение модели проекта, например, с целью автоматического вывода типов для контекстного автодополнения?
Полное построение модели проекта. Как, например, clang это делает.
Пользуясь обилием в комментариях пользователей IDE, спрошу. Господа, а что вы собственно говоря постоянно переименовываете и зачем?
Ну так: красная полоска, зеленая полоска, рефакторинг.
Бывает, функция оказалась названа неудачно. Банальная малозаметная опечатка, либо же функциональность немного изменилась/расширилась в процессе разработки. Такое случается, и лазить с грепом по всему коду не всегда оказывается продуктивно. Или были две функции с одинаковым именем (например, add), но разными аргументами, на какой-то стадии разработки стало ясно, что их поведение теперь значительно отличается (одна стала более интуитивно понятна как insert). Переименовать одну, не затронув другую, без IDE затруднительно.
В том-то и дело, что вы вроде как пищите очевидные и правильные вещи, но я сталкиваюсь обычно только с необходимостью переименования когда архитектура подожмет, а такое бывает довольно редко. Эх, хоть бери да устраивайся в бодишоп, чтобы ходить и заглядывать людям через плечо, наблюдая за методикой их программирования.
Но всё же, если архитектура подожмёт, лучше иметь такое средство, чем не иметь, не так ли? Бывают и другие случаи. Например, поскольку английский язык мне не родной, я могу неправильно выбрать слово для названия переменной или функции. Особенно, когда речь идёт о бухгалтерских приложениях и прочем матучёте. Живой пример: как назвать уволенного работника? Exempted? Fired off? Discharged? Dismissed? Released? Масса вариантов. В большой команде наверняка есть специально обученные люди, которые дадут однозначный и верный ответ на этот вопрос, и ответ будет записан в глоссарий, которым потом другие будут пользоваться. Так получилось, что я пишу софт один, с недавнего времени, вдвоём. Когда кода много, можно запросто в одном месте использовать одно слово, а в другом другое, и всё это будет выглядеть запутанно и плохо. Или же наступит такой день, когда сей вопрос для меня полностью прояснится, и тогда будет правильно переименовать все функции и переменные как положено. Когда в проекте 10-15к строк, провернуть такую операцию без особого риска причинить collateral damage в коде не так-то легко, даже если используется IDE. Но она, по крайней мере, может сильно уменьшить количество ручных правок.
Ещё бывает, что надо посчитать сумму чего-либо. Посчитал, положил в переменную sum. Позже выяснилось™, что таких сумм может быть несколько, и их общая сумма тоже нужна. Ну ладно, вот вам переменная total. После третьего уровня суммирования становится несмешно, и появляется необходимость упорядочить этот зоопарк сложения, и здесь будет, наверно, правильным переименовать безликие переменные во что-то определённое, типа totalWares, totalInvoices и прочее.
Вообще рефакторинг — это далеко не только переименования, лично я ещё пользовался:

— выделить абстрактный класс с общим функционалом
— перетащить общий функционал в класс-предок
— вынос константы
— вынос переменной
— вынос куска кода в виде функции

Не подскажу — пользуюсь продуктами JetBrains (если быть точным — Idea, т.к. основной язык программирования — java).
PhpStorm вам не подходит?

Пишу на JavaScript. Использую SublimeText 3 (не Vim, но и не IDE). В последнее время немножко вожусь с кодом на Scala. Учитывая как долго эта дурь компилируется мне чертовски не хватает IDE фич, вроде умного autocomplete, подсказок по наведению на слово, подсветки грубых и не только ошибок, jump to definition и т.д… Я понимаю, что в рамках инфраструктуры Scala, мой текстовый редактор попросту каменное орудие. В то время как существуют такие IDE как Idea.


Насколько я понимаю, используй я не ST3, а Vim или Emacs, я бы точно также чувствовал себя словно пещерный человек. Такие языки просто генетически предрасположены к синтаксическому анализу и соответствующим возможностям. А вот на JavaScript-е писать да, и Vim и ST3 и Emacs и что-нибудь более модное типа атома, это просто вкусовщина. Чуть завернул какой магии сложнее 2+2 и IDE сдулась :)

Вы ими пользовались? Просто подобные штуки есть и под Sublime. Я пробовал ими пользоваться. Удалил через 5 минут. Жалкая пародия на IDE. Оценить конкретно эти плагины не могу, т.к. я из категории тех людей, которые случайно открыв Vim, потом 10 минут разбираются как его закрыть :) Хотелось бы услышать мнение о работе этих плагинов для Scala, C#, Java, C++ и пр.

Конкретно теми, что по ссылке — нет. Но в интернетах хвалят.

Посмотрел на Tern для ST3. Jump To Definition, просмотр документации и rename в простых случаях умеет. Это конечно не IDE, но уже что-то. Спасибо за наводку.

Я много читал про Vim и чаще всего — хвалебные речи. Подумываю попробывать перейти на него, но у меня созрели вопросы.
В IDE я могу сделать пошаговую отладку, заглядывая на каждом шаге в регистры процессора и это иногда очень важное и необходимое действо. Возможно ли в Vim'е сделать подобное? Ну и выше уже писали про умный рефакторинг кода с автоматической вставкой отрефакторенного
> IDE значительно тяжелее VIM (даже с плагинами);
… именно поэтому у моего коллеги VIM отъел больше 2 гб озу, где-то как мой Eclipse. Я уже молчу про то, что в современном мире это не имеет никакого значения.

> IDE обычно поддерживает небольшое число языков/платформ.
Большинство программистов работает с весьма ограниченным стеком языков.

> Vim может работать в режиме только консоль.
Спасибо, у меня есть Remote Desktop. Да, я не админ, всего лишь программист.

> Сама идеология Vim — очень мощная штука в сравнении с классической IDE. Есть книга Practical Vim: Edit Text at the Speed of Thought, её название («редактируй текст на скорости мышления»)
Я думаю медленее, чем печатаю. Хотя, конечно, можно просто сказать, что я плохой программист. Я уже молчу о необходимости чтения специальных книг по редактированию текста, вы серьёзно вообще? Некоторые неплохие программисты даже печатать вслепую не умеют…

> С Vim вам не понадобится мышь, если вы конечно этого захотите.
Мышь чертовски удобна для скролла по файлам и перехода в нужное место. Я не понимаю в чем профит от НЕиспользования мыши: когда ты набираешь код, то обычно ты вбиваешь один большой последовательный блок, ± пара линий вверх-вниз (стрелочки). В остальных случаях мышь не является тормозом.

> Vim невероятно расширяем, любая ваша хотелка так и или иначе реализована или может быть реализована в Vim.
Опять же, я, наверное, плохой программист, но я хочу, чтобы инструмент работал из коробки (настроить только хот-кеи/форматирование кода).

> Ваша конфигурация для VIM вообще без труда переносится с машины на машину. Будет ли так просто с вашей IDE?
Да. Все современные IDE поддерживают иморт/экспорт настроек. Но как я упомянул выше, настройка занимает минут 15, так что можно если что настроить с нуля.

У меня на работе куча народу пользуется VIM, но как по мне это до ужаса неудобно. Каждый раз сердце кровью обливается, когда человек вбивает команду в консоли, чтобы открыть файл или добавить его в чендж лист. Или вбивает команду, чтобы проскроллить файл. Так что сейчас, в 21-м веке, я предпочту пользоваться благами цивилизации (IDE).

Или вбивает команду, чтобы проскроллить файл

Это что за команда такая? :normal j?
Каждый раз сердце кровью обливается, когда человек вбивает команду в консоли

Знали бы вы как я страдаю, когда вижу дергание рук между FJ и мышкой/тачпадом.
Bro
image
Не помню точно, но в там определенно есть что-то вместо/алтернативно shift+end.

> Знали бы вы как я страдаю, когда вижу дергание рук между FJ и мышкой/тачпадом
Руками двигать полезно :) Ну и я не понимаю, в чем выигрыш от вбивания имени файла (которое еще и забыть можно) в отличие от выбора файла в дереве мышкой. Опять же, навигация и кодинг — более-менее разделенные процессы. Мне весьма редко приходится одновременно редактировать десяток файлов.
А что делает shift+end? Переход в конец строки? Там для этого shift+4, но я предпочитаю shift+a
Руками двигать полезно

Не особо, если это отвлекает от процесса набора текста.
от выбора файла в дереве мышкой

Как правило (как правило!), один каталог проекта может содержать десяток файлов и папок, и чтоб выбрать нужный файл мышкой (или не мышкой), нужно сначала найти этот файл в списке. Сделать это можно путем последовательного чтения всех файлов (можно мышкой двигать сверху вниз, чтоб не сбиться, а можно стрелку вниз или j нажимать) или набрав какую нить поисковую команду. Заслуги IDE или редактора тут нет, кому как привычнее.
Мне весьма редко приходится одновременно редактировать десяток файлов

Мне постоянно приходится это делать. Как правило это четыре типа файла: Модель, Контроллер, Шаблон, Библиотека. Удобно, когда каждый в своей вкладке, а вкладки могут делится на подвкладки.
> А что делает shift+end?
Ctrl+end, ошибся. Стандартный шорткат перехода в конец файла (ну, кроме особых программ вроде вима).

> Не особо, если это отвлекает от процесса набора текста.
Когда я выбираю файл, я не набираю текст.

> Как правило это четыре типа файла: Модель, Контроллер, Шаблон, Библиотека.
Для этого есть табы (вроде есть даже хоткеи для перехода по ним, хотя я обхожусь без них обычно).
Ctrl+end, ошибся. Стандартный шорткат перехода в конец файла

В Vim проще, для этого есть shift+g.
Когда я выбираю файл, я не набираю текст

Вы мышкой пользуетесь только для выбора файла? Похвально, вам осталось совсем чуть чуть ;)
Для этого есть табы

Да, я знаю. Замечательная штука, не правда ли?
UFO landed and left these words here
Если вы в режиме нормал, то Shift-G, да

А зачем вам прыгать в конец файла в режиме insert? Вы перешли в insert mode, набрали текст, вышли из него, пошли гулять по файлу. В Vim так принято работать.
Я к тому, что в вим не проще — в разных режимах по-разному, и у вас не получится учить режимы отдельно, т.к. для работы нужны практически все они

Мне кажется, вы просто не привыкли к режимной модели Vim, потому вы пытаетесь серфить по файлу в insert mode, что не есть хорошо.
А вот Ctrl-End — универсальный шорткат для для любой текстовой области в любом вин-приложении

Да, если я сейчас сяду за блокнот, то мне будет очень неудобно. Но блокнот и рефакторить не умеет, так что теперь, не пользоваться благами IDE? Так себе аргумент.
А Ctrl-End — универсально везде

У меня Vim везде.
UFO landed and left these words here
А я новичок

Когда я говорю, что «в Vim проще», я не имею ввиду новичков и кривую обучения.
Я только сказал, что на вопрос «как мне переместиться в конец файла?» вимер должен дать ответ в контексте режимов

Совершенно верно.
Можно научиться, конечно, но почему бы не воспользоваться своими же бест практисес из программирования и не перестать множить сущности, начать повторно использовать скилы?

От того, что некий антипаттерн все повсеместно используют, я не начну им так же повсеместно пользоваться. Все просто.
UFO landed and left these words here
И второе явно не «проще» первого, потому что упоминает еще и концепция режимов

Не путайте кривую обучения и простоту.
Кривая обучения — это как просто изучить нечто
Простота — это как просто пользоваться тем, что уже изучено
Но, думаю, если бы вы имели в виду именно эту простоту, то так бы и сказали четырьмя комментариями выше

Да именно это я и подразумиваю под простотой.
UFO landed and left these words here
как проверите (или переключите) режим

Это делается на автомате. Обычно вимеры не сидят в insert mode, ввели что то и сразу вернулись в normal mode. Потому проверок не требуется.
> Вы мышкой пользуетесь только для выбора файла?
Не только. Речь не о мышке, а об интеграции: в текстовом редакторе нет дерева файловой системы, нет интеграции с контролем версий, нет интеграции с билдом и тестами, нет подсветки синтаксических ошибок, нет интеграции с дебагом, нет языко-зависимого рефакторинга. А если вы каким-то образом добились всего этого в VIM c помощью дестяка-другого плагинов (не буду врать, не знаю, насколько это возможно), то поздравляю, вы собрали кривую IDE на коленке с VIM-mode вводом текста.
вы собрали кривую IDE на коленке с VIM-mode вводом текста

Разница между моей IDE и любой другой в этом случае будет в?
В количестве потраченных на неё человеко-часов и общей продуманности. Ну и предложенные мною фичи в виме выглядят весьма утопично — все мои коллеги, которых я видел в процессе работы, использовали вим только для редактирования файлов, остальное из командой строки. Я даже табов-то не видел ни у кого толком :)
количестве потраченных на неё человеко-часов

В Vim за десять минут можно поставить все нужные для работы плагины (если знаешь что ставить и как они работают).
общей продуманности

А поконкретнее?
Ну и предложенные мною фичи в виме выглядят весьма утопично — все мои коллеги, которых я видел в процессе работы

Ну это проблема ваших коллег на самом деле.
Давайте вы мне покажете приличный, по вашему мнению, сетап ИДЕ на основе вим, а потом сравним с любой ИДЕ от JetBrains, например. Хотя я подозреваю, что половину функциональности невозможно обеспечить в принципе. Ну и в любом случае с каждым плагином теряются все те преимущества, что перечислены в статье, остается лишь странный метод ввода, который в теории, после Н часов чтения книг, практики и прохождения специальных тренировок, может обеспечить прирост в 10 процентов к скорости написании (а может и не обеспечить).
Давайте вы мне покажете приличный, по вашему мнению, сетап ИДЕ на основе вим

Что еще за «сетап ИДЕ»? Vim не умеет понимать код, он в принципе не может быть IDE. Если с вами об этом начнут спорить, смело обвиняйте человека во лжи.
а потом сравним с любой ИДЕ от JetBrains, например

Не надо сравнивать Vim с решениями от JetBrains, поверьте, Vim и JetBrains это как камень и камень с мозгами. Совершенно разные вещи.
Хотя я подозреваю, что половину функциональности невозможно обеспечить в принципе

Знаете как в песне поется — фсе возможно, после долгих ночей возможно. Так же и в Vim.
Ну и в любом случае с каждым плагином теряются все те преимущества

Куда это они теряются?
> В Vim за десять минут можно поставить все нужные для работы плагины
> Что еще за «сетап ИДЕ»?
Вы сами себе противоречите. Написали же о каких-то плагинах, которые добавят все фичи, которые имеются в нормальной ИДЕ. А теперь выясняется, что нет ничего такого.

> Совершенно разные вещи.
Одна из которых полностью заменяет другую.

> Куда это они теряются?
Редактор становится тяжелее, он уже не работает одинаково со всеми языками. Какие еще там «киллер-фичи» остались?
Вы сами себе противоречите. Написали же о каких-то плагинах, которые добавят все фичи, которые имеются в нормальной ИДЕ

Вы выдаете желаемое за действительное. Я повторю то что написал — В Vim за десять минут можно поставить все нужные для работы плагины
Делается это достаточно просто, ставите какой нить менеджер плагинов, затем скачиваете или заполняете нужные вам для работы плагины (кроме плагинов, завязанных на семантическом разборе кода, под Vim есть все) и ждете пока менеджер их установит. Радостно пользуетесь.
Одна из которых полностью заменяет другую

Ну кому как, я вон выше уже писал о моих проблемах в IDE. Не заменило, а ведь хотелось, и до сих пор не против перейти.
Какие еще там «киллер-фичи» остались?

normal mode

Я полностью согласен с тем, что несомненным плюсом Vim является легковестность, большое число поддерживаемых ЯП, расширяемость. Возможно (сам не пользовался), там можно редактировать и набирать текст с огромной скоростью (хотя я упираюсь в скорость печати).
Но IDE есть IDE. Сам я пишу на C#, использую Visual Studio. Да, она занимает черт знает сколько места, запускается черт знает сколько времени и вообще чертовски тяжелая. Но она, как и другая "средняя IDE" позволяет делать следующий, очень удобный набор функций:


  • Умный автокомплит, который показывает существующие классы, методы, втч написанные мной, сигнатуры методов с описанием из метаданных
  • Аналогичная умная подсветка, которая понимает, какое слово чем является
  • Переход к определению, при этом во всем проекте (Sublime умеет в рамках одного файла)
  • Показывает сколько раз и где метод\класс используется
  • Рефакторинг

Все это настолько удобно, что я готов смирится с прожорливостью IDE, и, к сожалению, не реализуемо в не-IDE

Так и тянет спросить, а никто случаем не запускал Vim под Windows со смешанным Арабско(урду, персидско)-английским текстом?
UFO landed and left these words here
Вот-вот… Собственна, одна из причин, почему пришлось исключить Vim из списка используемых редакторов и была связана как с его нелюбовью к нестандартным языкам, как и со спецификой обработки больших XML… А я то надеялся. В общем, Notepad++ & Sublime оказались все-таки покомфортнее.
Если нашли хорошее решение для навигации по гигабайтным дампам в xml, то поделитесь им пожалуйста.
Глупости какие-то, никакой редактор не может быть полноценной заменой IDE. Приобрести мощное железо не должно быть проблемой когда компьютер является твоим основным рабочим инструментом, речь идет о продуктивности работы.
UFO landed and left these words here
Именно, лучше использовать полноценную IDE чем собирать свой «супер» редактор из кусочков разбросанных по всему интернету. Видимо кому-то просто нравится возиться с редактором и «допиливать» его, вместо делания полезной работы. Не говорю уже о продуктивности работы в редакторе и IDE.
А под полезной работой, вы, по всей видимости, понимаете написание проекта за который вам будет капать денюжка?
Не обязательно денюжка, бывают ведь всякие любители опенсорсить, в гитхаб там что-то покомитить и тп.
Ну так в чем же бесполезность допиливания редактора? В смысле, а если я свою работу в опен сорс выложу.
Это уже было бы вредительство, поддерживать на плаву архаичные инстурменты разработки. Но как хобби пожалуйста, я ведь пишу «Видимо кому-то просто нравится возиться с редактором и «допиливать» его, вместо делания полезной работы».
Так под линюхами оно цветёт и пахнет. За 50 лет юниксов не сделать нормального отладчика — это должен быть где-то специально обученный вредитель. Срачи на тему VIM<->Emacs, а потом приходит Sublime, борет всех и они чешут в затылках: «да, конечно, он неплохой, и производительность выросла… Зато знаете как удобно из vim по :q! выходить? И сразу всё понятно — вышел и не сохранил...». Тьфу, блин.
Даже в линухах бывает не слишком стукнутые на голову люди, я например уже давно полностью перешел на линукс, и тем не менее никакими VIM/Emacs/Sublime (Atom зыбыли) и прочими хипстерско-архаичными инсрументами пользоваться не собираюсь.
Это уже было бы вредительство, поддерживать на плаву архаичные инстурменты разработки

Тобишь поддерживать на плаву надо только то, что модно, современно, молодежно?

Все же не понял, как вы разделяете полезную и бесполезную работу.
А потом программист «случайно» не замечает, что его творение не виснет только на Core i7 Extreme.
Я бы вообще запретил вести разработку на чём-либо мощнее самой распространённой конфигурации железа на данный момент минус 5 лет. Потому что продуктивность работы пользователя программы ещё более важна, чем продуктивность программиста.

Возможно, тогда современный веб был бы действительно удобным, а не специальной олимпиадой «кто быстрее сожрёт батарею ноута говённым джаваскриптом с 3 фреймворками и HD видео на фоне»
Возможно, тогда бы С++ неприлично долго компилирующиеся и неадекватно переусложнённые языки начали бы терять свою популярность.
Возможно, тогда мы бы не возвращались стремительно во времена DOS, когда люди работали одновременно только с одной программой (тогда — потому что не было многозадачности, сейчас — потому что тормозит — некоторые программисты же верят в закон Мура и в то, что у пользователей денег куры не клюют на покупку мощного железа)
Бред. Требования к ресурсам инструментов разработки никак не связаны с требованиями к ресурсам итогового продукта, не притягивайте за уши доводы. Я видел хипстеро подбных персонажей пишущих код в модных/архаичных редакторах, как правило у них даже не было привычки форматировать свой код по единому стандарту, они просто не понимают зачем это нужно, полагаю потому что не привыкли работать в команде. Я бы еще понял когда какие-то совсем автономные скрипты (не предполагающие сайд эффектов) пишешь в блокноте, но ведь есть любители писать в блокнотах на компилируемых языках. Работа в блокноте для меня явный признак непрофессионализма, подтверждено опытом. Для меня очевидно что любители всяких блокнотов это как правило одиночки, которые не привыкли работать над большими проектами и в больших командах.
Может быть, моя гипотеза ложная. Только объясни тогда, отчего народ свихнулся? Обычный редактор с подсветкой синтаксиса сейчас нормально делать на Electron (их уже два — Atom и VS Code). Там даже кастомных GUI контролов нет, на кой чёрт там HTML+CSS+JS? Это можно было даже на Tk сделать! Только тему красивую нарисовать и всё.
И ведь тормозит нещадно.
Так хипстерня ведь, чего здесь объяснять. Сверлит им где-то что-то сделать не как у всех, отхватить звездочек на гитхабе. Даже если поделка это кактус в итоге все равно будут его кушать. Из той же серии как известные в интернетах люди постоянно нахваливают свое функциональное программирование, ладно бы пускай, но они утверждают что это серебрянная пуля. Не знаю зачем им это, видимо славы хотят.
Меня это очень беспокоит. Даже на хабре, когда я говорю, что разрабатывать десктопное ПО на JS — не комильфо, что у HTML+CSS+JS вообще куча недостатков, а для разработки под десктоп — ещё больше, что нужно разрабатывать GUI-библиотеки нового поколения для разных языков (или одну с биндингами), меня минусуют и поднимают на смех и упорно впихивают Node.JS
Я не большой любитель писать много логики на JS в целом и на Node в частности, но если это делать аккуратно (допустим используя TypeScript), то вполне думаю можно жить. HTML+CSS+JS это очень гибко в плане UI, портабельности. Ну и для веба сейчас пишет каждая собака, проще найти нужных специалистов.
Там даже кастомных GUI контролов нет, на кой чёрт там HTML+CSS+JS?

А вот это как раз большой плюс, полная свобода в интерфейсе. Плюс можно в теории иметь еиную кодовую базу для веб приложения и десктопного.
А на практике это всё заточено под один браузерный движок, который, кажется, подошёл к сингулярности — где лучшие программисты мира, работающие в богатейшей компании, не успевают закрывать дыры и баги. Он переусложнён и из него выжимают последние соки.
Всегда пишу новые модули в Vim в одном стиле форматирования, а у когллег (пишут код исключительно в MSVS редакторе) почему-то стиль форматирования отличается от того, который задокументирован в проекте от файла к файлу, от функции к функции.

Дело тут совсем не в инструменте, а в людях и их привычках.
Дело тут совсем не в инструменте, а в людях и их привычках.

Разумеется, но по своему опыту как раз те люди с кем я пересекался использующие редакторы почему-то работают как школьники, но не профессионалы.
Не могу ничего возразить, но у нас с Вами разный опыт.
у них даже не было привычки форматировать свой код по единому стандарт
Ну для вас, как пользователя IDE это никак не должно стать проблемой — в любой IDE есть кнопочка для форматирования кода по выбранному стандарту.
дело не кнопочке, а в том что по моему опыту любители блокнотов не понимают что это необходимо при работе в команде.
Я к тому, что как раз стиль форматирования кода в наше время — это наименьшая из проблем: вы можете настроить pre-commit hook, и код будет автоматически переформатирован в соответствии с выбранным в команде стилем, вы можете нажать волшебную комбинацию клавиш после открытия файла, и код будет переформатирован в соответствии с вашими ожиданиями, или даже повесить макрос на открытие/сохранение файла.
Вы все же не поняли, это был самый примитивный пример, первый попавшийся. Я не стану здесь описывать как эти ребята пишут код.
В IDE тоже можно писать так себе код. Снова повторюсь: дело в людях.
Снова повторюсь: на моем опыте люди использующие блокноты как правило работали не достаточно профессионально.
Так, может, просто не тех людей нанимали?
С моей точки зрения если человек пишет код в блокноте, но при этом код нормальный, читаемый и вовремя написаный, то все равно как его пишут.
Как правило это были внешние сотрудники, можно сказать контракторы. Если человек «свой», то ему довольно быстро дадут понять что проект серьзный и инструменты разработки нужно использовать соответствующие.
> быстро дадут понять что проект серьезный
…а не какой-нибудь там хипстерский github, да?
Мы используем github для работы, приватные репозитории.

В вашем профиле указано, что вы занимаетесь FPGA. Вы синтез запускаете на синтезированном MISP или всё-таки на мощном современном x86_64 с 16+ GiB RAM?

Это нельзя сравнивать. Во-первых в моём распоряжении вся FPGA целиком. Во-вторых, я делаю отладку на реальном железе. В-третьих то, что я делаю, как правило, либо работает, либо нет, потому что при разработке для FPGA ты рассчитываешь алгоритм с точностью до каждого такта (если только не используешь софтпроцессор и пишешь для него на Си) — там нельзя говорить о производительности в компьютерном смысле.

В компьютерах производительность — эффективное использование процессорного времени и памяти. В FPGA производительность — эффективное использование чётко предопределённого количества логических ячеек.
Так и для софта под x86_64 условия эксплуатации бывают разные. И требовать
Я бы вообще запретил вести разработку на чём-либо мощнее самой распространённой конфигурации железа на данный момент минус 5 лет.


такая же глупость, как и требовать разрабатывать, например, для mips на mips'е или для FPGA на FPGA. Вы кстати, разрабатываете на celeron из поколения core 2 с 2 GiB RAM?
Вы же прекрасно поняли о чём я. Даже когда я сам пишу программы (не для FPGA), я делаю отладку на той же машине, на которой пишу код и собираю его. Только это Pentium 3. Поэтому я знаю, что если оно не тормозит у меня, то не будет тормозить ни у кого, даже на тех тонких клиентах с Atom Nxxx, для которых мне частенько приходится делать программы с GUI, и на которых поделки на Qt QML, которые делал мой бывший коллега, выдают FPS около 1 кадра в секунду (нет аппаратного ускорения графики).
Поэтому я знаю, что если оно не тормозит у меня, то не будет тормозить ни у кого, даже на тех тонких клиентах с Atom Nxxx, для которых мне частенько приходится делать программы с GUI, и на которых поделки на Qt QML, которые делал мой бывший коллега, выдают FPS около 1 кадра в секунду (нет аппаратного ускорения графики).


Это пока пользователь не поставит какой-нибудь тяжёлый антивирус и софт не уйдёт в своп. И это не повод разрабатывать и отлаживать допотопными средствами на древней конфигурации. Это повод делать performance тесты на целевых машинах.

Как я уже сказал выше, целевые системы бывают разными. И отлаживать приложение, которое планируется использовать на сервере, на "самой распространённой конфигурации железа на данный момент минус 5 лет" — глупость.
Ах да, все вышеперечисленные машины под Linux, никаких антивирусов там нет.
для IDE — нужна достаточно мощная рабочая станция.

  1. как и для комфортной разработки ПО вообще
  2. «мощная» == «с как можно бо́льшим кол-вом RAM и как можно более быстрой долговременной памятью»

Кроме того, создателю плагина надо сосредоточиться только на том, чтобы хорошо сделать поддержку специфических для ЯП вещей, а всё остальное Vim уже умеет.


Неужели так можно было?
Объясняется это тем, что для редких вещей создавать IDE неоправданно, а написать базовый плагин для Vim не так сложно.


А что, если не создавать IDE с ноля, а написать плагин для существующей IDE?.. Да ну, глупости какие, никто так не делает.
Ваша конфигурация для VIM вообще без труда переносится с машины на машину. Будет ли так просто с вашей IDE?


да. Подумаешь, ракетная наука.
С Vim вам не понадобится мышь


Это же ведь только vim весь клавиатурно-ориентированный, откуда тупым разработчикам ненужных IDE знать, что программистам может быть удобно не пользоваться мышью. А 54 страницы действий, доступных для биндинга, плагины поддержки vi и emacs modes, поддержка биндинга на две последовательные комбинации клавиш для тех, кому не хватает всей клавиатуры (в IDEA, по крайней мере) — это… это агония, вот!
что касается языков программирования и разметки, то вам понадобится осваивать несколько IDE со своими особенностями


Всем известно, что обратной дороги из IDE нет: к пользователям IDE, дерзнувшим воспользоваться блокнотом, на дом выезжает наряд полиции IDE (два огнемётчика и собака; собака внимательно слушает ваши оправдания перед тем, как огнемётчики начнут вас запекать).
плагины поддержки vi modes

Брр… Не упоминайте, пожалуйста, об этих треугольно-колесных костылях.
как и для комфортной разработки ПО вообще
«мощная» == «с как можно бо́льшим кол-вом 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 преимуществом. А вы?
связка рабочая и комфортная, проверено на себе.


я не сомневаюсь. я к тому, что 24G RAM (нижняя планка комфортной работы (привет, Google Chrome!)) для рабочей станции стоят меньше, чем может показаться
Очень интересно будет увидеть плагины для IDE (хотя бы для подсветки синтаксиса, хрен бы с обработкой ошибок и прочим) для систем компьютерной алгебры GAP и Magma


скармливаем https://github.com/dhowden/Magma.tmbundle и https://github.com/dhowden/gap-tmbundle (Sage textmate bundle не гуглится) плагину https://plugins.jetbrains.com/plugin/7221. Я понимаю, что так нечестно и это не касается не-IDEA, но тем не менее.
Мой опыт работы в VIM и обощённых IDE говорит о том, что работа без мыши в VIM комфортнее


позвольте усомниться в добросовестности ваших стараний работать без мыши в обобщённых IDE
я думаю, что связано это моё удобство с тем, что VIM изначально затачивался на работу без мыши, а для IDE работа без мыши — некоторая отдельная фича


my words exactly
Ну и по мне, так сложнее запомнить 54 страницы горячих клавиш, чем запомнить ограниченное число действий VIM, которые повторяются в различных вариантах.


вы, главное, ни в коем случае не ходите посмотреть, как оно там на самом деле — есть неиллюзорный шанс, что ленивые еретики из JetBrains и это учли
Дальше вам нужен ещё один ЯП, и под него вам нужен третий инструмент.


по всей видимости, полиция IDE следит ещё и за тем, чтобы ни одна IDE не поддерживала больше одного, максимум двух ЯП

Вопрос не в цене. Вопрос в том, зачем что-то делать, если можно этого не делать? Конкретно работая в VIM я могу себе позволить не думать о железе 10 (прописью, десять) лет. Т.е. в течение 10-ти лет мой выбор VIM в качестве основного инструмента разработки позволяет забыть о такой проблеме, как вынужденное обновление рабочей станции (конкретно в моём случае, ноутбука). На мой взгляд, это преимущество. Им можно пользоваться или нет, но это другой вопрос. Или вы не согласны?


Насчёт JetBrains, я выше писал, что я ушёл с IDE, не попробовав продкты JetBrains (если не ошибаюсь, они стали по-настоящему популярны только в последние годы), поэтому, действительно, допускаю, что многое стало сильно лучше.


А по поводу полиции IDE, я не до конца вас понимаю, вы считаете, что существует IDE, которая поддерживает всевозможные ЯП? Или, что существуют две, которые в сумме покрывают весь спектр? Или хотя бы столько, сколько поддерживает VIM? Потому что, если это вдруг не так (моя ставка), то я подберу вам 3 ЯП, для которых надо будет 3 IDE.


Ну а вообще, судя по тому же JetBrains, то на каждый ЯП своя IDE.

Ну а вообще, судя по тому же JetBrains, то на каждый ЯП своя IDE.

Вы ошибаетесь, все JetBrains IDE это одна и та же IDE просто с плагинами для каждого языка (можно поставить и просто плагины в Idea). У неё одинаковые горячие клавиши, вид редакторов, почти одинаковые меню и т.д.

существует IDE, которая поддерживает всевозможные ЯП

Вообще все возможные или более-менее популярные? Вряд ли есть Vim плагин вообще для любого ЯП на Земле.

Скажем, JetBrains IDE официально поддерживает C#, C/C++, Groovy, Java, JavaScript, TypeScript, Kotlin, Objective-C,
PHP, Python, Ruby, Scala, SQL, Swift, DSL. Можно найти open-source плагины для go, erlang, rust, haskforce, elm, Perl5, Cypher, Dart, haxe, OGNL, Squirrel, Bash, Lua, Nim и много-много других (> 180 штук). На крайний случай, можно взять и сделать свой плагин, это относительно несложно.

Уверены, что в Vim'e больше плагинов и лучшего качества? Не стоит мериться плагинами. ИМХО, в Idea их тоже дофига.
DSL


Какой именно?

Поддержка rust'а в идее недавно была на уровне подсветки синтаксиса и запуска cargo. Если вдруг сегодня вышли новые версии rust и oxidize плагинов с поддержкой автодополнения (не в рамках одного файла) и go to definition — дайте знать. Вчера, когда сносил эти плагины, этого функционала ещё не было. В случае же vim, emacs, atom/vscode — оно есть через ycmd.
Какой именно?

Разной, см. офф сайт JB и страничку с плагинами: Anko DSL, Coocoo DSL, DSL Platform, Tara DSL и т.п…

плагинов с поддержкой автодополнения (не в рамках одного файла) и go to definition

Вы же понимаете, что так сравнивать можно бесконечно. Все ли из 180 ЯП из плагинов Idea реализованы в Vim (есть какой-нибудь К или Fantom ?), везде ли автодополнения Vim'a настолько же интеллектуально как в Idea (в частности Java, JavaScript, PHP)? Это уже вкусовщина, тем более что ни вы, ни я не сможем досконально сравнить сотни плагинов для Idea и Vim'а. Как минимум, кол-во плагинов популярных языков достаточно велико в обоих случаях.

Сходу гуглится для Fantom и K.


Насчёт качества автодополнения, в некоторых языках, к сожалению, VIM заметно проигрывает, это правда.

В некоторых случаях он и не может выигрывать, т. к. оперирует текстом программы, а не AST.

Разной, см. офф сайт JB и страничку с плагинами: Anko DSL, Coocoo DSL, DSL Platform, Tara DSL и т.п…


Это было намёком, что DSL приводить в списке general purpose языков несколько странно.

Другая же часть касалась того, что значительная часть плагинов поддержки языков для идеи — реализованы также или хуже чем в vim'е. И если не рассматривать поддержку массовых языков, фреймворков на них и библиотек сериализации (всякие avro, protobuf) — то эти ">180" плагинов в среднем просто пшик.

Поддержка немассовых языков хромает везде, но в моей практике в случае vim'а она оказывалась лучше в нём, нежели в идее.
Вероятнее всего потому, что база пользователей vim'а, способных реализовать такую поддержку банально больше.

P. S. разрабатываю в основном в идее и смежных продуктах (rubymine, pycharm).
«я выше писал, что я ушёл с IDE, не попробовав продкты JetBrains» — значит, вы не видели нормальных IDE! :)

До того, как JetBrains-овские IDE стали действительно мощными и удобными (ну и IdeaVIM не стал достаточно юзабельным, хыхы), я сам пользоватся vim-ом и считал, что IDE мне не нужны.
Автор а вы работаете в команде? Допустим да. Допустим команда на 10+ человек и бывают пополнения. Вы бы смогли убедить команду (и возможно начальство) что Vim решает? Допустим смогли, тогда вы бы взяли на себя дополнительную обязанность обучить всю команду и сделать работу команды более продуктивной чем в IDE (допустим что-то от IntelliJ)?
Хоспади, зачем убеждать команду и начальство переходить на Vim? Оо
Ну как же, автор ведь пишет
Но если у вас вдруг появилось немного времени на повышение вашей эффективности в целом, то попробую вас заинтересовать именно Vim'ом

Ну вот мне и интересно как предполагаемые члены команды автора восприняли его методы повышения эффективности. Я полагаю он уже убедил команду и решил идти дальше так сказать проповедовать.
Думаю автор говорит об интересе читателя к редактору, а не об убеждении читателем своих тиммейтов.
UFO landed and left these words here
Вообще, если смотреть внимательно на скриншот — человеку не только в команде не работает, он еще и делает проекты — самоделки с коротким жизненным циклом. Вобщем он сам себя проклял вечной поддержкой своих исодников в одиночку.
Парное программирование — шутите?

Черезмерное обилие коментариев и одно окно — укзаывает на простую вещь — тестов нет (т.е. идеология когда тесты как документация к системе). В той-же Java переход от кода к тесту выполняется в 1 шорткат (это при том, что тесты расположены в совсем другой части файловой системы).


К сожалению для вас, всю вашу спесь и желчь вы изливали не на того человека. Быть может даже автор того, что на снимке экрана, вовсе не пишет в VIM (хотя что это я?! Конечно же пишет — он автор vim-go).

Возможно, вы редко встречаетесь с Open Source, но в этом мире принято документировать свои "самоделки", особенно, если это библиотека, предназначенная для использования сообществом. Конкретно на скриншоте — главный файл библиотеки color.go, у которой 932 звезды и 74 форка на гитхабе, много ли ваших проектов в той же степени заинтересовали сообщество?

По остальным претензиям к этому снимку экрана, замечу, что "короткий жизненный цикл" на данный момент превышает 2.5 года, на протяжении которых совершаются регулярные коммиты, а поддержку исходников автору помогают осуществлять ещё 11 программистов, согласно статистике репозитория. Тесты, конечно же, есть.

Этот чужой снимок экрана я привёл потому, что на нём: автодополнение с учётом семантики, структура файла и докментация к слову под курсором.

По всему остальному вашему комментарию: удобные коммиты есть, рефракторинг есть, автодополнение и, следовательно, длинные имена переменных есть.
UFO landed and left these words here
UFO landed and left these words here
Обычно в команде важно, чтобы подойдя к соседу, сев за его компьютер ты мог исправить что-то в программе.
Для того, чтобы это работало — нужно чтобы у всех была одинаковая IDE & клавиатура и трекпад.

Ни разу за 20+ лет с таким не встречался. Обычно правило — стандарта нет, каждый пользуется тем, что ему больше нравится.
UFO landed and left these words here
Ужас какой. Тем более, что под стандартной ОС обычно понимается Windows — лично я в ней вообще эффективно работать не могу, я привык к юникс-системам.

Надеюсь, в одинаковой одежде всем ходить и корпоративные гимны по утрам петь не надо?
UFO landed and left these words here
Почему сложный? Вовсе нет, начиная с $10k/m я бы крепко задумался и на многое согласился, а за $20k/m я бы и гимны попел. Через годик бы уволился, конечно.
UFO landed and left these words here
UFO landed and left these words here
Выбираеш — пишеш — знаеш — умееш… брррр.
UFO landed and left these words here
> подойдя к соседу, сев за его компьютер ты мог исправить что-то в программе.

Больно бы ударил того, кто попробовал бы подойти и на моем компьютере что-то исправить.
UFO landed and left these words here
Словами можно помочь, а не тянуть свои руки к чужому имуществу :)
UFO landed and left these words here
> реально задолбаешся рассказывать как пользовться gdb, ldd и прочими страшными словами.

А зачем рассказывать про gdb и ldd, когда существуют удобные надстройки над ними в виде IDE?

> Намного проще человека галантно попросить поделиться клавиатурой и разобраться самому, что оно не так.

Увы, это не так. Да, можно быстро решить чужую проблему самому, но это нисколько не поможет джуну в дальнейшем решить аналогичную проблему из-за того, что вы лишаете его таким образом драгоценного опыта.

Ну а если специфика работы требует использования именно vim и gdb — придётся смириться с тем, что порог вхождения в них высок по сравнению с IDE, и нужно либо набирать разработчиков, умеющих с ними эффективно работать, либо потратить 2-3 месяца только на одно обучение и выработку автоматических навыков.
Проще? Ну, да, в случае с джуном проще вообще всю работу за него сделать.

Если уж взяли джуна, то надо «задалбываться», рассказывать и учить.

У вас какое-то очень странное представление о том, как в VIM работать с несколькими файлами, или с проектом с развитой структурой. VIM сам по себе достаточно удобен для работы со многими файлами. А с помощью плагинов он может ещё больше: от банального древовидного каталога и выбора файла с помощью чего-то типа NERDTree:


image


до совершенно бесподобных штук с нечетким поиском типа fzf или ctrl-p:


image


Во втором случае, открытие другого файла мгновенно, и никакая IDE без аналогичного функционала (или с любым "мышечным" способом открытия файлов) не сможет соревноваться с VIM в этом вопросе.


Ну это надо не забывать, ещё про такие штуки как go to definition и перескачка между файлом и соответствующим тестом, quickfix с ошибками или упавшими тестами (т.е. открытие нужного файла на позиции ошибки) и т.п. Всё это в VIM есть и очень удобно.

Про fzf и ctrl-p не знал, спасибо, пригодится — всякую мелочь по старой памяти я в виме редактирую; vimrc еще с тех пор остался, когда вимом пользовался активно (лет 7, наверное, ему), так что про новье не в курсе, там у меня основа — это NERDTree + MiniBufExplorer.

А «бесподобно» — это все же перебор. JetBrains-овские IDE умеют то же самое, причем и по файлам, и по именам классов-интерфейсов. Срабатывает все моментально. Мышку же я вообще не трогаю, зачем? Один раз пробил все хоткеи, как мне удобно, и отключил к чертям все тулбары с менюшками.
UFO landed and left these words here
и никакая IDE без аналогичного функционала (или с любым «мышечным» способом открытия файлов) не сможет соревноваться с VIM в этом вопросе.

Я правильно понимаю, что вы что-то типа такого имеете в виду?
image
Уже пару лет пытаюсь перейти с вима на IDE, влекомый растущей сложностью кода и безобразной (ну действительно же безобразной, по сравнению с тем, что есть в нормальных IDE) работой умных плагинов (типа jedi). Останавливают две вещи — 1) отсутствие нормального редактора во всех IDE (вим-моды — это курам на смех) и 2) невозможность нормальной работы на удаленном сервере.
Зачем вам программировать на удаленном сервере? Настройте себе толковый деплой и радуйтесь.
Да я как-то привык писать маленькими частями, в стиле написал — проверил в соседней консоли. На деплой в таком случае уходит слишком много времени
Может unit-тесты или локальная сборка решат проблему?
Решат, если начать писать тесты, хаха :)
На самом деле основное для меня — это именно редактор. По сравнению с вимом штатные все-таки совершенно беспомощны
Золотые слова! По какой-то непонятной причине защитника вима не делают на редакторе акцент, а это пожалуй основное и единственное. IDE это добро, но оно было бы ещё добрее, если бы там текст можно было нормально редактировать. Я работаю в Intellij Idea с установленным плагином IdeaVim. Вроде неплохо получается, хоть редактор до вима и недотягивает.
UFO landed and left these words here
Как вариант: в PHPStorm можно настроить автоматическую загрузку изменённого файла по ssh на нужный сервер
Это очень хорошо работает пока для доступа на удаленный сервер не используется авторизационный токен, который успевает протухнуть пока настраивается подключение.

В посте я приводил возможные причины:


  • физическая привязка к оборудованию удалённого сервера (например, GPU)
  • удалённый сервер мощнее и там комфортнее работать
  • на удалённом сервере всегда открытая рабочая сессия, доступная со всех устройств.
В IDE разве нет возможности подключать удаленные/виртуальные каталоги (через ftp / sftp)? Eclipse вроде как уже очень давно это умеет из коробки ну и плагины никто не отменял если у вас запросы специфичные.
UFO landed and left these words here
Чем вам вим-моды не угодили, можете привести пару примеров чтобы прям «курам на смех»? Во всех IDE которыми я пользовался VS (VsVim), Netbeans (jVi), Idea (ideavim) основной функционал навигации / редактирования имхо удовлетворителен.
Дьявол, как водится, в деталях — где-то нет макросов, где-то каких-нибудь движений, где-то нету калькулятора в режиме вставки и  С-a/C-x — короче, всех этих штучек, за которые мы и любим вим.

Калькулятор в режиме вставки — это что конкретно вы имеете ввиду?

сел гуглить про калкулятор и про инкримент…

Спасибо добрый человек. 10 лет вим знаю, а этим ни разу не пользовался…
В ideavim навигация в стиле вима не работает при выборе метода из контекстной подсказки. И по результатам поиска так перемещаться не получается. И так далее.
Да всё просто, мне не нужен громоздкий швейцарский нож, который трудно держать в руке (а руки у меня небольшие). Мне нужна катана, которую я сам заточил… Да я не смогу ею открутить шуруп или вырезать снежинку из картона зато рубит она идеально.
пример из мой практике, возможно глупый
после переходу на vim мне не хватало автодополнений. Искать плагин времени не было как и разбираться как заточить vim под php. Пришлось просто вспомнить. Как оказалось, я очень много функций знаю наизусть, как впрочем и css правил. Но это я чисто про себя. Понятно что не всем это подходит.
Сколько VIM не изучай, а он все равно бибикает и портит. Имхо, таких агитирующих статей было уже много. И я даже верю, что эффективность растет. Но сам не достиг. Сколько еще упорства нужно вложить? Наверное, одно простое видео с демонстрацией киллер-фич будет эффективнее десятка статей. Запишет кто?
UFO landed and left these words here

Да… В комментариях начался какой-то абсолютно идиотский спора: Vim vs IDE. Вообще не понимаю зачем так ставить вопрос, и IDE и Vim — это иснтрументы, а как известно, каждой задаче свой инструмент. Где-то IDE так же необходима, как воздух, а где-то в ней нет особой необходимости и там уже каждый сам решает что для него продуктивная работа — супербыстрная и мегавыразительная работа с текстом, либо же рефаторинги и code autocomplete. И! Что самое важное, абсолютно нормально, если вы сейчас пишите на Java в Idea, а через пять минут открываете Vim и пишите на том же JS. Нужно учиться работать эффективно, это да, но нельзя искать "серебряную пулю", которая решит все ваши проблемы

Как автор вопрос поставил такие и комментарии. JS писать в редакторе глупо, если конечно код не уровня скопипастить что-то со стекоферфлоу, добавить google analytics на страницу и тд. Я тоже пользуюсь реакторами, но для редактирования текста, не кода.

А как я поставил вопрос? С моей точки зрения я написал, что-то типа такого: "у VIM есть ряд преимуществ перед IDE, если вас какое-то из них заинтересовало — попробуйте VIM". А что вы увидели?

Каждой задаче свой инструмент? Вы дискуссию то вообще читали? Тут весь спор в том, что противоположные стороны считают Vim и IDE лучшими инструментами для решения одной и той же задачи.
Мои пять копеек.

Сделал три попытки пересесть на VIM. Первая была просто из любопытства, закончилась примерно через 15 минут. Вторая была из-за советов уважаемых мною знакомых. Снова закончилась по причине того, что под рукой был привычный Sublime а работа подгоняла. Третья попытка совпала с моментом покупки нового ноубука, я изначально поставил на него только tmux и vim. Затем шла неделя матов и непрерывного гугления чего-то типа «Как перейти в конец строки», «Как вырезать текст между ковычками» и тд. Затем неделя на написание своего небольшого vimrc и парой самых распростроненных плагинов. Прошел год и я очень доволен. Особенно чуввствуется отказ от мыши в дороге. Раньше при ее отсутствии моя производительность изза плохого тачпада падала прилично, а теперь красота. Vimrc тем временем разросся, появилось множество удобных вещей от обычного lint'a и до всяких кастомных спиппетов. Плагин Vim Hard Time помог отказаться от кликанья по стрелкам. Ну и, как уже говорили выше, связка tmux+vim дает возможность поддерживать одну сессию на работе, дома и вообще на любой машине.
А сохранение vimrc где-нибудь в своем репозитории делает возможным сделать restore всех настроек локально где угодно.

Возможно я пропустил, никто не упомянул такое преимущество IDE как подсветка ошибок, т. е. встроенный статический анализ. Есть такое для Vim?

Разумеется. Для питона, например, есть плагин Python-Mode. Там хренова туча всего, я, правда, пользуюсь только pylint и раньше пользовался подсветкой ошибок PEP8.
UFO landed and left these words here
идея и ее производные — это по сути те же команды в консольке, наткоторые навешаны кнопочки и автоматизация

Не знаю насчёт идеи с джавой, но в пхп точно нет многих команд в консольке, которые есть в пхпшторм.
Пользуюсь и Vim и Pycharm. Несколько лет пользовался только Vim, и для правки конфигов и для написания кода. Vimrc оброс плагинами, был и eclim и прочее. Так продолжалось 3-4 года. Я был истинным апологетом вима, всем рекомендовал вим, восхвалял его, вступал в дискуссии. Потом я попробовал PyCharm, где я сразу же установил IdeaVim, с тех пор не мыслю промышленное программирование без него. Vim — отличный редактор, прекрасный редактор текста: режимы, навигация, hjkl — очень удобно. Но PyCharm дает больше за меньшее усилие. Умный автокомплит, интеграцию с фреймворками (django, flask), встроенные утилиты и помощники — генерация UML, интерфейсы для модульного тестирования, множество удобных инструментов для систем контроля версий и хабов репозиториев, количество полезных плагинов доступны и легко устанавливаются, рефакторинг гораздо умнее всего, что я пробовал под python для vim (rope, eclim), проект выглядит как одно целое — а не просто директория с файлами, профилирование, полноценный дебаг, удаленный интерпретатор и, как следствие, удаленный дебаг (например внутри vagrant), тут и инструменты для деплоя, докер. Ну и, конечно же, какое редактирование кода без удобного редактора? Пожалуйста — IdeaVim, который ставит окончательную точку с выбором среды разработки. Vim — это для быстрой правки файлов, конфигов, особенно удаленно. Vim — хороший продукт, но, имхо к программированию его стали адаптировать, потому что не было достойных IDE, и людям хотелось vim-like workflow. Сейчас это не так, сейчас вим никогда не догонит профессиональную IDE, если такая IDE конечно есть (а есть она не для всех ЯП).
Люди, а вы не учитываете, что в современном мире ещё существуют разработчики на C++?

Для написания кода на JS, CSS, PHP, правки SQL и т.д. я использую Sublime Text, мне его возможностей хватает за глаза.
Но для проектов на C++ — IDE и только IDE.

Для разработки на C++ сама по себе нужна мощная рабочая станция (скорость компиляции крайне важна), поэтому использование мощной IDE не является проблемой. VS загружается с нуля и открывает проект за 5 секунд, после чего совсем не тормозит. Зачем мне нужно что-то ещё?

Для переноса настроек существует вполне удобный иструмент импорта/экспорта настроек.

А отлаживаться непосредственно на сервере — мне это кажется немного странным.
А как VS или что там для плюсов есть под linux запустить на удаленном серваке в консоле? Я до этого работал довольно долго с С++, у нас было около 2М строк кода в проекте. Все прекрасно в виме всё редактировали. На обычном компе это былоб нереалько компилить, тесты бы наверное часами бы гонялись с поднятием докеров и тд. Да и дебагер бы я подозреваю постоянно свопился бы(там нужно было сильно много памяти). да и ставить весьма экзотичные дистрибутивы на рабочую станцию тоже не особо как то. Можно конечно в виртуальку, но как то это то еще удовольствие. Можно, наверное, настроить монтирование по sshfs и удаленную комплияцию, но это тоже то еще занятие. IDE однозначно удобнее, но в таких ситуациях vim и gdb есть везде, на любом разработческом/продакшн серваке.
Как правило на удаленном серваке что-то дебагают, потому что там такое окружение где баг воспроизводится, есть все нужные данные, с сетью все нормально(в том плане, что на локальной машине может быть другая подсеть, порты закрыты или еще что-нить). Ну или даже если можно подебагать локально, зачастую нужно притащить данных с десяток гигабайт, наверняка пробросить пару портов, возможно еще что-нить подчудить с DNS-ом.
На локальной машине может быть другое ядро, по-другому настроно, с другим переключением процессов, в общем дофига нюансов.
И вот снова приходим к тому, что невозможно учесть все нюансы. Продолжаем: существуют разработчики на C++, которые не занимаются разработкой серверного кода и веб-приложений, да вообще не занимаются разработкой сетевых приложений. То есть не имеет значения, в какой среде разрабатывается и запускается код.

Наверное, я не очень себе представляют процесс индустриального сетевого программирования, но что-то мне подсказывает, что если разработчики вынуждены править код непосредственно на сервере (откуда и вылезает привязка к окружению), то процесс организован как-то неправильно.
А зачем еще тогда на С++ писать? Может разве, что игры. Формочки рисовать? тогда можно и на питоне/перле/bash это делать. Если писать на С++, то для этого должно быть строгое обоснование, там требования по памяти жеские и/или по скорости.
Возможно можно какую то либу напистаь в отрыве(какое-нить хитроумное дерево, например), но если, например, эта либа завязана на epoll/sendfile или еще какую-нить системной хедер, а у меня Mac OS X на лэптопе, то опять же приходим к тому, что удобнее на целевой платформе это делать. А переключаться с окна virtualbox-а с IDE на браузер и назад как то не очень удобно, хотя возможно это самое оно и есть.
Я, например, занимаюсь обработкой изображений — мне критично и время, и память. Поэтому язык — C++ для вычислительной части, C# для интерфейса. Питон и Матлаб — прототипирование. Насколько удобно и эффективно обрабатывать изображения на перле, JS и баше, наверное, объяснять не нужно?

Необходимость запуска кода на сервере может возникнуть только если нужно просчитать большой объём данных.
Да, для вычислительной части, соглашусь тут нужно, как и для всяких алгоритмический/криптографических библиотек, и они часто могут быть разработаны на локальной машине. Но большинство С++ кода, с которым я сталкивался было кардинально не таким.
Сейчас можно встретить мобильные приложения, у которых ядро на С++ и UI на Java, Objective-C, Swift, C#. Почему-то вы думаете, что мир крутится вокруг вас и ваших задач.
Я как раз таки привел пример, когда приходится использовать vim/emacs для С++ и IDE для такого рода задач как то сильно накладно использовать. Чтоб разбавить изначальное утверждение «C++ — IDE и только IDE.».
Эээ… ядро пишет команда, которой всё равно, где это будет запускаться. Билд под платформы — на сервере. И пишут таки в IDE, по тем самым причинам, которые названы выше.
Да ядро может легко зависеть от специфичных системных вызовов и хедеров или линковаться с какой-нить либой, которой нет на десктопе, там могут быть ассемблерные вставки еще что-то очень специфичное. Отделять такие вещи и городить кучу уровней абстракций тоже не особо нужно. Делать код портабельным это как то странно, тк он никогда не будет работать ни на чем отличным от платформы сервера.
Всё правильно, но причинно-следственная связь здесь нарушена. В вашем случае выбор среды разработки обусловлен не удобством для разработчика, а требованиями проекта. Аналогичного эффекта можно добиться, заставив программировать на компьютере 10-летней давности с одним небольшим монитором и запретив использовать собственный комьютер для работы.
Суть в том, что эта идеология настолько заразна, что хочется перенести её с редактора на все сферы общения с компьютером: браузер, pdf-просмоторщик, почтовый клиент, музыкальный проигрыватель, файловый менеджер и многое другое.


Я именно поэтому отрёкся от vim (а равно и Emacs): приходится к каждой программе искать/подбирать плагины и настройки, чтобы сделать из неё что-то vim-подобное. А плагины, как правило, не работают настолько хорошо, чтобы не приходилось страдать. В конце-концов я решил, что проще перейти в лагерь vim-ненавистников: да, это не так удобно, зато можно просто пользоваться хоткеями и другими возможностями программ, которые в них заложил разработчик, а не пытаться этого разработчика перехитрить. В итоге, Geany — моё всё.
echo lalala >> filename уже отменили, что ли? Как дети малые, ей богу.
Лучшая среда для C++ это студия (для linux — QtCreator), лучшая среда для python — PyCharm. Но, если постоянно работаешь с несколькими языками (в моем случай c/c++ и python ежедневно, редко — java, еще реже javascript, плюс ежедневно переключаться linux/windows) разные IDE, с разными настройками, разным поведением — начинается кошмар.
Vim/Emacs позволяет добиться использования одного универсального инструмента для всего. Пусть даже и с какими то ограничениями/недостатками
Но, если постоянно работаешь с несколькими языками (в моем случай c/c++ и python ежедневно, редко — java, еще реже javascript, плюс ежедневно переключаться linux/windows) разные IDE, с разными настройками, разным поведением — начинается кошмар

c/c++ — CLion
python — PyCharm
java — IntelliJ IDEA
javascript — WebStorm

По сути все это линейка Idea адаптированная для разных языков с одинаковым поведением, то есть практически одна и та же IDE.

плюс ежедневно переключаться linux/windows


Вообще не проблема, Idea кросплатформенная.