Как стать автором
Обновить

Комментарии 80

В свое время тоже мучился от тормознутости IDE. Но вместо настройки и поиска плагинов для текстового редактора потратил 100$ на память. А позже и на новый ноут. Мне кажется, что если вы способны справиться с vim, то подобные затраты для вас не должны быть проблемой. Хотя с другой стороны, подозреваю, что все это доставило вам немало удовольствия.
Не забывайте еще, что vim-ом удобно пользоваться удаленно, даже на тощем канале и он есть практически на любой *nix-машине, и тогда достаточно только вытащить на неё свой конфиг (я еще беру питоновский файл, который вытаскивает все нужные плагины), и уже работаешь в удобном и комфортном окружении.
А резве кто-то занимается разработкой удаленно на сервере? Да еще и на медленном канале?
Если уже очень надо, то в IDE есть выгрузка изменений на сервер. И даже удаленная отладка.

Мы все правки вносим через git. Если очень надо что-то попробовать на тестовом сервере, то у меня всегда подмонтирована его веб-директория и есть gedit. В крайнем случае ssh + nano либо mc.
И да, на наших серверах нет vim ;)
Кроме разработки, есть еще куча разных операций, которые приходится делать удаленно, это раз.

Два — иногда приходится работать из не самых удачных точек, например я как-то работал из паба на Мальте :) Или из чайной в Китае.

IDE с выгрузкой на сервер — это лишние действия и потерянное время…

Гит вы вообще непонятно к чему приплели, или вы и при отладке на тестовом окружении все коммитите в общий гит? :)

А мне вот не надо этих крайних случаев с неудобными редакторами, у меня есть vim :)

Сочуствую тем кому приходится работать «на ваших серверах» :)
В статье сравнивается vim с IDE, значит речь о разработке. Или вы используете IDE для правки конфигов?

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

По поводу git — рабработка фич ведется в отдельных ветках, все правки можно коммитить, а перед слитием в девелоп объеденить их в один. Хотя на самом деле все делается локально, а на один из тестовых серверов выгружается только для тестов готового функционала. Выгрузка производиться из git-a. Правка чего либо прямо на сервере — крайний случай для которого годятся описанные мной варианты (и не требуют недель на изучение редактора).

На сколько я понимаю, vim хорош если вы ведете разработку прямо на сервере через медленный инет. Сочувствую.
Да, по большому счёту, если сравнивать с IDE, то в Vim нет возможности удобно подключить отладчик и нет действительно умного и качественного автодополнения для динамических языков. Первое не так актуально, как кажется (можно запускать отладчик в отдельном окне, да и вообще лично я необходимость запустить отладчик чувствую примерно один раз в год — в остальных сложных случаях я нахожу баг print-ами за пару минут), второе неплохо компенсируется простым автодополнением по тем словам которые уже встречались в текущем файле или всём проекте.

Но главное в Vim вовсе не то, есть проверка синтаксиса и быстрый переход на определение функции или нет! В соседнем топике любители IDE издевались над фразами вроде «3 месяца настраивал Vim», рассказывая как у них на настройку IDE уходит несколько минут… Но фишка в том, что Vim и Emacs можно настроить под себя. Да, на это может уйти куча времени, но редактор — это один из основных рабочих инструментов, и время потраченное на затачивание его под себя окупается сторицей.
Однажды на даче я нанял мастера, чтобы он построил забор. Когда приехал через неделю, обнаружил, что он напильником выпиливает себе молоток.
IDE порой тоже доставляет ряд неудобств. Как-то из-за обновления стороннего плагина у меня перестала запускаться IDE, переустановка не помогала. Целый день мне пришлось использовать vim, поскольку саппорт не мог сразу поставить диагноз и помочь решить проблему.

Вот например сейчас, я не могу переименовать файл, поскольку идет переиндексация проекта:

НЛО прилетело и опубликовало эту надпись здесь
У меня эта операция занимает не меньше 5-10 минут и происходит это регулярно!
И да, проблема в том, что проект монтируется, а не лежит локально (нет технической возможности).
Нет технической возможности держать исходники проекта локально? Это как?
Я бывал в ситуации, когда не было возможности исполнять код локально, проблема решалась авто-загрузкой файлов при изменении, на скорость индексации это не влияло, само-собой.
Исходники лежат на удаленной машине, потому что их файловая структура и зависимости завязаны на окружение конкретной машины.
Проект монтируется по smb или sshfs. Подключить другим способом пока не удалось, поскольку мы используем сессионный токен.
Кажется, если можно монтировать по sshfs, то и просто по ssh доступ должен быть, или я ошибаюсь?
Доступ по ssh конечно есть, но проект приходится монтировать, из-за этого скорость индексации сильно снижается.
Вот, можно же не монтировать, а скачать исходники на локальную машину и настроить в IDE подключение по ssh, чтобы она сама измененные файлы закачивала на сервер.
Мы пробовали, ничего не вышло. :D
Если мне не изменяет память, регулярно пропадал коннект и требовалось заново ввести сессионный ключ в настройках. В общем еще больше мучений.
Понятно, странно.
Кажется, что работа с удалённым хранилищем это действительно тот случай, когда лучше пользоваться редакторами, а не IDE, и это отнюдь не камень в сторону IDE. Это просто не область его применения.
Наверное, все зависит от личного опыта. У меня не было проблем с IDE в такой же ситуации, поэтому другое мнение про область применения.
Вас обманули, это оказался не мастер!
Однажды на даче я нанял мастера, чтобы он устранил утечки тепла, тк дом быстро промерзал.

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

Когда приехал через неделю, мастер попросил купить новую дачу, так как в этой было мало места и ему было не удобно работать.
Ну так ведь создание собственной модели тепловизора для обнаружения утечек дело не простое и долгое. Надо же как-то греться все это время ;)
Я думаю Cheater намекает вот на это:
немного ностальгии

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

Было:
std::string string (const std::string &string) {
    return string;
}

string("test");


Стало:

std::string text (const std::string &value) {
    return value;
}

text("test");
Зависит от языка. Например, для Go такое работает (плагин vim-go, команда :GoRename). А для динамических языков — да, только ручками и внимательно, делать массовый search&replace стрёмно. Но наличие автоматической проверки синтаксиса и юнит-тестов обычно делает эту задачу не такой сложной.
А я собственно не являюсь сторонником ни IDE, ни редакторов.
Глупо даже обсуждать, что лучше использовать. Если у меня не работает IDE я открываю Vim.
Мои предпочтения зависят от ситуации.
Первое время, когда начинал работать с рельсами, то использовал RubyMine, но потом «старшие парни» показали Vim. Я потратил много времени на его настройку под себя, но сейчас не могу перейти на какую-то IDE, я просто влюбился в него. Очень приятно, что при работе с рельсами даже консоль не обязательно открывать. Почти все фичи можно прикрутить к нему. Сейчас даже на хабре перемещаюсь используя навигационные кнопки Vim'а.
И второе, vim — это не IDE и делать из него IDE не стоит.

Почему вы так считаете?
Идеологически IDE — Integrated Development Environment, то есть «всё включено», а vim эффективен вместе с другими *nix-инструментами и интегрировать их в него особо нет смысла, т.к. они уже под рукой.
vim эффективен вместе с другими *nix-инструментами

То есть Vim для Windows вы хороните сразу? )) А как же горячие клавиши для работы с этими инструментами?
Идеологически IDE — Integrated Development Environment, то есть «всё включено»

Таки IDE это еще и синтаксический анализатор, который встроен в редактор.
В WinNT-системы портирован bash и большая часть(если не все) core-utils, однако лично мне в windows не удобно и я им не пользуюсь, т.к. пишу ПО только под *nix-системы.
А горячие клавиши для работы с инструментами это лишь один из вариантов использования, другой это команды.

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

Ну редачить файл тоже можно командами, только это дольше.
Ну редачить файл тоже можно командами, только это дольше.

Дольше, если делать это не в vim.
А как Vim ускоряет набор команд?
А как Vim ускоряет набор команд?

Имею в виду командный режим(normal mode)
Тогда возвращаюсь к вашему коменту:
А горячие клавиши для работы с инструментами это лишь один из вариантов использования, другой это команды

и говорю, что для нормального использования сторонних *nix-утилит нужно настраивать эти самые команды (которые есть горячие клавиши). Так что без интегрирования некоторых утилит прямо в Vim (через горячие клавиши, плагины и т.д.), использовать его становится не так удобно.
Команды <> горячие клавиши.
А утилиты можно вызывать из оболочки, т.е. никакой интеграции производить не надо.
Команды <> горячие клавиши.

Почему же?
А утилиты можно вызывать из оболочки, т.е. никакой интеграции производить не надо.

Вы про: :!command?
Команды <> горячие клавиши.


Почему же?

Потому что команды можно выстривать в различные комбинации и сочетания и их удобнее вводить.

Вы про: :!command?

Да, как вариант. Но я обычно использую screen.
Потому что команды можно выстривать в различные комбинации и сочетания и их удобнее вводить

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

Мне не очень удобно ими пользоваться. Но каждому свое, как известно.
Vim хорош прежде всего идеологией своих клавиатурных комбинаций. Какие бы там проблемы с высокоуровневыми средствами в нём ни были, переход на vim keybindings в любом редакторе/IDE — это огромный прирост скорости. У меня у самого основное средство — это emacs со включенным режимом эмуляции vim («Evil mode»).
Я emacs'ом не пользовался, но само наличие «Evil mode» мне всегда казалось странным. Зачем нужно эмулировать Vim?
Чтобы оставаться на своей среде разработки со всеми её фичами и при этом редактировать чистый текст со скоростью Vim.
Т.е. emacs не слишком удобен при наборе текста?
У emacs набор текста аналогичен современным текстовым редакторам (сочетания основанные на Ctrl+ и Alt+)
Это многое объясняет. Я лично Vim пользуюсь на постоянной основе.
Я долгое время брезговал IDE, а какое-то время мне хватало gedit и far'а в windows. Собственно gedit'а хватало бы и дальше если бы однажды не встала задача отредактировать текстовый документ весом 10 мегабайт. Для решения задачи я нашел себе SublimeText. Потом долгое время использовал SublimeText (обожаю его множественные курсоры).

Потом я перешел на Мак и первым делом решил отказаться от проприетарного SublimeText'а, тогда я считал, что не по христиански это платить $60 за текстовый редактор. И встал вопрос что использовать: на мак есть разные редакторы, но все они не могли дать привычную функциональность, которая была в gedit. Я даже пытался gedit поставить на мак, но это не элегантное решение. Потом решил, что мне нужен редактор, который будет на любой системе и который даст мне необходимую функциональность.

Выбор тут был не очень богатый: Vim OR Emacs. Я их и до этого смотрел, но они всегда казались какими-то неповоротливыми и уж слишком сложными для текстовых редакторов. Тут решил, что буду воевать до последнего пока не овладею по нормальному. Начал с Emacs, настраивал и изучал его пару дней и уже под конец решил сделать любимую функцию множественных курсоров (как в SublimeText) и прочитал, что архитектурно это сделать в Emacs нельзя, потому что он не поддерживает множество курсоров, а вот на Vim всё это делается.

Перешел на Vim и 2 года пользовался исключительно им. Он шустрый, расширяемый, открывает большие файлы. Но! Командный интерфейс Vim это 30-летний выкидыш пользовательских интерфейсов. Это кошмарный пережиток прошлого. И когда приходится писать текст на русском, Vim, в этом случае, постоянно заставляет переключать раскладку, что в итоге я опять вернулся на SublimeText. Ну и за это время я конечно осознал, что для крупных проектов нужно использовать среды разработки и, на мой взгляд, это среды от JetBrains.
И когда приходится писать текст на русском, Vim, в этом случае, постоянно заставляет переключать раскладку

Таки вроде переключение раскладки придумано для переключения раскладки?
Неудобно переключать раскладку для ввода команд Vim'а. Ну и режимы ввода Vim'а тоже бесят — ещё один пережиток прошлого.
В Vim есть встроенный механизм (lmap), позволяющий автоматически переходить на нужную раскладку при переключении режимов (почитать о нем можно тут habrahabr.ru/post/98393). Удобная штука. Я от нее отказался, так как не смог настроить переключение раскладки на CapsLock (видите ли сигнал этой клавиши не обрабатывается Vim'ом).
Ну и режимы ввода Vim'а тоже бесят — ещё один пережиток прошлого

А вы точно пользовались Vim?
Я настраивал lmap в Vim'e (настраивал 3 года назад, а не использую его уже год, поэтому сейчас не вспомню; а конфигов под рукой нет). И там были какие-то свои проблемы, но я уже не помню, к сожалению.

Ну это был MacVim.
И там были какие-то свои проблемы, но я уже не помню, к сожалению

Я его настроил себе и проблем не было (кроме описаных выше). Вполне удобный инструмент.
Ну это был MacVim

Странно что вы считаете режимы ввода Vim'а пережитком прошлого )
В emacs есть плагин для поддержки нескольких курсоров, так и называется — multiple-cursors.

Его ещё демонстрировали в Emacs Rocks: http://emacsrocks.com/e13.html.

Но он, к сожалению, не без глюков, сам щупал, в том же sublime text эта фича значительно более стабильна.
В Scintilla тоже наконец-то добавили множественные курсоры, работающие подобно таковым в Sublime Text, т.е. теперь их можно перемещать стрелками: sourceforge.net/p/scintilla/feature-requests/1085

Это очень здорово. Скоро во многих редакторах… :)
Почитав все это решил еще раз попробовать подружиться с vim. Прикольно, конечно, но все же моей любимой командой в нем остается :q!
Почитав все это решил еще раз попробовать подружиться с vim

А зачем? Если вам нравится используемый вами редактор/IDE, пользуйтесь им и не обращайте внимание на других.
А зачем? Если вам нравится используемый вами редактор/IDE, пользуйтесь им и не обращайте внимания на других.
Не соглашусь с этим утверждением. Всему нужно дать шанс. Может понравиться, а может и нет. Я бы основывался именно на этом.
Давать шанс нужно тогда, когда используемое средство начинает чем то не устраивать.
Ну, моя точка зрения связана с любопытством («А вдруг не зря говорят что это лучшее, что есть?»).
К сожалению и к счастью программисты очень ленивый народ. Эта лень как двигает прогресс, так и тормозит его.
Как всегда, дело в правильном балансе.
Я админствовал 10+ лет. vi/vim знаю/умею.
Но когда потребовалось стать разрабом и писать сразу на: Perl, JavaScript, SQL, HTML, CSS = Sublime rocks!
unix way = нужно выбирать правильный инструмент под задачу
Я админствовал 10+ лет. vi/vim знаю/умею

А как это связано?
В vi/vim'e удобно править конфиги. Я примерно так же сделал, но у меня было vim -> TextMate (быстро наскучил) -> MacVim -> RubyMine -> vim сейчас на NeoVim перехожу.
У vim есть преимущество, попадая на любой новый сервер ты знаешь, что там есть vim и он будет работать так же как и везде. Причём у тебя есть ограничения: ssh + консоль.
Для разработки ПО — это преимущество не актуально, т.к. разработка ведётся обычно на 1-2 ПК где ты можешь настроить себе окружение. В vim для нормальной разработки требуется намного больше телодвижений, чем в заточеном для разработку редакторе/IDE.
Не нужно гвозди забивать микроскопом.
Ясно, спасибо.
Проверил, на наших серверах нет vim. Так что "почти на всех".
Учитывайте еще то, что на всех серверах версия этого самого Vim'а может отличаться, а на некоторых так вообще стоит какая нить другая реализация vi, так что аргумент типа — в любом месте, в любое время — не очень уместем (еще один аргумент в вашу копилку «Против Vim») ;)
Вим не настолько менялся, чтобы было невозможно пользоваться даже старыми версиями :) Посмотрел свой конфиг — даже для версий ниже 7 «отвалятся» только табы из удобных фич, остальное будет работать.

Могут отвалиться разлапистые плагины, требующие поддержки перла или питона, но их не так много, да и не всегда они нужны.
Частенько чту исходники различных популярных плагинов, и у всех имеются жесткие ограничения на версию Vim и его расширения. Так что не скажите )
Могут отвалиться разлапистые плагины, требующие поддержки перла или питона, но их не так много, да и не всегда они нужны.

Плагины не нужны? Без плагинов я прекрасно отредачу и с помощью какого нить ed.
Покажите где я написал что плагины не нужны? :)
Вим не настолько менялся, чтобы было невозможно пользоваться даже старыми версиями :)

Как же пользоваться старыми версиями без плагинов?
НЛО прилетело и опубликовало эту надпись здесь
Кстати, если используется плагин ack.vim, то для его использования с ag можно просто добавить настройку:

let g:ackprg = 'ag --nogroup --nocolor --column'
Иронично использую vim в cygwin. Рейт ми.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации