Пользователь
3,3
рейтинг
15 июля 2012 в 14:31

Разработка → Vim перевод

VIM*
Всё начиналось в меру невинно. На первом курсе ты экспериментировал один или два раза, но Nano и Pico были проще, они были ближе к тому, чем ты уже пользовался в средней школе на машинах с Windows и Mac. Но время текло, твой багаж знаний пополнялся тем, что вам давали в вузе, и ты начал что-то замечать: все действительно великие программисты, люди, которым под силу было уместить в 4 строчки, то, для чего тебе требовалось 10 страниц кода, те, у которых богатое функциональностью решение учебного проекта было готово через день, в то время как ты неделями мучался лишь с базой, никто из них не пользовался Nano или Pico.

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

«Как ты это делаешь?» — недоверчиво спросил ты.

Твою жизнь изменил лаконичный ответ, состоящий из одного слога: «Vim.»

Вначале ты был раздражен и куда менее производителен. История браузера являла полный индекс документации Vim, твои Nano и Pico-друзья считали тебя сумасшедшим, Emacs-товарищи умоляли одуматься, ты заплатил деньги за ламинированный экземпляр пямятки Vim. Даже спустя недели тренировок, ты всё ещё по привычке иногда тянулся к мыши, но затем одергивал руку, понимая, что придется искать в сети нужную комбинацию для выполнения рутинной операции, о которой раньше тебе никогда не приходилось задумываться.

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

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

Vim вошел в каждую часть твоей сетевой жизни. Неудовлетворенный скудными функциями ViewSourceWith, ты быстро вырос до Vimperator и затем до Pentadactyl. Ты бродил по сети с него. Теперь ты и есть сеть. Когда ты решил написать приложение для iPhone, первым делом ты сменил редактор по умолчанию с XCode на MacVim. Когда у тебя появилась работа с кодом .NET, ты немедленно купил копию ViEmu для Visual Studio, не будучи удовлетворенным функциональностью его бесплатного собрата, VsVim.

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

«Как ты это делаешь?» — спросил он голосом, полным трепета.

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

«Vim.»

:wq
Перевод: Рудис Муйжниекс
Анатолий Будько @atomlib
карма
268,7
рейтинг 3,3
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (277)

  • 0
    как раз сейчас сидел и изучал документацию по виму :))

    правда, до описанного в тексте еще не дошло…
  • +14
    Не :wq, а :x.
    • +10
      ZZ
    • +11
      Мне к стати wq удобнее, получается очень естественно безымянным и мизинцем как по пианино
      • –3
        Будучи подростком :w! стал для меня полной заменой CMD+S
        • +1
          Emacs негодуэ?
          • +3
            Граммар-наци негодуэ.
            :w! вряд ли когда-то был подростком.
            • +1
              Я буду раставлять запятые.
              Я буду раставлять запятые.
              Я буду раставлять запятые.
              • +2
                * расставлять
                «Я выучу русский язык» * 3
                • +3
                  «Я выучу русский язык\n»
              • +2
                Вы, видимо, совсем не поняли, почему граммар-наци негодує.
    • +3
      А я вот тоже жутко привык к :wq :)
  • +1
    Меня прет заголовок статьи — такой же могущественный как и он.
  • –5
    А самый лучший код получается в nano или редакторе mc — чем менее удобен редактор, тем больше задумываешься перед тем как пишешь, чтобы меньше потом исправлять :)
    • +2
      Кстати, да.
      Вместо
      var a = [], b = 0, c = {};
      пишу
      var a = []; var b = 0; var c = {};
      только потому, что проще и быстрее удалить всю строку, чем выискивать нужную переменную, потом не забыть запятую еще удалить.
      • +3
        Ну вот, переводы строк во втором примере не сработали… :(
    • 0
      mcedit очень удобен.
      Только в нем и работаю
      • +3
        Там сделали автокомплит и нормальный автоиндент?
        • +2
          Даже не подозревал о таких возможностях в консольных редакторах :)
          • +3
            Пришло время переустановить Емакс!
  • +9
    А потом пришел Sublime Text 2, который был для тебя, как Java, C# или Ruby после C. И узрел ты откровение: даже не обладая ни желанием, ни временем, ни силами зачитывать документацию до дыр и запоминать десять тысяч хоткеев, ты можешь творить Чудо с Текстом. И помогает тебе в этом Command Palette.

    Такие дела.
    • +5
      Java, C# или Ruby после C


      @Сim, можете объяснить что вы имели ввиду?

      Если вы про то, про что я подумал — то я могу сказать что я прошел этот путь — но все равно вернулся на С (С++) ввиду приемуществ последнего.

      P.S. Скорее всего ваш ник — опечатка (Vim — Cim, причем С и V рядом).
      • +1
        Извините, две опечатки в комментарии.

        1. Cim (хотел позвать)
        2. В посткриптуме — [irony] :))
        • +2
          На самом деле вы были правы по поводу ника. Думаете, очень удобно печатать, когда текстовый редактор только и умеет, что пищать и портить текст? Вот с перепугу не ту клавишу и нажал. :)
      • +4
        ну статья шуточная, вот и я придуриваюсь:)
        А имел в виду я, что Sublime более высокоуровневый по сравнению с Vim: как ява и си, например.
        Безусловно, вим впереди планеты всей: вон и в sublime есть режим эмуляции vim, а не наоборот
        • +2
          Заметьте, куча прог имеет режим эмуляции Vim, догадываемся почему?)
          В тоже время Vim тоже не промах и имеет кучу плагинов, превращающих его в тот или иной инструмент.
          • +4
            Вот я и говорю, что Вим всё равно впереди всех.
            И он, конечно, удобен. Но для этого надо усердно работать и изучать документацию. И тогда это будет швейцарский нож на все случаи жизни, а не просто качественный и удобный молток-гвоздодёр
            • +3
              Я так и не смог пересесть с Сублима на Vim, как ни пытался. Одной из причин, было то, что вимовский плагин к Lua(+CoronaSDK) необходимо было допиливать, а сублимовский плагин работал практически идеально. А второй, основной, причиной стало то, что пройдя дважды vimtutor я все равно забывал все основательно буквально на следующий день.
              • +2
                Главное не сдаваться! :-D
                Со временем все запоминается, и открываются все новые и новые возможности.
              • +1
                А мне туторы никогда не помогали тоже. Только постоянная практика. Сначала гуглишь каждый шорткат, потом уже туловище само привыкает жать Ctrl + X + S, Ctr+S, Alt+Shift+% и т.п
                • +1
                  Эх, как же пальцы раскорякиваются, но это не к вим-у претензия, а расположенbю Ctrl и Alt.
                  Хотя ту пролетала статья про использование буквенных клавиш как модификаторов (например удерживая f нажимаем о отпускаем o)
                  • +1
                    привычка на самом деле. оно не так ужасно как рисуют.
                    и нет, у меня нет тентаклей для работы в Емакс. :)
                  • +2
                    Перемещение Ctrl на место Caps Lock решает большую часть проблем.
              • +1
                >>забывал
                подсказка в тексте — ламинированная шпаргалка.
        • +1
          Ага, только эта поддержка даже до уровня екмаксовкой поддержки вима не дотягивает. Сходу — сел к человеку, через 10 секунд заметил, что C-o не работает.
    • –6
      Ахахаххахахах зачёт. Неожиданно)
    • +1
      Плюсую. Мои попытки изучения Vim были прерваны грубым вторжением Sublime Text 2. Папа Vim теперь используется только когда нужен консольный редактор.
    • +1
      В «сублайме» есть Vintage Mode между прочим.
      • +2
        Есть, и на фоне остальных попыток эмуляции вима он даже весьма неплох (сравнивал, например, с IdeaVim).
      • +6
        :sp нет. И это печально. Печально до такой степени, что этого достаточно для отказа от sublime
      • 0
        У меня там не заработал даже dd, может я не так этот винтаж готовлю?
        • +2
          видимо да, потому как dd вполне работает.
        • +1
          dw, cw, 5dd — это всё работает. Командного режима там нет. Точнее, есть попытка его реализовать (VintageEx), но вот она действительно скудна в плане команд.
    • +3
      Было дело, пришел. И затем снова ушел. Зачем нужен эрзац-вим, если везде есть вим настоящий?
      • –1
        Хех, «зачем в коробке-автомате есть режим ручного переключения передач, если везде есть ручные коробки?»
        • +2
          Вот не понимаю зачем коробка автомат. Ручка — надежнее, дешевле, дает больше контороля.
          • +5
            Автомобиль — это средство для комфортного и безопасного перемещения своего зада из пункта a в пункт b. Лишние телодвижения не предполагают ни комфорта ни безопасности.

            Текстовый редактор — средство для удобного написания/правки кода. Лишние телодвижения… ну вы поняли.

            Если вы на гоночной трассе и являетесь профессионалом — вам нужна ручная коробка.

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

            В большинстве случаев на дороге абсолютно достаточно возможностей АКПП.

            В большинстве случаев работы с кодом абсолютно достаточно Sublime Text 2.

            Каждый выбирает по своим потребностям, в идеале, исключая фактор «понтов». Кому-то вон и электростеклоподъемники мешают чувствовать полный контроль над машиной.

            Уж простите, если такая точка зрения будет вам неприятна.
            • 0
              Неправильные у вас оссоциации.
              Скорее VIM — это ручка, а Sublime — Автомат.
              • 0
                Я думаю smargelov это и имел ввиду.
              • +1
                А что я не так сказал?
        • +3
          Не совсем так, правильный вопрос таков: «Зачем человеку, умеющему и любящему ездить на ручке нужен режим ручного переключения передач в автомате?»
          • +1
            А не любящему? :)
            • +4
              Дак пусть себе ездит на чем хочет, кто ж ему не дает?

              Просто в контексте этой ветки предполагается, что появился ST2 — и все вимеры, которые умели, любили и могли (см. текст статьи) резко узрели свет и массово на него перешли (см. стартовый коммент ветки). А все сишники — на Ruby (прям все и прям сразу, да, конечно). Я сугубо с этим не согласен. А так, ST2 — отличный редактор.
    • +1
      А есть ли переходить на Sublime Text 2, если ты уже познал дзен Вима? Т.е., какие он может преподнести фишки, которых нет/невозможно настроить в Vim'е?
      • +1
        Есть multi-input — штука интересная, но киллер-фичей мне не показалась.
        • +2
          Мне товарищ эту фичу тоже представлял как очень крутую. Да, согласен, крутая, но я пока не могу представить где она могла бы мне пригодиться =\
          • +1
            Для редактирования конфигов самое то, как альтернатива замене по регуляркам, только в режиме реального времени.
            Например: ваделил все объвления переменных (шорткатом естественно), тыкнул любую стрелку, включился режим мульти-ввода, подабовлял всем переменным префиксы, переносы, табы где нужно. На все уходит буквально пару секунд, быстрее чем написать регулярку.
            Но я согласен что это не киллер-фича, но в некоторых ситуация, бывает полезна, так же как и сотни вимовских команд, которые используются раз в пол года.
            • +2
              Ну не знаю, %s/fuu/bar/g вполне удобен.
        • +1
          Этот мульти-инпут в emacs был известен минимум год назад (=
          www.youtube.com/watch?v=r2o9HYi7DOY
          • +1
            Вопрос-то был про vim.
      • +1
        Я думаю, смысла нет. Сублим — это такой «вим попроще». Однако, есть миникарта кода и мультиинпут. Но не киллер фичи это, нет. Command Palette, опять же, для вас спасением не будет — вы и так запомнили сотню команд вима.
  • +2
    Пользуясь случаем прошу совета. Недавно начал постигать Vim, по тихоньку… Собираюсь брать через пару месяцев новый ноутбук, задумывался брать Mac (мне сборка нравится), но крутится на нем будет еще и Windows (в силу специфики работы). Собственно вопрос — можно ли юзать Vim с учетом что некоторые клавиши на маке отсутствуют?
    • +4
      vim можно использовать практически на любых терминалах без каких-либо проблем.
    • +4
      Если вы про клавишу win, то в vi/vim она не нужна.
      • +2
        мне кажется, SantaClaus16 имел в виду Insert, Home и еще некоторые.
        Нет, виму они не нужны. Более того, Vim-вей — это использовать основную клавиатуру без всяких стрелочек, инсертов, эндов и так далее. Только в таком случае получится эффективная работа с редактором, не отрывая пальцев от ASDF & JKL;'
    • +2
      нет никаких проблем. Работаю с vim на macbook air, каких-либо сложностей из-за отсутствия клавиш не замечал…
    • +1
      Проблема была кажется, с клавишей Cmd/Ctrl в TabBar в Mac OS X.
      Уже не помню, в чём она заключалась, но она решилась правкой плагина.
      Т.е. проблемы могут возникнуть, но они легко решаемы.
    • +1
      Советую перебиндить в макоси бесполезный CAPS LOCK на Ctrl, в принципе больше ничего специфичного делать не нужно.
  • +11
    Тег «фанатизм» очень удачно подчеркивает тонкий сарказм повествования
  • +9
    Я вот предпочитаю использовать IntelliJ IDEA. В ней тоже практически никогда не приходится использовать мышь. И чувствую я себя достаточно продуктивно под ней по сравнению с Eclipse, где иногда все-таки приходится тянуться за мышкой. В случае веб-девелопмента все равно приходится довольно часто тянуться за мышкой, что бы обновить страницу в браузере-сделать несколько тыков.

    Есть ли у кого-то опыт профессиональной разработки на Java под vim? Как дебажить и проч и проч? Хотелось бы попробовать полный хардкор…
    • +2
      Есть довольно скромный, но всё же опыт разработки на Java в Vim. Из различных плагинов больше всего функциональностью порадовал eclim. Для отладки находил JavaKit, правда так и не попробовал его. Для быстрой справки использовал файлы помощи, сгенерированные Vim Doclet, но пара десятков метров документации сильно замедляет поиск в ней (командой :helpgrep) и даже работу с тегами (при дополнении аргументов команды :help).
  • +1
    vim — это просто супер удобно, а для Rails есть еще и сборка-солянка Vimfiles от Akita.
    • +1
      пользовался «солянкой» когда только начинал Vim-ить, но когда число плагинов у них перевалило за пару десятков, удалил и собрал свой набор+vimrc попроще и только с самым необходимым.

      в общем, как советовал мне один сотрудник, лучше начинать знакомиться с голым вимом и постепенно в него добавлять что-то свое.
      • +1
        Согласен, в последнее время Fabio Akita что-то темное мутит со сборкой, порой отваливаются нативные вещи — меняется поведение, что не очень хорошо. Да и кол-во плагинов не самым лучшим образом влияет на качество ;)
  • +7
    Ну вы тут все собрались прям жестокие кодеры, которые так быстро генерируют свой говно-код, что даже нет времени на мышь оторваться! Все «великие программисты, которые в четыре строки умещают то, на что вам надо десять страниц кода» пользуются нормальными IDE. А извращенцы, которые мнят себя крутыми, используют неудобное ПО, написанное когда они ещё не родились, чтобы казаться круче в глазах непонятного кого.

    Прогнозирую слив всей своей кармы этим комментом, но как будто бы мне есть до этого дело.
    • +6
      Все «великие программисты, которые в четыре строки умещают то, на что вам надо десять страниц кода» пользуются нормальными IDE.

      Серьезно? У вас прямо-таки есть список всех великих программистов вместе с IDE/редакторами, которые они используют? Можно взглянуть?
    • +4
      Сильно зависит от языка.
    • +8
      Дело даже не в вашей точке зрения, вы просто хам и говорите гадости, которые не имеют никакого отношения к реальности.
      Удивительно как можно заклеймить качество кода по текстовому редактору.
      btw troll me a river
      • +2
        Ну как бы автор так и делает — клеймит «крутость» программиста по текстовому редактору. Это моё мнение, а не в коем случае не троллинг.
        • +12
          А по мне так в статье просто доброе художественное произведение на компьютерную тематику, без оскорблений, хамтсва и меряния *** на тему крутости.
          Ну а если вы лично считаете Vim (или любой другой инструмент) неудобным, то это не значит что он действительно неудобен.
          • +2
            Инструмент просто не может быть действительно удобным. «Удобство» субъективная категория.
    • +4
      Я не считаю себя программистом, но все равно очень люблю vim за то, что он стоит на всех nix серверах, а если не стоит, то его очень легко поставить.
      • –3
        Равно как и nano.
        • +2
          Не ради флейма, часто пользуюсь файловым менеджером в vim-е следующим образом: есть некоторые файлы в папке, доступ к которой простому пользователю запрещен, точное имя этих файлов не помню или они очень длинные и автодополнение не работает, vim запускаю так:
          sudo vim /путь к папке/
          и уже в самом vim-е выбираю нужный мне файл.
          Есть ли такая фишка в nano, без нее мне будет очень тяжко :)
          • +2
            можно еще так.
            $vim
            : e <путь к директории, если текущая то .>
            ctrl+w после v (рабочая область вима поделится на две вертикальных области(для горизонтального разделения нажмите n))
            далее во второй области можно открыть любую другую директорию.

            Таким способом с ним можно работать, как с обычным фм.

            Я люблю вим за его распространенность, за удобство использования.

            Как-то требовалось заменить все тэги с <root_> на <имя файла-root> в папке с 100к xml. Был написан макрос на виме(vim script), который все это дело быстренько сам и сделал. Те не прибегая к программированию, можно делать такие вещи.
            А какой еще радоктор на это способен? дедушку emacs в счет не берем.
            • +2
              sed?
              • +1
                sed не берем. Ни на каждой win машине установлин cygwin или mingw.
                • +4
                  vim тоже установлен не на каждой win машине.
                  • +1
                    согласен. приведу следующий аргумент, чтобы решить это задачу с sed нужно знать регулярки.
                    В виме же все решается, переходите в режим записи макроса в свободный слот, после нажимаете для вас обычные комбинации(вы ведь знаете вим, этого достаточно). Конечно минимальное знание регулярок понадобиться, но зато остальные действия решаются очень просто.
                    • +1
                      В виме можно еще и запустить один и тот же макрос на многих файлах автоматически?
                      А регулярки надо знать в любом случае:)
                      • +2
                        Можно запустить макрос в окне со списком файлов (включая и окно файлового броузера netrw)
                        • +1
                          Хм. Забавная идея, спасибо:)
                          Но это в любом случае не очень помогает в чуть менее тривиальных случаях, когда надо делать немного более сложное преобразование.
                          • +1
                            Неудивительно, в совсем нетривиальных случаях вообще вот не помогает. Но в тривиальных — вполне себе решение.
    • +4
      Мне как программисту, все равно где писать/исправлять код. Есть IDE — хорошо, нет IDE — тогда Vim (vi) или mcedit (nano).
      Так что корреляция между качеством написанного кода и редакторов стремится к нулю.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Очень приятное чтиво, на маке лучшей зарядки по утрам для пальцев не найти! (:
  • +1
    «Vimperator и затем до Pentadactyl. „

    а я наоборот :)
  • –5
    <вброс id=1>
    Интересно, а кто сколько знает людей, перешедших с Vim на Emacs, а кто сколько — чтобы наоборот? Я вот знаю людей, перешедших с Vim на Emacs, но не знаю ни одного, чтобы в обратном направлении.
    </вброс>
    • +13
      Они просто после Emacs себе все пальцы переломали и больше не могут программировать в Vim… =)
  • –7
    <вброс id=2>
    Интересно, а кто сколько знает людей, перешедших с Vim или Emacs на более высокоуровневые и эффективные IDE, а кто сколько — чтобы наоборот? Странно, но мне вот первые люди встречались, а вторые — ни разу.
    </вброс>
    • +7
      Странно, но мне вот первые люди встречались, а вторые — ни разу.
      Ну что ж, здравствуйте, я пришел к Vim с высокоуровневых IDE и ничуть об этом не жалею… По мне, так для Python нет ничего лучше, чем Vim (хотя ST2 тоже хорош).
    • +2
      Ну даешь… Я же с Eclipse на Emacs перешел!
    • +2
      Вброс уныл, поскольку постулирует эффективность и высокоуровневость «мейнстримных IDE», не подкрепляя эту точку зрения доводами.

      Я перешел с Eclipse на vim лет 6 тому.
  • –4
    <вброс id=3>
    Интересно, а кто сколько знает убеждённых пользователей Vim, хотя бы пробовавших, хотя бы прошедших туториал в Emacs-е, а сколько — пользователей Emacs, хотя бы прошедших туториал в Vim-е? Забавно, но вот все виденные мной пользователи Emacs знакомы с Vim-ом, зато встречал много пользователей Vim, которые даже не пробовали туториал в Emacs-е.
    </вброс>
    • +1
      Я когда поставил себе emacs для знакомства (к этому времени уже очень хорошо знал vim) первым делом полез делать туториал. После его прохождения я понял: до чего же не удобные эти кнопки pgUp pgDown, Home, End.

      Отвыкнуть уже не могу, но emacs пока до конца не осилил. Перенастроил все ИДЕ на поведение emacs.
    • +1
      Пробовал Emacs после Vim, так и не понял. зачем он мне нужен и за что его так любят… Это ведь просто ещё один очень расширяемый текстовый редактор с кучей пальцесломательных сочетаний клавиш…
      А Vim… Режимы Vim — это оно, это то, что надо. Именно так нужно работать с текстом.
      Но все это дело вкуса…
      • +1
        с кучей пальцесломательных сочетаний клавиш…

        А вы Ctrl на его историческое место поставили? Если нет — то рекомендую, в vimе тоже становится удобнее.
        • +1
          Кстати, про control. Я для переключения раскладки использую capslock — и это очень очень удобно.
          Но из-за этого не могу в emacs кнопку control поставить на capslock, т.к. будет конфликт для меня.

          Вот ведь дилемма…
          • +1
            Можно попробовать заставить это работать извне иксов (actkbd). Я сейчас под windows, тут подобное работает с autohotkey, поэтому не могу сказать подробнее, но вообще оно должно работать.
          • +1
            Для меня переключение раскладки в окне — операция редкая, так что отдавать такую удобную кнопку на это у меня рука не повернется.
            • +1
              ну, кому как. Например, когда я пишу коммент на habrahabr к топику про vim и хочу рассказать про то, что я использую вместо control+shift capslock, то переключаю раскладку не менее 5и раз.
              И тут уже даже не важно vim это, или emacs, или opera, или чат. Значительно удобнее и быстрее.

              Думаю, ещё это сильно зависит от вида деятельности ;)
              • +2
                И от стиля речи. Например, мне переключение раскладки на альт-шифте нисколько не мешает писать коммент на хабре к топику про вим.
    • +2
      Я пытался пройти туториал Emacs, но не смог себя заставить пройти до конца. Наверное мой мозг можно сломать только один раз и он уже сломан Vim'ом. Возможно, если бы я намапил Ctrl на Caps, мне было бы легче в Emacs.
    • +2
      Выбирая продвинутый редактор прошёл туториалы обоих. Уже владея Vim-ом и наталкиваясь на подобные коментарии несколько раз повторно проходил туториал Emacs, но ни разу так и не захотелось продолжить им пользоваться. Плюс читал статьи и главы книг, посвящённые Emacs. В итоге могу сделать что-то базовое в Emacs, но использую Emacs-сочетания только для редактирования командной строки в оболочке, а для текстов и кода лучше Vim-а не нашёл.
    • +2
      Проходил туториалы вима и емакса, вима даже дважды. В результате использую ST2, во время написания кода, надо думать о коде, а не вбивать сотни шорткатов в гугл. Но судя по туториалам, вим мне понравился больше, потихонечку пытаюсь его осилить, но пока безрезультатно.
      • +1
        Аналогично. Вима туториал даже раз 5 проходил.
      • +4
        И не осилите, поверьте мне.
        Вим бесполезно пытаться осилить потихонечку, это как учиться плавать в ванне.
        Надо просто садиться и начинать в нем работать целый день. Первую неделю будет мучительно, месяц — тяжело, через год привыкните, через пять не будете понимать как вы жили до этого.
        • +1
          Проблема в том, что нельзя просто сесть и начать в нем работать целый день, потому как для работы приходится перепробовать кучу плагинов, прогуглить кучу шорткатов, научиться править конфиг, а мне ведь еще и код надо писать. В результате переход на VIM, оказывается экономически не выгодным, т.к. идет резкий и очень сильный спад в производительности. Хотя я и понимаю, что, в долгосрочной перспективе VIM позволит мне экономить кучу времени, но в данный момент, могу позволить себе ковырять VIM только вечерами в свободное от работы время.
          • +2
            В виме надо делать реальную работу, тогда производительность прийдет очень быстро.
            • +1
              Я не могу сразу сесть и начать делать в нем реальную работу, т.к. все что у меня есть — это подсветка синтаксиса, для остального надо ковырять плагины и конфиги. И хорошо если язык компилируемый и ругнется на ошибку вовремя, а не начнет валиться через месяц, из-за того, что где-то в коде я забыл отрефакторить одну переменную, или банально опечатался.
              • +1
                Брр… банальная опечатка в имени переменной может обнаружиться через месяц? Это как так? Это что за язык такой?
                • +2
                  Если данная ветка кода выполняется только раз в месяц — то почему нет? Насколько я помню, будет рантайм-еррор/нотис в PHP, JS, Python, Ruby в таком случае. Думаю, в большинстве динамически типизированных языков такая же ситуация.
                  • +1
                    Ну как, почему нет. Достаточно прогнать через анализатор кода, что бы выявить ошибку. Это даже если не вспоминать про тесты.

                    Для Perl, на пример, достаточно указать ключ -c
                    -c causes Perl to check the syntax of the program and then exit without executing it. Actually, it will execute and «BEGIN», «UNITCHECK», or «CHECK» blocks and any «use» statements: these are considered as occurring outside the execution of your program. «INIT» and «END» blocks, however, will be skipped.

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

                      И что, даже в eval { } найдет ошибки? А при вызове метода на объекте по имени?
                      Пример из орейлевского perl cookbook (представьте, что ошиблись в имени одного из методов):
                      @methods = qw(name rank serno);
                      %his_info = map { $_ => $ob->$_() } @methods;
                      


                      Не думаю, что у других языков будет какое-то отличие.

                      Будет. Для них может не существовать таких утилит. Для PHP, например, до недавнего времени таких штук не было. Сейчас, возможно, это можно сделать с помощью hiphop. Но я сомневаюсь, что тот же перловский пример на PHP профейлится на этапе компиляции:
                      $methods = ["getName", "getRank", "getSerNo"];
                      $data = array_map(function ($method)  use (&$ob) {
                          return $ob->$method(); 
                      }, $methods);
                      
                      • +1
                        Ключ -c — это не утилита, это нативное средство. Речь идет не о программных ошибках, а о опечатках при декларации переменных.

                        Для выявления программных ошибок синтаксический анализатор никогда и не был предназначен. Для этого существуют тесты.
                        • +1
                          Ключ -c — это не утилита, это нативное средство.

                          Это уже детали реализации. Может быть нативным (ключом утилиты perl), может не быть — для целей обсуждения данного вопроса это неважно.

                          Речь идет не о программных ошибках, а о опечатках при декларации переменных.

                          В ряде языков опечатки в декларации переменных (а не во всяком языке декларация вообще необходима) — это именно что «программная» ошибка (runtime error). См. тот же Javascript.

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

                          Тут можно поспорить о том, насколько имена переменных вообще относятся к синтаксису, но я не стану. Тесты же очень редко покрывают все ветки выполнения кода, поскольку их для этого нужно намного больше, нежели даже для 100% LOC покрытие кода (которое, в свою очередь, далеко не всегда встречается в реальных проектах).
                          • +1
                            У нас есть тема обсуждения — Vim, есть проблема с анализом кода. Диалог начался с обсуждения проблемы и похоже, что решение нашлось.

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

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

                            • +2
                              Суть моих комментариев можно свести к одному, что для каждого языка существуют родные или общепризнанные средства для работы с кодом (анализа, профилирования и пр.) и Vim никоим образом не усложняет работу с этими средствами.

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

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

                              Эта подветка началась с вашего комментария:
                              Брр… банальная опечатка в имени переменной может обнаружиться через месяц? Это как так? Это что за язык такой?

                              который к виму прямого отношения не имел, и посыл которого мне видится как «Да ладно, так не бывает». Я привел вам примеры подобных языков, вы мне сообщили, что в Perl синтаксический анализатор может отлавливать такие ошибки (по крайней мере часть подобных ошибок) и что думаете, что в других языках все так же, я привел контрпример, вы упомянули тесты, я вам намекнул, что нет гарантий того, что тесты поймают такую ошибку. Мне кажется, что усмотренный мною посыл вашего коментария наша дискуссия успешно опровергла.

                              Кроме того, теперь я чуть больше знаю о Perle, а вы — о языках, от него отличных.
                              • +1
                                Начнем с того, что в том же JavaScript наверняка есть возможность декларировать переменные, определять область видимости и пр., и скорее всего, это является хорошей практикой.

                                Так же, для JavaScript существуют анализаторы кода, и если переменные всё же объявлять, то они помогут исправлять подобные ошибки.

                                Я уверен, что для подавляющего большинства языков проблемы при работе в Vim — надуманны. Да, это может быть не привычно сперва, но не катастрофично.

                                PS: Что касается тестов, то как раз таки проблемные места и надо тестировать, а не писать тесты «что бы были», не правда ли?
                                • +1
                                  Не катастрофично — да, но эффективность кодирования падает, имхо. Необходимо же каждое сохранение анализировать, а не получать уведомления динамически, прямо в процессе набора/редактирования. не говоря о том, что обычно лучше ошибку предупредить, чем допустить, найти и исправить.
                                  • +1
                                    Я никогда не работал в IDE, по этому мне плохо понятно, как можно находить ошибки, которые обсуждаются в этой ветке, на лету.

                                    Подсветкой? Обсудили. А как ещё?
                                    • +1
                                      Находить или информировать? Если второе, то тултипы, статусы, панели, окна и т. п. А первое — проблема, по-моему будет в том, что IDE запускают свои анализаторы в ответ на практически каждое нажатие клавиши, изменяющие код, пользуясь, например, тем что полное синтаксическое дерево или что-то вроде него можно не перестраивать с нуля, только точечные изменения вносить…
                                • +1
                                  Начнем с того, что в том же JavaScript наверняка есть возможность декларировать переменные, определять область видимости и пр., и скорее всего, это является хорошей практикой.

                                  Да, есть. Нет, это не спасет от ошибок в рантайме.

                                  Так же, для JavaScript существуют анализаторы кода, и если переменные всё же объявлять, то они помогут исправлять подобные ошибки.

                                  Существую, да вот только толку от них мало. Вот вам пример:
                                  var e = {
                                    w : 10,
                                    getW: function() {
                                      return this.q; 
                                    }
                                  };
                                  e.getW();
                                  

                                  С точки зрения предложенной вами утилиты код не содержит ошибок (кроме жалобы на не-strict mode, использовать который себе дороже). Тем не менее, опечатка в имени свойства w в методе getW() очевидна. Но автоматизировать поиск таких ошибок очень и очень сложно в контексте яваскрипта — хотя бы потому, что getW() может быть вызвана с любым объектом в качестве this.

                                  Я уверен, что для подавляющего большинства языков проблемы при работе в Vim — надуманны.

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

                                  Что касается тестов, то как раз таки проблемные места и надо тестировать, а не писать тесты «что бы были», не правда ли?

                                  То есть вы не станете писать юнит-тесты для геттеров, правда ведь? А вот как раз в геттере в примере выше и есть опечатка.
                • +1
                  Lua, имеем код вида:

                  local foo = false
                  ffoo = true
                  
                  if foo == true then
                      print( "done!" )
                  end
                  


                  В данном случае просто создастся глобальная переменная ffoo и условие никогда не будет выполнено. И это нормальное поведение, но большинство более высокоуровневых редакторов помечают похожие ситуации.
                  • +2
                    Сценарии Vim пишутся на Lua, то есть с этим языком у вас вообще проблем быть не должно.

                    github.com/xolox/vim-lua-inspect
                    • +1
                      А вот за ссылку спасибо. Как-то мне до этого гуглились только кривые и нефункциональные плагины.
              • +1
                Ну вы же пишете на каком-то конкретном языке, а не на всех сразу. Начните использовать с разработки приложений, которые вы хорошо знаете.
  • +4
    41 комментарий и ни слова про Емакс. Так и будет тема без главного холивара.
    • +1
      Чёрт, обновлять надобно.
  • –1
    Написал бы кто-нибудь хорошую обучающую по нему статью…
    • +2
      Vimtutor вам поможет.
      • +1
        А мне не показалось хорошим. Я прошёл его давно, но выход от этого прохождения для меня близился к нулю. Начало нормальное, но тогда я базовые команды уже знал. Но вот дальше сразу паттерны, а не отдельные команды (в паттерны я потом и сам сложить 2+2 смогу). Например, описывается «ce», а не «c» отдельное.
        • +1
          Ниже объяснили, что обучающих статей много, а какую-то универсальную написать сложно по тому, что после vimtutor у всех пути расходятся. Другими словами, после vimtutor каждый начинает подстраивать работу с вим под свои привычки, какие-то внутренние правила и пр.
    • +3
      По Vim'у?!?!?!? Вы точно хотя бы попробовали поискать, прежде чем это писать?
      • +1
        Статей много, субъективно хороших — нет. Или, грубо говоря, повторение vimtutor, или список плагинов для тех или иных задач с непонятными словами типа cname. Статей, описывающих реальные практики для программирования в контексте того или иного языка, как-то мало.
          • +2
            О чём я и говорил. Инфа обрывочная или повторение туториала, а большая часть вообще не в виде статей, а флэша.
            • +2
              А можно пример того, что вы бы посчитали необрывочной инфой для любого другого языка/редактора? Просто чтобы понять, что именно вы ищете.
              • +3
                Я, скорее, об IDE. Как редактором я vim'ом пользуюсь, ну, как в винде пользовался Notepad'ом. Но вот туторила о том как превратить vim в подобие Notepad++ или того же SublimeText 2 не встречал. Вернее попытки встречал, но как-то они уровня описания плагинов, причем описывающих, что плагин делает (а-ля «более умное автодополнение для PHP чем стандартное»), а не как с ним работать («чтобы посмотреть список вариантов нажмите ...., чтобы включить файл в индекс наберите ...») и не как его установить и настроить. Не говоря об описании общего workflow работы с проектом от создания пустого под контролем VCS до подключения разных деплой/билд систем. В традиционных IDE это всё как-то интуитивно понятно, включая сам процесс установки плагинов. В vim'е же…
                • 0
                  Простите, но вы несете бред… всё это есть в куче туториалов и книг по виму… Сначала вы говорили, что нужны практики программирования и они нигде не описаны — я привел ссылки, они описаны там, причем по-моему очень даже хорошо. Теперь вы говорите, что нет учебников по настройке вима под язык и установке плагинов — это, мягко говоря, чушь собачья…
                  • +1
                    Реальные практики для меня, например, что и как нужно установить и что потом нажимать, чтобы перейти с названия типа в объявлении параметра к его декларации. Или как выделить блок кода в функцию или метод нового класса.
                    • +2
                      Установить ctags, сгенерировать файл тегов (man ctags), указать виму на этот файл (:help ctags), после этого — Ctrl+] или Ctrl+W ] (открыть в текущем окне, или в новом).
                      • 0
                        volch@home:~$ ctags
                        Приложение 'ctags' может быть найдено в следующих пакетах:
                         * exuberant-ctags
                         * elvis-tools
                        Попробуйте: sudo apt-get install <выбранный пакет>
                        


                        Что-то не то. Да и, мягко говоря, складывается ощущение, что перегенерация потребуется после каждого изменения имён в проекте.
                        • +1
                          cynovg@cynovg-notebook:~$ aptitude search ctags
                          v   ctags                          -                                           
                          i   exuberant-ctags             - составление индексов объявлений различных 
                          i A libparse-exuberantctags-perl    - exuberant ctags parser for Perl
                          
                        • +1
                          Что-то не то.

                          Да нет, как раз то. Вас интересует exuberant-ctags.

                          Да и, мягко говоря, складывается ощущение, что перегенерация потребуется после каждого изменения имён в проекте.

                          Теоретически — да. Но на практике (по, разумеется, моему ограниченному опыту) — хватает генерации раз в несколько дней. Занимает секунд 15-20 на дереве исходников в ~150тыс. строк и почти шесть тысяч файлов (сюда включены все используемые библиотеки). ctags также поддерживает дополнение базы, а процессинг одного файла происходит очень быстро (ну вы и сами можете прикинуть сколько, исходя из замеров выше).
                          • +1
                            хм, присмотрелся к выводу ctags — похоже, что он не игнорирует то, что я ему говорил игнорировать. Получается, что процессятся больше 13тыс файлов и чуть больше трех миллионов строк.
                • +7
                  Тут сложность в том, что подобный мануал будет о-очень сильно зависеть от используемых плагинов — и, стало быть, будет бесполезным для тех, кто использует другие плагины. Плюс, будет повторять документацию самих плагинов.

                  Второй момент заключается в том, что в отличие от привычных вам IDE в виме нет нужды проводить весь рабочий день. Что не умеет вим, дополняют другие утилиты. Вот, к примеру, возьмем юз-кейс «закоммитить часть измененнных файлов в свн». Что делает пользователь в «типичной IDE»? Ищет менюшку «Source Control/Commit...», выбирает чекбоксами файлы, возможно просматривает изменения в них, заполняет commit-message, нажимает кнопку «Commit». Первое, что я делаю в таком случае… выхожу из вима :)… и запускаю его снова, вот таким образом: svn st | vim — . Теперь, у меня в окне есть список всех измененных файлов (в виде обычного текста, вывода svn st). Я его редактирую, оставляя только нужные мне для коммита файлы. Далее на тех файлах, изменения в которых я считаю нужным проверить, я (в нормальном режиме) набираю \d (вызывая скрипт, который я написал для просмотра изменений). Открываются две панели (в терминологии vim — окна) в режиме diff, одна с базовой ревизией файла, вторая — с моими изменениями. Я просматриваю изменения, редактирую по необходимости и набираю Ctrl+W+K+W+O (или :q:q). Просмотрев изменения, я выбираю в визуальном режиме (режим, похожий на режимы блочной пометки в Norton Commander) список всех файлов, которые собираюсь закоммитить, и нажимаю \с (что запускает другой скрипт, который я тоже написал для себя). Сбоку открывается другое окно, с заполненным стандартным commit-message. Я его редактирую по необходимости, и выхожу с сохранением (:wq). После запроса подтверждения коммита коммит успешно происходит, вывод команды svn заменяет тот список файлов, что я выбирал перед созданием коммит-месседжа. Все, коммит готов, список файлов и вывод svn больше не нужны, выхожу без сохранения (:q!)

                  Смысл этой истории в том, что в ряде случаев нет необходимости тащить привычки из «обычных IDE» в vim. Да, наверняка есть плагины, которые добавят менюшку «Source Control / Commit...» — но пользоваться ею будет не удобнее, нежели в том же Eclipse. Для моего случая это значит, что вышеописанный юз-кейс выполнялся бы в несколько раз медленнее.

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

                  PS: (обращаясь к IDE) «Проект»? Какой, нафиг, «проект»? Уйди с дороги, чудовище, и дай мне редактировать мой код!
                  • +2
                    Для меня хорошая IDE реализует 3 функции именно при редактировании:
                    — автодополнение (крайне желательно контекстное, что называется интеллектуальное) по всему проекту и внешним (например в /usr/share) библиотекам
                    — навигация по проекту и внешним библиотекам, как по дереву, так и переходу к месту объявления, использования и т. п.
                    — рефакторинг

                    Наличие интеграции с VCS, системами билда и деплоя, тестовыми средами и т. п. не критично, всё равно чаще всего их игнорирую и использую консоль :)

                    Но вот понятие проекта нужно и не просто один каталог, а минимум возможность включать несколько, скажем, один из /home и несколько из /usr, плюс настройки тех же табов для каждого проекта и т. п. Возможно вы правы и подобного материала я не дождусь.
                    • +2
                      — автодополнение (крайне желательно контекстное, что называется интеллектуальное) по всему проекту и внешним (например в /usr/share) библиотекам

                      Есть такое, но степень поддержки разнится от языка к языку. Называется omni-completion. Дополнение по тегам (ctags), дополнение по файлам, дополнение по списку слов, встречающихся в открытых файлах — есть из коробки и работает хорошо.

                      — навигация по проекту и внешним библиотекам, как по дереву, так и переходу к месту объявления, использования и т. п.

                      Переходы к объявлению (ctags), к использованию (cscope) — есть, но зависят от степени поддержки языка указанными утилитами. Разнообразные Project plugins тоже есть, но про них ничего полезного сказать не могу, т.к. не пользуюсь. Настройки табов для разных проектов должны быть, как минимум это возможно через :mkview

                      Для некоторых языков есть встроенные в интерфейс вима дебаггеры (для PHP, например, — есть клиент для xdebug).

                      Встречал интеграцию с тикет-системами, например с trac — но использовать не получилось, наш trac был слишком старым и не поддерживал xml-rpc.

                      Интеграция с build-системами — в простейшем случае через :make, может есть и что-то сложнее. Интеграция с тест-системами — не уверен, как именно это должно выглядеть.

                      Рефакторинг — в зависимости от языка. Говорят, eclim умеет. Сам не пользовался, предпочитаю руками.
                      • +1
                        Дополнение по тегам (ctags), дополнение по файлам, дополнение по списку слов, встречающихся в открытых файлах — есть из коробки и работает хорошо.

                        Видел, но как-то оно очень неинтеллектуальным показалось (для динамических языков: PHP, Python, Ruby) — такое ощущение, что никакого синтаксического анализа не производится, просто слова предлагаются из общего списка вне зависимости от контекста.

                        Сам не пользовался, предпочитаю руками.

                        Очень много приходится рефакторить код без покрытия тестами (собственно для покрытия и приходится), а не заметить, например, использование глобальной переменной (одной из десятка) при выделении функции/метода в сотню строк проще простого :(
                        • +2
                          Видел, но как-то оно очень неинтеллектуальным показалось (для динамических языков: PHP, Python, Ruby) — такое ощущение, что никакого синтаксического анализа не производится, просто слова предлагаются из общего списка вне зависимости от контекста.

                          Тут зависит от типа дополнения, которое вы вызываете. Например, дополнение по тегам (Ctrl-X Ctrl-]) берет данные из tags database, которая в свою очередь была построена с помощью ctags, который как раз занимается очень простым синтаксическим анализом (не семантическим).
                          Дополнение по словам тоже удобно (если к нему привыкнуть), и позволяет достаточно удобно делать дополнение как раз в динамических языках, без лишнего оверхеда но, порой, требует от пользователя выбрать нужный вариант. Вот, например:
                          var old = true;
                          var a = {};
                          a[old ? "oldApiMethod" : "newApiMethod"] = function() {
                             // do something;
                          };
                          a.oldA//Ctrl+P легко дополнит здесь название метода
                          

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

                          Интеллектуальность и сложность IDE в виме заменяется на скорость самого редактора + интеллект/память пользователя + мускульная память.

                          а не заметить, например, использование глобальной переменной (одной из десятка) при выделении функции/метода в сотню строк проще простого :(

                          Не повезло вам с кодом, сочуствую. У нас глобальных переменных вообще нет (использование ключевого слова global запрещено на уровне pre-commit hook'а). Я бы в таком случае завернул для начала кусок кода в лямбду с вызовом ее в той же точке, отладил ее — при этом вам придется вынести все используемые переменные в аргументы лямбды/use() clause и, таким образом, построить список всех используемых переменных, — и уж потом бы выносил этот изолированный кусок кода. Доступ к глобальным переменным лучше сразу заменить доступом к суперглобальному массиву $GLOBALS — обращение к нему визуально намного проще заметить.
                          • +1
                            Предполагая, что речь шла о PHP.
        • +1
          Это не статьи но, очень просто и очень хорошо Derek показывает Vim и заражает любовью к этому редакотру 100%.
          • +2
            Зарядил когда-то, но хочется большего, а тут, грубо говоря, тот же vimtutor.
    • +2
      Это не статьи но, очень просто и очень хорошо Derek показывает Vim и заражает любовью к этому редакотру 100%.
  • –4
    Здорово, что вы и ваши коллеги достигли такого уровня мастерства владения vim. Но, многим людям, которые пользуются vim'ом много лет, хочется сказать «Слышь, мужик, не мучайся, возьми kate/Sublime/geany/mksv3...»
    • +10
      Дак скажите. А потом нам сюда сбросьте их ответы, вместе посмеёмся ;)
    • +8
      почему все время так много троллей в теме про вим?
      пользуюсь где-то с вимом с 2005 года.

      до сих пор не могу понять зачем мне переходить на kate/Sublime/geany/mksv3…
      • +4
        Я когда слышу как люди восхищаются тем, что научили сублим подсвечивать маркдаун и пр. вещи, просто ухмыляюсь. Бедные, что ж вы мучаетесь-то так.
        • +1
          Типа подсветка не нужна?
          • +2
            Нет. Просто vim из коробки поддерживает множество подсветок и автоматически их распознает. Список для 7.3.409.
            • 0
              Множество же не значит все?
              • +3
                Тем не менее поддерживается большее количество языков, нежели во многих других редакторах. Сравните 542 языка (из ссылки от hoxnox) с 48 языками в ST2
          • НЛО прилетело и опубликовало эту надпись здесь
            • +2
              Лично мне не важно, каким цветом будет выделен тот же while, достаточно того, что он просто выделен. Другими словами, я просто быстрее визуально разбиваю код на фрагменты, ну и спасает от банальных опечаток.
              • НЛО прилетело и опубликовало эту надпись здесь
                • +1
                  Вот задумался, вполне возможно.

                  Правда, у меня тут же всплыл ещё один пример с подсветкой: когда осваиваю что-то новое. Вот, на пример, пишу html-шаблоны для фреймворка. У фреймворка, понятное дело, собственный синтаксис и подключив эту самую подсветку я сразу вижу, что «нифига я тут не правильно написал». Лезу читать, почему не правильно, исправлять и всё такое.
                  • НЛО прилетело и опубликовало эту надпись здесь
  • +4
    Я, наверное, столкнусь с негодованием, но никак не могу взять в толк, как удобство набора/редактирования кода влияет на эффективность программиста? Или окромя меня все такие крутые программисты, что всю свою программу наперёд знают, осталось только забить её в редакторе и скомпилить?

    Напомнило известный скетч из сборника «Физики шутят»:
    Однажды вечером Резерфорд зашел в лабораторию. Хотя время было позднее, в лаборатории склонился над приборами один из его многочисленных учеников.
    — Что вы делаете так поздно? — спросил Резерфорд.
    — Работаю, — последовал ответ.
    — А что вы делаете днем?
    — Работаю, разумеется, — отвечал ученик.
    — И рано утром тоже работаете?
    — Да, профессор, и утром работаю, — подтвердил ученик, рассчитывая на похвалу из уст знаменитого ученого.
    Резерфорд помрачнел и раздраженно спросил:
    — Послушайте, а когда же вы думаете?
    • +7
      Всё куда проще: мы хотим сократить время набора кода до минимума, чтоб можно было больше времени тратить на обдумывание.
    • +1
      Ну, вы просто попробуйте написать несколько скриптов в notepade и поделитесь своими впечатлениями.

      Что бы начать работать в vim, достаточно пройти vimtutor, то есть это не так уж и много усилий. Уж точно на это понадобится меньше времени, чем на обсуждение «как удобство набора кода влияет на эффективность программиста» :)
      • +1
        Чтобы не «пипикал и всё не портил» этого хватит, но эффективность сильно не повысится. Примерно та же эффективность будет в Notepad++ или Sublime. И, то, субъективно для этого vim ещё придётся сильно допиливать, гугля на каждый чих типа «прикрутить build систему».
        • +1
          Vim упомянул по тому, что вопрос «как удобство набора/редактирования кода влияет на эффективность программиста?» воспринял в контексте статьи. Можно заменить на какой либо другой, более привычный редактор, суть не изменится.

          Пусть человек сравнит тот же Notepad и Notepad++ и поделится впечатлениями, влияет ли удобство на эффективность или нет?
    • +3
      но никак не могу взять в толк, как удобство набора/редактирования кода влияет на эффективность программиста?

      Примерно так же, как и удобное кресло, правильно подобранная высота стола и удобная клавиатура. Людям с уже приобретенными проф. заболеваниями оно позволяет заниматься любимым делом с меньшими мучениями, тем, кто еще таких болячек не заимел — позволяет дольше оставаться здоровыми.
  • +2
    Не люблю вимеров за слепую уверенность что тех фич что есть в виме нет в других редакторах или они (фичи) как-то менее удобней реализованы.

    Предлагаю челлендж.
    Вы мне фичу из vim — а я вам показываю как тоже самое сделать в Netbeans/Subime/PhpStorm.
    На каждую такую фичу я буду предлагать свою фичу которая есть в этих редакторах и по моему мнению отстутсвует в vim.

    Цель? Я хочу перейти на vim, но постоянно сталкиваюсь с тем что в нем чего-то нехватает или реализовано это сложнее (банально больше кнопок надо нажимать) чем в моем стационарном редакторе.
    Поучимся друг у друга, а?

    Ох щас нарвусь
    • +3
      Удалить 5 слов нажатием 3х клавиш (5dw).
      • +3
        Бессмысленная довольно фича, я считаю. Ну где вы при написании кода будете считать слова? Вы будете считать скобки, запятые, кавычки итд. А слова в коде — сущность не встречающаяся в чистом виде.

        Ну да ладно, phpstorm: shift + alt + (5 раз стрелка), delete

        Слишком редкая функция что бы считать количество нажатий клавиш.
        И да, вы не учли перехода в коммандный режим. (shift+:) итого 5. 5 против 7.
        • +1
          Переход в командный режим — одна клавиша esc.

          Однажды перейдя в командный режим, можно много раз удалить по N слов. Так что, не 5, а примерно 3.5 нажатия.

          И про осмысленность фичи:

          предположим у нас имеется список айпи-адресов через запятую (довольно частая штука, да ведь?). С помощью вима мы можем скакать по списку туда-сюда нажимая 8w или 8b (w — слово вперед, b — слово назад). Доскакав до нужного айпишника можно нажать 8cw, чтобы изменить его, или 8dw чтобы удалить.
          • +2
            Возможно мне просто с такими задачами не приходилось сталкиваться.
            Мой мозг при беглом взгляде не может сказать сколько тут адресов, и какой по списку 27.134.24.4:

            [192.168.1.1, 10.100.150.1, 33.14.134.13, 55.24.55.11, 27.134.24.4, 234.1.1.12, 77.55.112.1, 88.12.44.4]
            • +1
              Вимеры тоже не могут, поэтому для вима есть плагин который вам подсветит номер ;)

              Но вот например даже по той строчке что вы привели. Я очень часто использую фичи вида —
               * скопировать в буфер обмена целиком приведенный список. (3 нажатия)
               * скопировать в буфер целиком приведенный список не включая символы [] (3 нажатия)
               * удалить все адреса начиная с того на котором стоит курсор и до символа ]  (3 нажатия)
               * окружить список вместо [] тегами <pre>  (5 нажатий)
               * отправить этот список на pastebin и скопировать ссылку в буфер обмена (5 нажатий)
              


              (даже вот этот комент я пишу в виме который автоматически открылся у меня файрфоксом и он красиво подсвечивает мне вышеприведенный список )
              • +1
                Вы бы нажатия написали, иначе первый пример можно интерпретировать как то, что делает shift+end, ctrl+c.
                Кстати «окружить список вместо [] тегами
                 (5 нажатий)" - выглядит подозрительно, чтобы только набрать <pre> на обычной клавиатуре уже 7 надо.
                • +1
                  это я без набора тега, конечно )
                  Наврал кстати, можно короче cs[
                • +1
                  Прошу прощения — съелся тег.

                  cs[<pre>
            • +1
              Вы не внимательно прочитали мой коммент.

              Прикол в том, что нажав 8w — я перемещаюсь ровно на один айпишник вправо.

              На вашем примере: поставим курсор на «1» в адресе 192.168.1.1 и нажмем 8w: окажемся на символе «1» в следующем адресе (10.100.150.1) и так далее.
          • +2
            Ctrl + стрелочки, не?
            кроме того список айпи-адресов это скорее сисадминский юзкейс, для сисадминов действительно, лучше вима инструмента нет.
            • +1
              Так ctrl и 8 раз стрелочку же. А если хочешь отредактировать этот кусок — придется зажимать shift-ctrl.

        • +1
          Даже не 7 а 6, везде, где пробовал, работает сtrl+(del 5 раз).
        • 0
          вот тут есть примеры более жизненные, как мне кажется )
      • +1
        Так, моя очередь, задавать задания! )

        Автокомплит, я пишу:

        class a {
        }
        class b extends a {
        public function doSmth() {
        $this-> | хочу увидеть список методов доступных в текущей области видимости
        }

        }

        • +1
          Код вроде похож на PHP. Никогда на нём не писал, сходу сказать не могу есть ли для него плагин.

          Но вот для C++ есть OmniCppComplete:

          Features:

          — Complete namespaces, classes, structs and union members.
          — Complete inherited members for classes and structs (single and multiple inheritance).
          — Complete attribute members eg: myObject->_child->_child etc…
          — Complete type returned by a function eg: myObject->get()->_child.
          — Complete the «this» pointer.
          — Complete a typedef.
          — Complete the current scope (global and class scope).
          — Complete an object after a cast (C and C++ cast).
          — Complete anonymous types (eg: struct {int a; int b;}g_Var; g_Var.???). It also works for a typedef of an anonymous type.
          • +1
            Увы, для пхп с таким функционалом как OminCppComplete нет. Есть только автокомплит по списку кейвордов и стандартным функциям яыка
    • +2
      :sp — разделение экрана на фреймы, каждый фрейм относится к буферу, в свою очередь один и тот же файл может находиться в разных буферах.
      zf — 'fold' кода, т.е. сворачивание. Можно сворачивать не только по синтаксическим конструкциям, а вообще любой кусок кода.
      `` — вернуться к предыдущему месту редактирования.
      Для начала пойдёт.
      • +1
        Phpstorm: Window -> Editor tabs -> Split vertically, Split Horizontally (комбинация клавиш любимая биндится в настройках)
        Сворачивание кода: ctrl +, ctrl — Предыдущее место редактирования: alt + ctrl + -<
        • +1
          Я немного не в курсе как оно в phpstorm, но в vim можно делать split в любом месте произвольное количество раз. Уточняю лишь потому как в sublime text есть только заложенные стандартные лэйауты по которым экран можно пилить.
          Немного далее:
          ^wL — переместить текущий фрейм в правый край
          :q закрывает фрейм, но буфер к которому он прикреплен остаётся загруженным и вы можете его вернуть в любое время.
          p/P — вставить содержимое буфера после/до курсора. крайне удобно в режиме копипасты строк.
          Макросы очевидно есть везде — даже писать не буду, единственное что радует во время записи это как раз возможность перемещаться по смысловым блокам, т.е. по словам/абзацам, а не по количеству нажатией стрелки вправо/вниз, что делает их более реюзаемыми.
          • +1
            Сплит да, можно делать где угодно и любое количество раз.

            Перемещение фреймов — не нашел :(
            Закрыть фрейм с созранением буфера — нет понятия буффер. Так но понятное дело закрыть можно комбинацией клавиш. Файл будет сохранен автоматически.
            • +3
              Я вам главного удобства режимов редактирования не рассказал.
              Как правило во время навигации в файле и необходимости ввести какой-то код, вам нужно сначала позиционировать курсор на нужном месте. Так вот в vim'е есть возможность начать редактирование сразу в необходимом месте:
              A — начать редактирование, установив курсор в конце строки.
              a — тоже самое но после текущего символа.
              o — добавить строку ниже текущей и начать на ней ввод
              O — тоже самое, но добавляет строку до текущей.
              • +2
                Честно говоря, это не самый сильный аргумент.

                Даже по сравнению с notepad:

                A = end
                a = ничего. просто начинаем писать.
                o = end enter
                O = home enter

                просуммировав получим 6 нажатий в случай вима, и 6 в случае блокнота (ведь A и O это на самом деле shift-a и shift-o).
                • +2
                  Нам ведь уже очевидно что на сложных операциях vim требует меньше нажатий чем блокнот, теперь мы убедились что на простых операциях он требует столько же нажатий как и в блокноте. Неплохой показатель, право же.
                  • +1
                    И пальцы не надо до home/end тянуть.
                    • +1
                      Да, предлагаю в следующий раз как будем подсчитывать нажатия, всякие F1/F2...F12/PgDn/PgUp/Ins/Home/End считать за два нажатия, т.к. реально трудозатраты на их нажатия весьма велики по сравнению с буквенным блоком клавиатуры.
                      • +2
                        И возможность использования мини-клавиатуры. Типа такой (реально работаю на ней сейчас):

                        image
                        • +1
                          А вот и моя:
                          image
                          Microsoft arc, если что.
                          • +1
                            Я свою взял рублей за 400 в порядке эксперимента специально под вим. Два месяца — полет нормальный. Если за полгода туннельный синдром не разовьется — подумаю об апгрейде до модели вроде вашей.
                            • +2
                              Я вам по секрету скажу что я печатаю на двух клавиатурах. Правая рука на клавиатуре ноутбука, левая на этой. Между ноутбуком и второй клавиатурой стоит большой монитор.
                              На туннельный синдром даже намёка нет ;)
                      • +1
                        Тогда нужно учесть что запоминание End для перемещения в конец чего-либо требует меньше трудозатрат чем A.
                • +1
                  Кажется почти никто не понял сути комментария.
                  Поясняю: оверхэда на переключение между режимами практически нет, если переходить в них наиболее подходящим контексту образом.
              • +1
                ST2:
                A = ⌘+→
                a = просто символ
                o = ⌘+Enter
                O = ⌘+Shift+Enter
                • +1
                  А что это такое -> ⌘
                  • +1
                    Особая маковская кнопка.
                  • +1
                    Аналог Win-кнопки на маках. Используется аналогично Ctrl в других системах.
          • +1
            вставка до/после курсора, — реализуется макросом
      • +1
        Моя очередь! )

        — проверить и выделить ошибки в коде на основе JSLint/phpcs
        — Отделить цветом файлы по категориям, например покрытые тестами — зеленые, непокрытые — красные, вне проекта — желтые
        — в css-файле дополнение по имени файла для свойств background относительно DocumentRoot
        • +2
          — проверить и выделить ошибки в коде на основе JSLint/phpcs

          :help makeprg
          :make
          :cc

          — в css-файле дополнение по имени файла для свойств background относительно DocumentRoot

          :cd $DocumentRoot
          Ctrl-X Ctrl+F

          Хотя в CSS, если мне не изменяет память, куда актуальнее дополнение путей относительно положения самого файла CSS.
      • +1
        вернуться к предыдущему месту редактирования

        А кто может подсказать как такое же сделать для «Sublime Text»?

        А то перешел на него с NetBeans, и чувствуется некоторый дискомфорт по хоткеям.
        • +1
          Судя по описанию «soft undo; jumps to your last change before undoing change when repeated» Ctrl+U должно делать то, что вам нужно.
          • +1
            Спасибо, что ответили. Но CTRL+U работает аналогично так же как и CTRL+Z. Т.е. происходит откат того, что писал ранее.

            Я вышел (насколько это можно назвать) из положения установкой плагина.

            Navigation History

            Почему то думал, что такие явные вещи должны быть из коробки, нативно.
    • +1
      Боюсь это затянется… сейчас у каждого найдется что-то своё! =)

      У меня сходу — это возможность работы из текстового терминала без потери функциональности. Отсутствие необходимости тыкать мышкой.
      • +2
        Отсутствие необходимости работать мышкой не фича, а отсутствие необзодимости, не находите? :)
        Возможность работы из текстового терминала не относится к фиче «редактора». А к фиче «программы».
        Мы же сейчас о редакторах говорим а не абстрактных программах. Иначе скатимся в обсуждение графика vs консоль. А это не то о чем хотелось бы поговорить.
        • +2
          Тогда следует определиться с понятием «фича». Для меня возможность работы без мышки — фича. И возможность работы без X-ов фича… Почему вы разделяете понятие программы и редактора? Редактор и есть программа.
          • +1
            Пытаясь быть объективным я считаю это не фичей а «особенностью». Потому что для некоторых людей работа без мышки будет недостатком.
            • +3
              Да будет вам известно, что если перевести слово «feature» на русский, получится «особенность», а «особенность» переведенная на английский — «feature».
        • +1
          Вроде все известные мне редакторы не требуют мыши для работы. На любое действие можно забиндить сочетание. В крайнем случае Alt/F10 и в меню.
          • +1
            >На любое действие можно забиндить сочетание.
            Не хватит терпения и сочетаний. =)

            >В крайнем случае Alt/F10 и в меню.
            А это уже не работа.
            • +1
              В виме же хватает? )
              • +1
                Фишка в том, что там не только сочетания. Еще режимы и командная строка. В которой всегда работает команда ":h <что я еще не знаю>" с автодополнением!
      • +1
        >> Боюсь это затянется… сейчас у каждого найдется что-то своё! =)

        Ну так поэтому и был написан этот комментарий. от каждого по «своему», каждому по «моему». Я считаю отличный способ обучения.
        • +1
          Мне достаточно того, что я могу править любые текстовые файлы на любой *nix-машине без всяких там предварительных действий. По этой же самой причине не занимаюсь никакой адаптацией и «тонкой настройкой», а пользуюсь тем, что предоставляется по-умолчанию.
    • +1
      Вы мне фичу из vim — а я вам показываю как тоже самое сделать в Netbeans/Subime/PhpStorm.
      <cheat mode>На сервере без иксов по ssh отредактировать файлик =))</cheat mode>
      • +1
        )) Ну я уже говорил, это фича программы а не редактора.
        • +1
          Ладно, вот вам другой юз-кейс — сравнить конфиги на двух серверах, доступных по ssh, в режиме split-screen, по необходимости синхронизировать некоторые изменения.

          vim:
          :e scp://user@host//path/to/file
          :vsplit scp://user@anotherhost//path/to/file
          :diffthis
          Ctrl+W h
          :diffthis
          
          • +1
            Я не в коем случае не приуменьшаю возможности вима в этих вопросах, но в топике все таки шла речь о «написании кода».

            В этом случае я открою консоль, сделаю scp file1, scp file2 и открыв их в редакторе начну смотреть разницу.
            Да мне прийдется залить их после редактирования.

            Но я хотел услышать юз-кейсы программистов которые пишут какие-то проекты большие, классы, функции, тесты, вот это вот все.

            При всем моем уважении, я не знаю ниодного пхп-девелопера который правит сравнивает конфиги по SSH на удаленных серверах.
            • 0
              Теперь знаете:)
            • +1
              При всем моем уважении, я не знаю ниодного пхп-девелопера который правит сравнивает конфиги по SSH на удаленных серверах.

              DevOps — это модно и современно. И да, несмотря на автоматизацию конфигурации и развертывания, проконтролировать, что там puppet намудрил, иногда полезно.
      • +1
        Пфф. ssh -X. я так с чужих компов по ssh сидел в firefox'е.
        • +1
          Там же написано «без иксов».
          • +1
            Так для этого нет необходимости иметь иксы на сервере.
            • +1
              Окей, я наверное что то не понял, потому что никогда так не делал.
            • +1
              На x-клиенте нужно иметь программу, которая умеет общаться по x-протоколу, и иксовые библиотеки.
      • +1
        sshfs
    • +2
      Заменить текст от курсора до первой «;» в текущей строке: cf;
      Удалить текст от курсора до первого вхождения WHATEVER: d/WHATEVER ввод. Оно же до парной скобки/кавычки (когда курсор на такой же): d%
      Подсветить/искать текущее слово: #
      • +2
        > Заменить текст от курсора до первой «;» в текущей строке: cf;
        в большинстве случаев; надо оставлять и тогда лучше использовать ct;
    • +1
      Вы уж выберите какой-то один редактор, а то лезть за каждой функцией в новый редактор, это намного дольше выйдет.

      А так игра мне нравится. Допустим, есть код: column_for_attribute(name) && (pk_attribute_allowed || !pk_attribute?(name))

      Курсор находится внутри крублых скобок, в виме заменить содержимое — ci(
      Заменить вместе со скобками- ca(
      • +1
        Жмем сколько надо сtrl+w (расширяет выделение последовательно от слова до блока кода), затем ctrl+v (ну из буфера вставить) или прям набрать чотам.
    • +1
      Есть ещё «нет — значит не нужно, нужно — напиши сам» :)
    • +1
      А можно я еще с Emacs к вам присоединюсь? как насчет психоаналитика, или gomoku например? (=
      • +2
        ещё Тетрис и adventure, без них на работе никак, да :)
    • +1
      Народ, помогайте, а то работать надо ) Попозжей я отвечу всем кому не ответил.
    • +1
      Вот список. Повторите в упомянутых IDE.
      • +1
        Список большой, давайте вы отберете несколько, потому что некоторые откровенно легко делать. Я могу их выбрать и показать, но так будет не совсем по правилам. Я же предложил челлендж.
        • +1
          Можете выбрать любые. Вы же затеяли челендж. Предположу, что Вы хотите убедиться/убедить кого-то, в том, что «не такой уж vim и крутой». Занимайтесь. Мне это не интересно. Я спокойно сплю, используя «не самый крутой» vim, установленный на «отстойной» ubuntu (с «ужасной» unity) и пишу в нем php-код, который, как все знают, «говно».
          • +1
            Вы все придумываете. Я цели описал в первом сообщении.
            • +1
              Цель? Я хочу перейти на vim, но постоянно сталкиваюсь с тем что в нем чего-то нехватает или реализовано это сложнее (банально больше кнопок надо нажимать) чем в моем стационарном редакторе.
              Поучимся друг у друга, а?


              Если у Вас действительно цель перейти на вим и Вы сталкиваетесь с какими-то проблемами, то, возможно, Вам стоило бы их озвучить, нет? А так, начав этот челлендж, Вы получите кучу, возможно и крутейших демонстраций фич вима, но которые Вам не сдались.
    • +1
      1. Выровнять блок текста такого вида:
      |Заголовок|Тест|
      |Один|Два|
      

      в такой вид:
       | Заголовок | Тест |
       | Один      | Два  |
      


      Или

      var a=3;
      var b_var = 43132;
      


      В такой:

      var a     = 3;
      var b_var = 43132;
      


      В Vim, при использовании плагина, разумеется, это выделение блока текста V2j, а затем :Align | в первом случае и :Align = во втором.

      2. Поменять местами две колонки №2 и №3 в следующей таблице

       | Один | Два | Три |
       | Один | Два | Три |
      


      Вот так:
      
       | Один | Три | Два |
       | Один | Три | Два |
      


      В VIM это ctrl+v, выделить колонку №2, вырезать её (x), встать курсором в правый верхний | и нажать p
      • +1
        1) Выравнивание кода:
        Выделить блок.
        Пункт меню Code -> Reformat Code

        2) Колонки:
        Выделение колонки через «alt». ctrl+x.
        Далее также через alt выделяем область вставки. ctrl+v.

        Выравнивание текста увы нет. Но опять же, программистам редко это делать приходится, в основном таки код.
        • +2
          Этот текст — таблицы из Cucumber. Без выравнивания их невозможно читать.
          ""
          Хорошо, далее

          1. Удалить текст под кавычками. VIM: di"
          2. Обрамить b+c в скобочки в выражении a+b+c+20. VIM: fbvfcS"
          3. Перейти на строку №1234. VIM: 1234G
          4. Отсортировать выделенные фрагмент. VIM: выделить и :sort
          5. Применить к выделенному фрагменту любой внешний обработчик. VIM: выделить и :!uniq -c, на примере команды uniq.
          6. Проверить синтаксис на неподдерживаемого языка, например, GAP. VIM:

          syntaxchecker + небольшой код, который легко написать:
          function! SyntaxCheckers_gap_GetLocList()
              let makeprg = 'sh '.shellescape(findfile("bin/make_gap", &rtp)).' '.shellescape(expand('%'))
          
              let errorformat = '%ESyntax error: %m in %f line %l'
          
              return SyntasticMake({ 'makeprg': makeprg, 'errorformat': errorformat })
          endfunction
          

          • +1
            1. Жмем ctrl+w до тех пор пока не выделится нужный блок. Сначала выделится слово. Потом по ширине блока ограниченого скобками, кавычками итд. Затем delete
            2. выделение мышкой, символ нужной кавычки.
            3. ctrl+g -> 1234
            4. Реализуется макросом.
            5. И снова макрос.
            6. Для всех языков есть плагины. Если чесно пока не встречал не поддерживаемого.
      • +1
        Моя очередь,

        — сделать изменения в строке, посмотреть разницу и предыдущую версию скопировать в буфер обмена.
        — Переместиться по файлу к следующему/предыдущему изменению
        — сгенерировать базовый phpdoc по аргументам функций
    • +1
      Задача: Нужно из текста надёргать кусочков и потом куда-то вставить.
      В Vim для этого используются именованные буферы обмена с возможностью добавлять в буфер.
      Т.е. первый кусочек мы копируем в буфер с помощью "ay, следующие с помощью "Ay. Потом вставляем куда нужно "aP.

      Ещё фича: история вырезанных кусков текста. Хотя это скорее всего должно быть в приличном редакторе, но на всякий случай.
      В Vim "0 — "9.
      • +1
        В phpstorm: shift+ctrl+v (paste from history)
        • +1
          А первая задача?
  • +1
    После этапа «Vim» у меня был этап «Тайловый оконный менеджер» (awesome)… Что дальше?
    • +1
      links и mcabber, наверное.
      • +1
        Нет, links и mcabber — это после vi и dwm. А тут светят luakit и weechat.
  • +3
    Поработав немного в VIM, ST2, и парочкой больших IDE, я понял, что редактор надо выбирать исходя из его возможностей помогающих ускорить реализацию конкретной задачи, а не кол-ва шорткатов на все случаи жизни. VIM конечно крут, и писать код в нем можно очень быстро, но ровно до тех пор, пока под конкретный язык есть плагины\бандлы, в противном случае он превращается в обычный бесполезный блокнот.

    VIM, как и любой редактор, это просто инструмент, и очень глупо пытаться допилить его под все. Напоминает картинку с батоном и троллейбусом. Так, например, для Ruby, PHP и т.п. VIM идеальный вариант, особенно для веба. Есть и куча плагинов, и на серваке всегда можно что-то быстро подправить. А вот например для разработки на C#+Silverlight под Windows Phone 7, VIM не самый лучший вариант, как его плагинами не обвешивай, продуктивности вряд-ли прибавится.
  • +1
    А я светлый фон использую) Чтоб не было большой разницы между яркостями рабочего стола с vim и рабочего стола с браузером)

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