Как я встретил Vim
Я поклонник *nix-like систем и слышал, что в каждой такой системе по умолчанию всегда есть vi (хотя, бывает, что не всегда). И однажды мне нужно было написать программу на си для известного linux-дистрибутива, вопрос про использованию IDE не стоял — я просто открыл vi и частенько открывая шпаргалку начал писать код. Сразу замечу, что тогда пользовался vim как обычным редактором и не пользовался всей силой командного режима.
Время мелких программ прошло, теперь все по серьёзному
То было прекрасное время студенчества, теперь я инженер. Так сложилось, что технологический стек выбирать не приходилось и писать я стал на php. Всем прекрасно известно, что одной из лучших IDE для php является PHPStorm, хотя есть еще много других, в том числе и бесплатных. Однако все мои коллеги как один рекомендовали мне PHPStorm и я не стал пропускать мимо ушей советы более опытных разработчиков. Эта IDE действительно хороша, в ней есть все, что нужно web-разработчику, но была проблема: IDE очень медленно работала.
Скорость работы никуда не годилась. В моем распоряжении был ноутбук с intel core 2 duo (2 ядра по 2.4 Ghz, если я правильно помню) 3 GB RAM и HDD. Денег на новое железо нет, зарплата у junior'а не высокая и кредиты брать не хочется, да и вряд ли дадут.
Проект состоял из ~1,5 GB исходников, БД на Oracle и использовал некоторые специфичные библиотеки. А так же имел очень большие ресурсные файлы (XML), которые приходилось править руками.
PHPStorm ужасно лагал, он долго запускался, долго производил поиск, даже повисал когда я просто редактировал текст, больше XML он просто не мог открыть.
И снова Vim
Первое что стоит сказать о vim, что без написания конфига и дополнительных плагинов программировать в нем нормально нельзя. Но если все настроить, то жить можно. И второе, vim — это не IDE и делать из него IDE не стоит. Даже если прикрутить сотню плагинов, то он не будет таким же как PHPStorm или <твоя IDE могла быть здесь>.
Редактор для редактирования, но...
Но разработка — это не только редактирование кода, это анализ, рефакторинг, отладка, перемещение по файлам и прочее.
Итак, проблемы
Мне хотелось видеть файлы проекта в виде древовидной структуры
Эту проблему я решил плагином (NERDTree), в нем можно видеть дерево файлов, производить манипуляции над ними и прочее, но так же в vim есть и встроенный файловый менеджер.
Понимать, что я допустил синтаксическую ошибку в ходе редактирования
Статический анализ кода и отображение его результатов в редактор оказалось тоже простой задачей, так же решаемой плагином, причем для любого известного мне ЯП.
Иметь быстрый поиск файлов и иметь быстрый поиск по файлам
Для поиска по файлам я использую vimgrep или ack, может быть это не так эффективно, как в IDE, но даже в огромном проекте работают довольно шустро. Поиск самих файлов и их открытие на редактирование так же можно делать связкой команд find или grep + vim или прямо в vim через плагин (например, ctrlp).
Запускать отладчик из редактора
С отладчиком мне подружить vim так и не удалось. Вернее есть плагин для связи с xdebug, но пользоваться им не очень удобно, однако ценность этого инструмента у меня сводилась к минимуму, callstack и так посмотреть можно, а остальное дело техники. Сейчас я уже не пишу на php и в качестве отладчиков использую консольные инструменты (аналоги gdb) и их хватает.
Иметь инструмент инспекции кода
Инспекция кода вещь не такая нужная как может казаться, у меня есть плагин (tagbar), но я крайне редко его использую.
Перемещаться к определению метода или класса
Нормальное перемещение к определение работает только с си и его производными, для php, ruby, python и т.д. у меня не получилось настроить, но я очень быстро привык использовать ack и vimgrep.
Иметь автокомплит привязанный к проекту
Для автокомплита есть столько плагинов, что все не перепробуешь, но со временем я для себя решил, что это не такая полезная вещь. Тут стоит отметить, что для некоторых это очень важно, т.к. используются очень длинные названия методов, классов (привет, java) но при желании более менее адекватный автокомпит настроить можно.
Поддержка нескольких языков
Включение поддержки нового языка обычно решается подключением соответствующего плагина, к примеру, для golang достаточно подключить один плагин, который умеет все (от подсветки до статического анализа и автоформатирования).
Работа с очень большими файлами
Vim хорошо работает с большими файлами из коробки, но для гигантских файлов тоже есть плагин (LargeFile), при его использовании можно даже гигабайтные файлы открывать и ничего не зависнет.
Автоформатирование кода
Автоформатирование кода есть из коробки и оно автоматические подцепляет настройки из плагинов для разных языков.
Интеграция систем контроля версий
Я использую git и делаю я это в bash, но для кое-каких операций поставил пару плагинов (vim-fugitive, nerdtree-git-plugin).
Редактирование как оно есть
Самая важная особенность vim это режимы. Их много, но самый главный — это normal, или командный режим. После какого-то времени, пусть и продолжительного (2-3 месяца) я практически полностью редактирую код в командном режиме. Конечно, перехожу в режим вставки, когда надо что-то написать, но в остальном я использую команды. Это позволяет не отрывать руки от клавиатуры и через какое-то время ты перестаешь думать о том, как тебе редактировать код и полностью можешь сосредоточится на том, какие изменения требуется внести. Пожалуй, самый удачный пример — это рояль, когда ты научишься на нем играть, ты начинаешь думать только о музыке, а не о том, на какие клавиши жать. И я точно могу сказать, что горячие клавиши не дадут такой результат (очень долго пытался — не получилось).
Подводя итог
В тех условиях, в которых я работал, со слабым железом и огромным проектом, пользоваться IDE было мукой, но связка стандартных *nix-инструментов и vim позволила решать все задачи, которые вставали передо мной. Сейчас я так же работаю в vim, но уже из-за того, что не хочу переучиваться и менять привычную среду, которая себя хорошо показала. С течением времени я работаю все более и более эффективно, т.к. vim и *nix-системы — это вещи, которые можно изучать очень долго и постоянно находить новые методы решения тех или иных проблем.
И если вам не хочется использовать IDE или нет денег на крутую платную версию, я рекомендую вам попробовать поработать в редакторах, таких как vim и emacs. Если вы поймете их идеологию и она окажется вам близка, то вы не будете испытывать никаких проблем с работой над кодом.
Но надо сказать, что это все актуально для меня как для backend-разработчика, возможно, для разработки GUI-приложений или frontend, редактором ограничится не получится.
Комментарии (79)
powerman
26.08.2015 11:34+2Да, по большому счёту, если сравнивать с IDE, то в Vim нет возможности удобно подключить отладчик и нет действительно умного и качественного автодополнения для динамических языков. Первое не так актуально, как кажется (можно запускать отладчик в отдельном окне, да и вообще лично я необходимость запустить отладчик чувствую примерно один раз в год — в остальных сложных случаях я нахожу баг print-ами за пару минут), второе неплохо компенсируется простым автодополнением по тем словам которые уже встречались в текущем файле или всём проекте.
Но главное в Vim вовсе не то, есть проверка синтаксиса и быстрый переход на определение функции или нет! В соседнем топике любители IDE издевались над фразами вроде «3 месяца настраивал Vim», рассказывая как у них на настройку IDE уходит несколько минут… Но фишка в том, что Vim и Emacs можно настроить под себя. Да, на это может уйти куча времени, но редактор — это один из основных рабочих инструментов, и время потраченное на затачивание его под себя окупается сторицей.
marenkov
26.08.2015 11:48+9Однажды на даче я нанял мастера, чтобы он построил забор. Когда приехал через неделю, обнаружил, что он напильником выпиливает себе молоток.
monolithed
26.08.2015 12:18+3IDE порой тоже доставляет ряд неудобств. Как-то из-за обновления стороннего плагина у меня перестала запускаться IDE, переустановка не помогала. Целый день мне пришлось использовать vim, поскольку саппорт не мог сразу поставить диагноз и помочь решить проблему.
Вот например сейчас, я не могу переименовать файл, поскольку идет переиндексация проекта:
OnYourLips
26.08.2015 14:16+1Данная операция происходит примерно секунду при переключении ветки в проекте на ~100мб.
При первом запуске проекта и установке зависимостей, конечно, подольше, но данную операцию вы навряд ли будете делать чаще раза в месяц.monolithed
26.08.2015 14:43У меня эта операция занимает не меньше 5-10 минут и происходит это регулярно!
И да, проблема в том, что проект монтируется, а не лежит локально (нет технической возможности).asavin
26.08.2015 20:55+1Нет технической возможности держать исходники проекта локально? Это как?
Я бывал в ситуации, когда не было возможности исполнять код локально, проблема решалась авто-загрузкой файлов при изменении, на скорость индексации это не влияло, само-собой.monolithed
26.08.2015 22:58-1Исходники лежат на удаленной машине, потому что их файловая структура и зависимости завязаны на окружение конкретной машины.
Проект монтируется по smb или sshfs. Подключить другим способом пока не удалось, поскольку мы используем сессионный токен.asavin
26.08.2015 23:00+1Кажется, если можно монтировать по sshfs, то и просто по ssh доступ должен быть, или я ошибаюсь?
monolithed
26.08.2015 23:23-1Доступ по ssh конечно есть, но проект приходится монтировать, из-за этого скорость индексации сильно снижается.
asavin
26.08.2015 23:24+2Вот, можно же не монтировать, а скачать исходники на локальную машину и настроить в IDE подключение по ssh, чтобы она сама измененные файлы закачивала на сервер.
monolithed
26.08.2015 23:25-1Мы пробовали, ничего не вышло. :D
Если мне не изменяет память, регулярно пропадал коннект и требовалось заново ввести сессионный ключ в настройках. В общем еще больше мучений.asavin
26.08.2015 23:27+2Понятно, странно.
Houston
26.08.2015 23:46Кажется, что работа с удалённым хранилищем это действительно тот случай, когда лучше пользоваться редакторами, а не IDE, и это отнюдь не камень в сторону IDE. Это просто не область его применения.
asavin
27.08.2015 00:02Наверное, все зависит от личного опыта. У меня не было проблем с IDE в такой же ситуации, поэтому другое мнение про область применения.
Cheater
26.08.2015 12:56+7Однажды на даче я нанял мастера, чтобы он устранил утечки тепла, тк дом быстро промерзал.
Когда приехал через неделю, обнаружил, что он решил проблему установкой трёх дополнительных обогревателей.
Delphinum
26.08.2015 13:01+2Однажды на даче я нанял мастера, чтобы он заштукатурил мне стены.
Когда приехал через неделю, мастер попросил купить новую дачу, так как в этой было мало места и ему было не удобно работать.
marenkov
26.08.2015 13:34Ну так ведь создание собственной модели тепловизора для обнаружения утечек дело не простое и долгое. Надо же как-то греться все это время ;)
monolithed
26.08.2015 11:47Про рефакторинг кода забыли упомянуть.
Например, в следующем примере делать шаблонную автозамену строки во всем файле будет безрассудством, а если править руками, то тоже можно что-то пропустить.
Было:
std::string string (const std::string &string) { return string; } string("test");
Стало:
std::string text (const std::string &value) { return value; } text("test");powerman
26.08.2015 12:13+2Зависит от языка. Например, для Go такое работает (плагин vim-go, команда
:GoRename). А для динамических языков — да, только ручками и внимательно, делать массовый search&replace стрёмно. Но наличие автоматической проверки синтаксиса и юнит-тестов обычно делает эту задачу не такой сложной.monolithed
26.08.2015 12:23+3А я собственно не являюсь сторонником ни IDE, ни редакторов.
Глупо даже обсуждать, что лучше использовать. Если у меня не работает IDE я открываю Vim.
Мои предпочтения зависят от ситуации.
denqxotl
26.08.2015 11:48+1Первое время, когда начинал работать с рельсами, то использовал RubyMine, но потом «старшие парни» показали Vim. Я потратил много времени на его настройку под себя, но сейчас не могу перейти на какую-то IDE, я просто влюбился в него. Очень приятно, что при работе с рельсами даже консоль не обязательно открывать. Почти все фичи можно прикрутить к нему. Сейчас даже на хабре перемещаюсь используя навигационные кнопки Vim'а.
Delphinum
26.08.2015 13:00И второе, vim — это не IDE и делать из него IDE не стоит.
Почему вы так считаете?
rutaka_n
26.08.2015 13:29Идеологически IDE — Integrated Development Environment, то есть «всё включено», а vim эффективен вместе с другими *nix-инструментами и интегрировать их в него особо нет смысла, т.к. они уже под рукой.
Delphinum
26.08.2015 13:33vim эффективен вместе с другими *nix-инструментами
То есть Vim для Windows вы хороните сразу? )) А как же горячие клавиши для работы с этими инструментами?
Идеологически IDE — Integrated Development Environment, то есть «всё включено»
Таки IDE это еще и синтаксический анализатор, который встроен в редактор.rutaka_n
26.08.2015 13:41В WinNT-системы портирован bash и большая часть(если не все) core-utils, однако лично мне в windows не удобно и я им не пользуюсь, т.к. пишу ПО только под *nix-системы.
А горячие клавиши для работы с инструментами это лишь один из вариантов использования, другой это команды.
Кому как удобнее — у разных вещей, методов, идеологий разные приверженцы.Delphinum
26.08.2015 13:44А горячие клавиши для работы с инструментами это лишь один из вариантов использования, другой это команды
Ну редачить файл тоже можно командами, только это дольше.rutaka_n
26.08.2015 14:36Ну редачить файл тоже можно командами, только это дольше.
Дольше, если делать это не в vim.Delphinum
26.08.2015 16:38А как Vim ускоряет набор команд?
rutaka_n
27.08.2015 09:51А как Vim ускоряет набор команд?
Имею в виду командный режим(normal mode)Delphinum
27.08.2015 14:15Тогда возвращаюсь к вашему коменту:
А горячие клавиши для работы с инструментами это лишь один из вариантов использования, другой это команды
и говорю, что для нормального использования сторонних *nix-утилит нужно настраивать эти самые команды (которые есть горячие клавиши). Так что без интегрирования некоторых утилит прямо в Vim (через горячие клавиши, плагины и т.д.), использовать его становится не так удобно.rutaka_n
27.08.2015 15:53Команды <> горячие клавиши.
А утилиты можно вызывать из оболочки, т.е. никакой интеграции производить не надо.Delphinum
27.08.2015 17:04Команды <> горячие клавиши.
Почему же?
А утилиты можно вызывать из оболочки, т.е. никакой интеграции производить не надо.
Вы про::!command?rutaka_n
27.08.2015 21:57Команды <> горячие клавиши.
Почему же?
Потому что команды можно выстривать в различные комбинации и сочетания и их удобнее вводить.
Вы про: :!command?
Да, как вариант. Но я обычно использую screen.Delphinum
27.08.2015 23:37Потому что команды можно выстривать в различные комбинации и сочетания и их удобнее вводить
Не совсем вас понимаю, ну да ладно.
Да, как вариант. Но я обычно использую screen.
Мне не очень удобно ими пользоваться. Но каждому свое, как известно.
Cheater
26.08.2015 13:08Vim хорош прежде всего идеологией своих клавиатурных комбинаций. Какие бы там проблемы с высокоуровневыми средствами в нём ни были, переход на vim keybindings в любом редакторе/IDE — это огромный прирост скорости. У меня у самого основное средство — это emacs со включенным режимом эмуляции vim («Evil mode»).
SdotR
26.08.2015 13:15+4Я долгое время брезговал 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.Delphinum
26.08.2015 13:20И когда приходится писать текст на русском, Vim, в этом случае, постоянно заставляет переключать раскладку
Таки вроде переключение раскладки придумано для переключения раскладки?SdotR
26.08.2015 13:25Неудобно переключать раскладку для ввода команд Vim'а. Ну и режимы ввода Vim'а тоже бесят — ещё один пережиток прошлого.
Delphinum
26.08.2015 13:30В Vim есть встроенный механизм (lmap), позволяющий автоматически переходить на нужную раскладку при переключении режимов (почитать о нем можно тут habrahabr.ru/post/98393). Удобная штука. Я от нее отказался, так как не смог настроить переключение раскладки на CapsLock (видите ли сигнал этой клавиши не обрабатывается Vim'ом).
Ну и режимы ввода Vim'а тоже бесят — ещё один пережиток прошлого
А вы точно пользовались Vim?SdotR
26.08.2015 13:39Я настраивал lmap в Vim'e (настраивал 3 года назад, а не использую его уже год, поэтому сейчас не вспомню; а конфигов под рукой нет). И там были какие-то свои проблемы, но я уже не помню, к сожалению.
Ну это был MacVim.Delphinum
26.08.2015 13:41И там были какие-то свои проблемы, но я уже не помню, к сожалению
Я его настроил себе и проблем не было (кроме описаных выше). Вполне удобный инструмент.
Ну это был MacVim
Странно что вы считаете режимы ввода Vim'а пережитком прошлого )
Cheater
26.08.2015 13:26В emacs есть плагин для поддержки нескольких курсоров, так и называется — multiple-cursors.
Его ещё демонстрировали в Emacs Rocks: http://emacsrocks.com/e13.html.
Но он, к сожалению, не без глюков, сам щупал, в том же sublime text эта фича значительно более стабильна.
plashenkov
26.08.2015 23:17В Scintilla тоже наконец-то добавили множественные курсоры, работающие подобно таковым в Sublime Text, т.е. теперь их можно перемещать стрелками: sourceforge.net/p/scintilla/feature-requests/1085
Это очень здорово. Скоро во многих редакторах… :)
marenkov
26.08.2015 14:32Почитав все это решил еще раз попробовать подружиться с vim. Прикольно, конечно, но все же моей любимой командой в нем остается :q!
Delphinum
26.08.2015 16:39+1Почитав все это решил еще раз попробовать подружиться с vim
А зачем? Если вам нравится используемый вами редактор/IDE, пользуйтесь им и не обращайте внимание на других.DrLivesey
26.08.2015 16:55+2А зачем? Если вам нравится используемый вами редактор/IDE, пользуйтесь им и не обращайте внимания на других.
Не соглашусь с этим утверждением. Всему нужно дать шанс. Может понравиться, а может и нет. Я бы основывался именно на этом.
neiromancer
26.08.2015 21:44Я админствовал 10+ лет. vi/vim знаю/умею.
Но когда потребовалось стать разрабом и писать сразу на: Perl, JavaScript, SQL, HTML, CSS = Sublime rocks!
unix way = нужно выбирать правильный инструмент под задачуDelphinum
26.08.2015 21:47Я админствовал 10+ лет. vi/vim знаю/умею
А как это связано?
Zelgadis
26.08.2015 22:18В vi/vim'e удобно править конфиги. Я примерно так же сделал, но у меня было vim -> TextMate (быстро наскучил) -> MacVim -> RubyMine -> vim сейчас на NeoVim перехожу.
neiromancer
26.08.2015 22:49У vim есть преимущество, попадая на любой новый сервер ты знаешь, что там есть vim и он будет работать так же как и везде. Причём у тебя есть ограничения: ssh + консоль.
Для разработки ПО — это преимущество не актуально, т.к. разработка ведётся обычно на 1-2 ПК где ты можешь настроить себе окружение. В vim для нормальной разработки требуется намного больше телодвижений, чем в заточеном для разработку редакторе/IDE.
Не нужно гвозди забивать микроскопом.marenkov
27.08.2015 11:25Проверил, на наших серверах нет vim. Так что "почти на всех".
Delphinum
27.08.2015 14:17Учитывайте еще то, что на всех серверах версия этого самого Vim'а может отличаться, а на некоторых так вообще стоит какая нить другая реализация vi, так что аргумент типа — в любом месте, в любое время — не очень уместем (еще один аргумент в вашу копилку «Против Vim») ;)
dimas
28.08.2015 01:46Вим не настолько менялся, чтобы было невозможно пользоваться даже старыми версиями :) Посмотрел свой конфиг — даже для версий ниже 7 «отвалятся» только табы из удобных фич, остальное будет работать.
Могут отвалиться разлапистые плагины, требующие поддержки перла или питона, но их не так много, да и не всегда они нужны.Delphinum
28.08.2015 14:47Частенько чту исходники различных популярных плагинов, и у всех имеются жесткие ограничения на версию Vim и его расширения. Так что не скажите )
Могут отвалиться разлапистые плагины, требующие поддержки перла или питона, но их не так много, да и не всегда они нужны.
Плагины не нужны? Без плагинов я прекрасно отредачу и с помощью какого нить ed.
PerlPower
27.08.2015 00:25+1Все-таки попробуйте вместо ack использовать ag, он же silver searcher, а вместо них обоих ctags — благо интеграция с vim у него была еще в те времена когда компании Jetbrains еще не было.
dimas
28.08.2015 15:18Кстати, если используется плагин ack.vim, то для его использования с ag можно просто добавить настройку:
let g:ackprg = 'ag --nogroup --nocolor --column'
marenkov
В свое время тоже мучился от тормознутости IDE. Но вместо настройки и поиска плагинов для текстового редактора потратил 100$ на память. А позже и на новый ноут. Мне кажется, что если вы способны справиться с vim, то подобные затраты для вас не должны быть проблемой. Хотя с другой стороны, подозреваю, что все это доставило вам немало удовольствия.
dimas
Не забывайте еще, что vim-ом удобно пользоваться удаленно, даже на тощем канале и он есть практически на любой *nix-машине, и тогда достаточно только вытащить на неё свой конфиг (я еще беру питоновский файл, который вытаскивает все нужные плагины), и уже работаешь в удобном и комфортном окружении.
marenkov
А резве кто-то занимается разработкой удаленно на сервере? Да еще и на медленном канале?
Если уже очень надо, то в IDE есть выгрузка изменений на сервер. И даже удаленная отладка.
Мы все правки вносим через git. Если очень надо что-то попробовать на тестовом сервере, то у меня всегда подмонтирована его веб-директория и есть gedit. В крайнем случае ssh + nano либо mc.
И да, на наших серверах нет vim ;)
dimas
Кроме разработки, есть еще куча разных операций, которые приходится делать удаленно, это раз.
Два — иногда приходится работать из не самых удачных точек, например я как-то работал из паба на Мальте :) Или из чайной в Китае.
IDE с выгрузкой на сервер — это лишние действия и потерянное время…
Гит вы вообще непонятно к чему приплели, или вы и при отладке на тестовом окружении все коммитите в общий гит? :)
А мне вот не надо этих крайних случаев с неудобными редакторами, у меня есть vim :)
Сочуствую тем кому приходится работать «на ваших серверах» :)
marenkov
В статье сравнивается vim с IDE, значит речь о разработке. Или вы используете IDE для правки конфигов?
По поводу работы из неудачных точек, то по своему опыту скажу, что править файл через ssh даже хуже чем локальным редактором из подмонтированного раздела (задержки на переводе курсора не слишком располагают к работе). Ну и в конце концов — это крайний случай.
По поводу git — рабработка фич ведется в отдельных ветках, все правки можно коммитить, а перед слитием в девелоп объеденить их в один. Хотя на самом деле все делается локально, а на один из тестовых серверов выгружается только для тестов готового функционала. Выгрузка производиться из git-a. Правка чего либо прямо на сервере — крайний случай для которого годятся описанные мной варианты (и не требуют недель на изучение редактора).
На сколько я понимаю, vim хорош если вы ведете разработку прямо на сервере через медленный инет. Сочувствую.
dimas
Мда, вам похоже лишь бы поборцевать. Не вижу смысла в дальнейшей беседе.