Vim и IDE — это разные вещи

Увидел очередную статью про vim и IDE и решил поделиться своими мыслями — вдруг кому-то покажутся полезными, чем черт не шутит?..

По сути, статья будет развернутым пояснением идеи, высказанной другим пользователем в комментарии к статье «VIM: зачем, если есть IDE, и как?».
Принципиально IDE от редактора отличается тем, что IDE оперирует синтаксическим деревом редактируемого кода на целевом языке (или неким к нему приближением), а редактор оперирует символами и строками.

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

IDE


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

Как пример можно рассмотреть проект Roslyn и Visual Studio. Про него можно прочитать в одной старой статье — Введение в Microsoft «Roslyn» CTP.

Цитата из статьи Введение в Microsoft “Roslyn” CTP
В прошлом наши компиляторы работали как черные ящики — вы подаёте на вход исходный текст программы, а на выходе получаете сборку. Все знания и информация, которую формирует компилятор выбрасывается и недоступны для чьего-либо использования.

Как пишет Soma в своём блоге, часть Visual Studio language team работает на проектом, который называется Roslyn. Его главная цель — переписать компиляторы C# и VB и создать языкове сервисы в управляемом коде. С чистым, современным и управляемым кодом наша команда сможет быть более продуктивной, внедрять инновации быстрее и выдавать больше возможностей скорее и с лучшим качеством.

Более того, мы открываем компиляторы C# и VB со всей их внутренней информацией, делая доступным для вас анализ кода. Мы предоставляем публичное API и обеспечиваем точки расширения в языковых сервисах C# и VB.

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


Если кратко, то Roslyn — проект, дающий API для компилятора. И это позволяет IDE «понимать» язык программирования так же хорошо, как это делает компилятор.

Vim


Задача vim — редактирование текста. Все. Точка. Серьезно. И сейчас я поясню, что имею ввиду.

Основная «фишка» vim'a — «понимание» элементов текста: слово, строка, предложение, абзац и т.д. Vim на самом низком, простом уровне заточен под работу с текстом. Просто попробуйте поработать в vim без дополнений и даже без подсветки синтаксиса. Уверяю, это будет незабываемый опыт.
Кажется, что-то подобное звучало и в вебинаре Hexlet про vim: www.youtube.com/watch?v=79OWQ1qJwto.

Но в этом же кроется и основная трудность освоения vim — вам приходится думать в терминах, в которых работает vim. Для IDE это не проблема — мы изучаем язык программирования, мы работаем в тех же терминах, что и IDE. Для vim это не очевидно. У меня ушло некоторое время для того, чтобы поменять свои мысленные направляющие. Раньше я думал:

Надо перейти к этой строчке или к этому месту в коде. И мышкой ставил курсор в нужное место. Теперь это выглядит чуть по-другому:

Надо перейти к этой строчке. Хм… К ближайшей сточке с объявлением публичного метода. /public
Удалить три слова 3dw

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

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

Можно еще много написать про возможности, но это статья не про «плюсы» vim'a, поэтому перехожу к заключению.

Вместе


У читателя наверняка родился вопрос: а зачем же тогда все эти плагины для vim? Если это не его задача?

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

Вы можете пойти трудным путем и попытаться сделать IDE из vim'a. Можете пойти более простым путем и добавить часть возможностей vim'a в свою любимую IDE. Или можете пойти самым простым путем — не использовать vim. Использование vim дает дополнительный «режим» работы — когда с кодом удобнее работать как с простым текстом.

Выводы


Я хотел подчеркнуть, что IDE и vim — это разные инструменты для разных задач, и их противостояние заключается лишь в том, что нет идеального варианта интегрировать эти два инструмента.

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

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

    +1
    > Удалить три слова 3dw
    проблема в том, что удаляете вы не слова а термы языка, и как то не комильфо смешивать 2 разных парадигмы.
    Вам просто повезло что 3 слова в редакторе = 3 термам языка. Попробуйте редактировать код на брайнфаке. Я думаю IDE и для него можно сделать с подсветкой :)
      0
      Просто уже давно есть IDE, в которые отлично интегрирован vim (например, Qt Creator). Хочешь юзай, хочешь нет.
        –6
        Единственная IDE операционная система, в которую отлично интегрирован vim — это emacs. Все остальное — жалкие подделки.
          +3
          Я пробовал — «жалкое подобие левой руки».
            0
            Дополню себя — я говорил об Evil (an extensible vi layer for Emacs). Это самый полный из эмуляторов вима, который я видел. Я бы сказал, что они близок процентов на 98 к оригиналу.

            Таким образом можно получить редактор, совмещающий лучшее из двух миров. Emacs добавляет:
            — расширяемость на стероидах (привет elisp вместо vim script)
            — асинхронность
            — org-mode

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

            Для желающих почитать/посмотреть на тему
              +1
              Использую я эту вундервафлю… уже пилю свою конфигу около года. Не достиг похожести даже на 80%. Одна из проблем — dired у него свои хоткеи, у nerd_tree свои. Так и получается, что юзая vim держишь один набор хоткеев, юзая vim и evil уже держишь 2 набора хоткеев. И так для каждого плагина. В итоге при работе больше думаешь о том, как запилить себе бинды, а не о программинге. Так что evil у меня только для org-mode, а программлю я все равно на vim.
                0
                Мне удалось перенести все используемые плагины и полностью переехать недели за 2 (тратя где-то в среднем по 30 минут в день).

                Не использую nerd_tree/dired, но в чем проблема у последнего переопределять все хотели и сделать их как в nerd_tree? Либо, если там совсем отличается воркфлоу, то просто выучить новый?

                Возможно вам нужно использовать одновременно и vim, и evil? В таком случае синхронизация конфигов действительно будет головной болью. Я могу полностью перейти на емакс — редактор нужен только на моей рабочей/домашней машине, никакого редактирования по ssh.
        +2
        > На мой взгляд, лучшим решением было бы, если бы IDE и редактор текста были бы отдельными модулями, взаимодействующими через некое API (как это сделано между IDE и компилятором Roslyn). Чтобы в IDE можно было бы встроить любой редактор, наиболее подходящий для работы с текстом.

        eclim примерно это и делает. Хотя тот еще франкенштейн.
          0

          Прикручивали, кстати, eclim к VIM? Работает?

            0
            Он именно к vim изначально и прикручивается и у меня оно заработало. Но я пошел еще дальше и у меня emacs с evil-mode и в нем emacs-eclim. И тоже работает.

            Для java и android я даже действительно этим пользовался (потому что что с чистым eclipse, что с android studio у меня получалась не работа, а война). Для чего-то другого (питон, си) пока не пробовал.
          0
          Вот правильное завершение холивара ) Конечно, он не завершится, но очень сильный аргумент в нём.
            +2
            Под очень сильным аргументом вы подразумиваете то, что автор перепутал «задачу редактора» и «все есть из коробки»?
            +4
            vim прекрасно справляется и с подсветкой синтаксиса и с подсветкой синтаксических ошибок. Писать код с использованием vim вполне себе нормальное занятие, и чаще это просто дело привычки.

            Однако vim это действительно не IDE: vim не знает ничего кроме синтаксиса, и понятия не имеет, например о содержимом структур данных и классов, и соответственно не в состоянии валидировать семантику. Современная IDE должна уметь это делать, и должна определять доступность классов и объектов в контексте редактируемого кода. Да почему современная? Древние Borland-овский Turbo Pascal и Turbo C из конца 80-х прошлого века умели это делать. vim не умеет. А также не забываем о сторонних фреймворках используемых в Вашем проекте, знания о которых у vim просто быть не может.

            Для небольших проектов (до 10-15 фалов), я например, продолжаю использовать vim, т.к. вполне в состоянии удержать информацию такого объёма в голове. И в таком случае продуктивность использования vim выше чем IDE. Как только объём информации необходимой для работы с кодом становится таким, что я начинаю забывать детали реализации в каком либо из классов, или суммарная информация о проекте не умещается в моей голове, я перевожу проект на любимую IDE (NetBeans).

              –2
              Современные IDE, к примеру QtCreator 4, студии под рукой нет, к сожалению, но думаю и там тоже, умеют делать такие трюки, как выведение типа auto для С++, хотелось бы посмотреть на плагин к текстовому редактору, который это сумеет :)
                0
                неужели нельзя сделать аналогичный плагин на основе какого нибудь llvm?
                  +2
                  clang_complete или ycm. Я предпочитаю последний.
                    –1
                    я даже больше скажу, такой плагин существует и для самого Qt Creator. И, ЕМНИП, он будет включен по умолчанию, когда решатся проблемы с производительностью. С точки зрения архитектуры это ничем не отличается от vim+ycm. Интересно, каким образом можно пользоваться Qt Creator и не знать о таких вещах.
                    +4
                    YouCompleteMe использует clang для автокомплита. И так же поддерживает clang CompilationDatabase
                      0
                      Спасибо, попробую!
                    +6
                    Автор начал о возможностях двух редакторов, а закончил про «из коробки». Эхх… Откуда же вы лезите?
                      0
                      Все с чего начинают и чем — то заканчивают.
                        0
                        Только вот на хабре принято начинать, аргументировать и заказчивать одну мысль.
                      +1

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


                      К сожалению, ничего сверх процитированного


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

                      почерпнуть из текста не удалось :(


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


                      Жду вот такого материала.


                      А разоблачения в стиле "VIM — редактор текста", и "голый VIM малопригоден для программиста, в то время как в IDE анализатор кода!!!". Ну право слово, даже обидно как-то.

                        0
                        почерпнуть из текста не удалось

                        И не удастся. Авторы подобных статей когда нибудь поймут, что один редактор от другого может отличаться только наличием или отсутствием плагинов. Нет там больше никакой особой магии apple.
                          0
                          Delphinum, магии действительно нет, но разница (принципиальная) есть. поправьте меня, но vim же не может графику.

                          Vim — нормальный текстовый UI для работы с тем, что можно представить в виде текста. Типа да «текстовый редактор», но «текст» — не в смысле «чо-то там типа на каком-то языке, где есть абзацы», а в смысле данные в текстовом формате, последовательности печатных символов. Если кому-то не нравятся абзацы и естественный язык, а нравится что-то другое, то пусть прикручивает clang или roslyn или libxml2. Т.е. имхо в реальности у vim есть (а может и был. я по событиям ~5летней давности говорю) всего один фатальный (для тех, кому это важно, в т.ч. для меня) недостаток — он чисто текстовый, т.е. открыть firefox или построитель графиков внутри какого-то окна внутри, скажем, gvim нет возможности.
                            +1
                            но vim же не может графику

                            Смотря что подразумивать под «мочь графику».

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

                            открыть firefox

                            А в чем проблема открыть firefox из vim?

                            построитель графиков внутри какого-то окна внутри, скажем, gvim

                            Вызывайте какую нить системную тулзу, типа display и радуйтесь.

                            что можно представить в виде текста

                            Совершенно так. Народ сравнивает две кружки так, как будто это кружка и слон. Нет, текст, с которым работает Vim и текст, с которым работает IDE это одно и тоже. Вот если бы IDE работали с диаграммами, а Vim с текстом, то это уже была бы принципиальная разница. В общем да, я согласен с вами.
                              0
                              >мочь графику
                              всмысле GVim может только текст, все что он может показывать — это viewports of text buffers (что собственно естественно и нормально). А IDE (которые не Vim) вполне могут внутри себя и графику. Например, IDE могут диаграммы (т.е. понятно, что чаще всего не IDE сами могут, а интегрированные сторонние приблуды могут), но вот в Vim графику (так чтоб графические приблуды было интегрировать в Vim средствами самого Vim) интегрировать нельзя.

                              >А в чем проблема открыть firefox из vim?
                              не «из», а «внутри». Хотелось держать стороннюю графическую прогу внутри одного из тех окон, которые «сtrl-w» (viewports of text buffers). Я сейчас подробностей не вспомню, т.к. этим вопросом не я занимался, но почему-то хотелось это делать именно внутри и средствами GVim (и почему-то не хотелось это делать средствами системы), какая-то причина была. Но, понятно, что на GVim за это никто не в обиде.

                              >Вызывайте какую нить системную тулзу, типа display и радуйтесь.
                              требовалось рисовать именно внутри Vim.

                              >Нет, текст, с которым работает Vim и текст, с которым работает IDE это одно и тоже.
                              факт!
                                0
                                но вот в Vim графику

                                Вам стоит больше беспокоится о синхронности Vim, а не об этом, поверьте )
                                  +1
                                  Как вам уже сказали: браузер и графика в Vim — это не Unix-way. А для такого ворклфоу, как описываете вы, хорошо подходят тайлинговые менеджеры окон. Тогда получается, что всё что надо живёт в своих тайлах и переключаться между ними удобно и быстро.
                                    0
                                    спасибо за совет, уточнения:
                                    1) это было 5 лет назад
                                    2) 5 лет назад это решилось переездом на Emacs, т.к. в Emacs можно и текст и графику.

                                    >тайлинговые менеджеры окон
                                    а под виндой это будет работать? я просто из любопытства спрашиваю, вопрос вообще не стоит.
                                      +1
                                      т.к. в Emacs можно и текст и графику

                                      И кофе он варить умеет, и вообще это тайный проект Столмана по разработке свой собственной ОС. Знаем )
                                        0
                                        Про винду сказать не могу — не пользуюсь. Но вот что есть на reddit: https://www.reddit.com/r/windows/comments/2rn775/best_tiled_window_manager_for_windows/
                                    0
                                     Нет, текст, с которым работает Vim и текст, с которым работает IDE это одно и тоже.

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


                                    Вот если бы IDE работали с диаграммами, а Vim с текстом

                                    Vim работает с текстом, IDE — с абстрактным/конкретным синтаксическим деревом, полученным из этого текста.

                                      +1
                                      Соответственно, довольно существенная разница заключается в накладываемых представлением ограничения на возможные операции с этим текстом

                                      И это вопрос уровня плагинов. IDE включает в себя плагин синтаксического анализатора и плагины на его базе, Vim такого плагина в себе не включает. Вся разница в этом, не нужно больше ничего придумывать от себя, как автор этой статьи, про некие «задачи» или «различные инструменты». И то и другое, это всего навсего редактор текста.
                                      Vim работает с текстом, IDE — с абстрактным/конкретным синтаксическим деревом, полученным из этого текста

                                      Повторюсь, и то и другое работает с текстом. Некоторый плагин в IDE позволяет ей этот текст представить в виде дерева с контекстными связями. Повторите этот плагин в Vim и он станет IDE. Другими словами Vim это редактор, IDE это редактор + плагин. В сравнении двух редакторов «с» и «без» плагина не вижу вообще никакого смысла, особенно разводить на этой почве холивар. Это разный функционал.
                                        –3
                                        IDE включает в себя плагин синтаксического анализатора

                                        Да? Тогда этот плагин должен быть опубликован на plugins.jetbrains.com|Eclipse Marketplace|plugins.netbeans.com

                                          +1
                                          Кто это такое необычное требование выставил JetBrains?
                                            0

                                            Конкретно JB даже платные плагины публикует у себя в галерее. Соответственно, логично искать «плагин синтаксического анализатора» именно там.

                                              0
                                              не все плагины публикуются — некоторые идут строго в сборке (bundled-plugins)
                                                0

                                                это да, однако я уверен, что «плагин синтаксического анализатора» отсутствует и среди них

                                                  0
                                                  ну, он может ещё быть как неотключаемый плагин ядра (читайте «модуль»), тогда вы его не увидете в списке плагинов.
                                                  А так, есть же статический анализ кода: flexible static code analysis, который, как я понимаю, лежит в библиотеке openapi.jar

                                                  ЗЫ: а вообще, думается человек просто описался говоря «плагин» — в остальном же правильно сказал
                                                    0
                                                    думается человек просто описался говоря «плагин»

                                                    Нисколько, я всего навсего пытаюсь просто и понятно излагать свои мысли, так как читать это будем не только мы с вами, а мыслить в контексте плагинов редактора, а не в контексте функционала ядра, многим проще.
                                                0
                                                Давайте назовем это не плагином, а «функционалом», так, возможно, вам станет понятнее о чем я говорю.
                                  0
                                  Чтобы IDE делало рутинную работу за вас и т.п.


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

                                  Автодополнение с учётом контекста.
                                    0

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


                                    Моё мнение, нужны не общие слова (вроде тех, что вы привели), а конкретные примеры для конкретных языков, где <ФИЧА> не работает или работает плохо в VIM, работает отлично в IDE, и где объяснено, почему <ФИЧА> — это очень полезная вещь, и как она ускоряет/облегчает процесс разработки.

                                      0
                                      Сейчас не буду настраивать vim для PHP, но года три назад я не мог банально перейти по имени класса в конструкции типа $obj = new SomeClass(), если SomeClass существовал в каталоге проекта не в одном экземляре, а в нескольких (с разными неймспейсами). Куда перейти однозначно определялось кодом в каталоге проекта, никакой неоднозначности не было, если знаешь о том, что конструкции языка namespace и use изменяют области видимости.
                                        0
                                        Да и сейчас вам это нормально не удастся.
                                          0
                                          Почему-то не удивлён.
                                            0
                                            А перейти к объявлению метода по тыку на него это рутинная работа?
                                              +1
                                              Да. Либо перейти, либо увидеть всплывающую подсказку с сигнатурой и прочей документацией.
                                                0
                                                Не завидую я вам.
                                                  +1
                                                  Почему? Я не должен помнить все сигнатуры всех методов приложения, библиотек, фреймворков, стандартной библиотеки и т. п.
                                                    –3

                                                    Конечно, должны. ЭВМ придуманы не для того, чтобы делать за вас рутинную работу. </irony>

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

                                                      Или, возможно, вы плохо знакомы с используемой платформой, на базе которой разрабатываете свое приложение?

                                                      Хотя, если вам так удобно, то возражений нет. Просто для меня это как то необычно, но кого интересуют мои предпочтения? )))
                                                        0
                                                        Зачем лезть в маны, если код самодокументированный и в манах то же самое написано, поскольку они автосгенерированные по коду?
                                                          0
                                                          То есть вы работаете с уже готовым кодом, в котором вызовы методов некоторого пакета были написаны до вас, и вы по этим вызовам ходите и смотрите, что эти вызовы делаю?
                                                            0
                                                            Как вариант. Или просто помню (или автокомплит напомнит) название метода, а нюансов вроде типа или семантики параметров не помнишь. Переходишь на объявление метода и смотришь сигнатуру метода, *doc комментарии к ним, а иногда и в исходники лезешь, когда, например, не понятно что в граничных случаях происходит.
                                                              0
                                                              Да, не завидую я вам. И у вас это настолько часто, что аж рутинно?
                                                                0
                                                                Я вас не понимаю. Вы программист, но вы не читаете код?
                                                                  +1
                                                                  Я изучаю пакет/библиотеку/фреймворк с которым буду работать. Если мне и бывает нужно вспомнить семантику того или иного класса, я открываю его и читаю. К счатью, мне это бывает необходимо не очень часто (раз-два в день), и в рутину это не превращается.
                                    +1
                                    Все перепробованные мной IDE под Linux дохли (или переставали корректно работать — ломался синтаксический анализатор, не работали переходы), стоило только начать работать с исходниками ядра. Ибо анализаторы в них слишком сложны и медленны для интерактивной работы с реально большими проектами.

                                    Остались только cscope, ctags и SublimeText. Так что редакторы ещё повоюют.
                                      +1
                                      Извините, но ваша аргументация очень странная. Все равно, что говорить «Танк — настоящее оружие убийства, он для того и сделан. А то, что вы прикрепили на ваш уазик пулемет — это фигня, все равно он предназначен для езды, а не для убийства».

                                      Вообще несколько сомнительно сравнивать современные продукты и программу вышедшею 25 лет назад. Естественно тогда были совсем другие цели. К тому же затрагиваете довольно философский (а значит неотвечаемый) вопрос: если добавить плагин, анализирующий код, можно считать, что вим знает что-то о языке или нет?

                                      ps. Наверное, я все-таки ожидал (смотря на название статьи) списка различий IDE и vim, а точнее говоря IDE и любого directory oriented editor'а (vim, emac, sublime, etc...). Но тут этого нет.
                                        –1
                                        Правильнее так:
                                        Танк — настоящее оружие убийства, он для того и сделан. А то, что вы прикрепили на ваш уазик пулемет — это позерство, и вообще, не служил, не мужик!

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

                                      Самое читаемое