По сути, статья будет развернутым пояснением идеи, высказанной другим пользователем в комментарии к статье «VIM: зачем, если есть IDE, и как?».
Принципиально IDE от редактора отличается тем, что IDE оперирует синтаксическим деревом редактируемого кода на целевом языке (или неким к нему приближением), а редактор оперирует символами и строками.
Я отталкиваюсь от мысли, что vim и IDE — разные инструменты для разных задач. Совершенно разных и, более того, не пересекающихся задач.
IDE
Задача IDE — разработка программы на одном из языков программирования. Чем лучше IDE «понимает» язык программирования, тем более полезные функции она может предложить разработчику. Начиная от самых элементарных — подсветка синтаксиса, и заканчивая наиболее продвинутыми — подсветка потенциальных ошибок и рефакторинг.
Как пример можно рассмотреть проект Roslyn и Visual Studio. Про него можно прочитать в одной старой статье — Введение в 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)
oYASo
06.07.2016 11:28Просто уже давно есть IDE, в которые отлично интегрирован vim (например, Qt Creator). Хочешь юзай, хочешь нет.
dvor
06.07.2016 12:12-6Единственная
IDEоперационная система, в которую отлично интегрирован vim — это emacs. Все остальное — жалкие подделки.
potan
06.07.2016 14:18+3Я пробовал — «жалкое подобие левой руки».
dvor
06.07.2016 14:23Дополню себя — я говорил об Evil (an extensible vi layer for Emacs). Это самый полный из эмуляторов вима, который я видел. Я бы сказал, что они близок процентов на 98 к оригиналу.
Таким образом можно получить редактор, совмещающий лучшее из двух миров. Emacs добавляет:
— расширяемость на стероидах (привет elisp вместо vim script)
— асинхронность
— org-mode
Из минусов я бы назвал долгое время старта. Однако это не важно в случае, если редактор используется только на одном компьютере.
Для желающих почитать/посмотреть на темуhttps://www.youtube.com/watch?v=JWD1Fpdd4Pc
http://blog.aaronbieber.com/2015/01/17/learning-to-love-emacs.html
http://juanjoalvarez.net/es/detail/2014/sep/19/vim-emacsevil-chaotic-migration-guide/
Если лень копать конфиг, можно посмотреть на готовую сборку.
temonix
06.07.2016 16:16+1Использую я эту вундервафлю… уже пилю свою конфигу около года. Не достиг похожести даже на 80%. Одна из проблем — dired у него свои хоткеи, у nerd_tree свои. Так и получается, что юзая vim держишь один набор хоткеев, юзая vim и evil уже держишь 2 набора хоткеев. И так для каждого плагина. В итоге при работе больше думаешь о том, как запилить себе бинды, а не о программинге. Так что evil у меня только для org-mode, а программлю я все равно на vim.
dvor
06.07.2016 16:52Мне удалось перенести все используемые плагины и полностью переехать недели за 2 (тратя где-то в среднем по 30 минут в день).
Не использую nerd_tree/dired, но в чем проблема у последнего переопределять все хотели и сделать их как в nerd_tree? Либо, если там совсем отличается воркфлоу, то просто выучить новый?
Возможно вам нужно использовать одновременно и vim, и evil? В таком случае синхронизация конфигов действительно будет головной болью. Я могу полностью перейти на емакс — редактор нужен только на моей рабочей/домашней машине, никакого редактирования по ssh.
aragaer
06.07.2016 11:54+2> На мой взгляд, лучшим решением было бы, если бы IDE и редактор текста были бы отдельными модулями, взаимодействующими через некое API (как это сделано между IDE и компилятором Roslyn). Чтобы в IDE можно было бы встроить любой редактор, наиболее подходящий для работы с текстом.
eclim примерно это и делает. Хотя тот еще франкенштейн.mpetrunin
06.07.2016 17:05Прикручивали, кстати, eclim к VIM? Работает?
aragaer
06.07.2016 17:32Он именно к vim изначально и прикручивается и у меня оно заработало. Но я пошел еще дальше и у меня emacs с evil-mode и в нем emacs-eclim. И тоже работает.
Для java и android я даже действительно этим пользовался (потому что что с чистым eclipse, что с android studio у меня получалась не работа, а война). Для чего-то другого (питон, си) пока не пробовал.
thatsme
06.07.2016 12:25+4vim прекрасно справляется и с подсветкой синтаксиса и с подсветкой синтаксических ошибок. Писать код с использованием vim вполне себе нормальное занятие, и чаще это просто дело привычки.
Однако vim это действительно не IDE: vim не знает ничего кроме синтаксиса, и понятия не имеет, например о содержимом структур данных и классов, и соответственно не в состоянии валидировать семантику. Современная IDE должна уметь это делать, и должна определять доступность классов и объектов в контексте редактируемого кода. Да почему современная? Древние Borland-овский Turbo Pascal и Turbo C из конца 80-х прошлого века умели это делать. vim не умеет. А также не забываем о сторонних фреймворках используемых в Вашем проекте, знания о которых у vim просто быть не может.
Для небольших проектов (до 10-15 фалов), я например, продолжаю использовать vim, т.к. вполне в состоянии удержать информацию такого объёма в голове. И в таком случае продуктивность использования vim выше чем IDE. Как только объём информации необходимой для работы с кодом становится таким, что я начинаю забывать детали реализации в каком либо из классов, или суммарная информация о проекте не умещается в моей голове, я перевожу проект на любимую IDE (NetBeans).
Tujh
06.07.2016 13:44-2Современные IDE, к примеру QtCreator 4, студии под рукой нет, к сожалению, но думаю и там тоже, умеют делать такие трюки, как выведение типа auto для С++, хотелось бы посмотреть на плагин к текстовому редактору, который это сумеет :)
dimykus
06.07.2016 15:10неужели нельзя сделать аналогичный плагин на основе какого нибудь llvm?
Laney1
06.07.2016 21:00-1я даже больше скажу, такой плагин существует и для самого Qt Creator. И, ЕМНИП, он будет включен по умолчанию, когда решатся проблемы с производительностью. С точки зрения архитектуры это ничем не отличается от vim+ycm. Интересно, каким образом можно пользоваться Qt Creator и не знать о таких вещах.
northicewind
06.07.2016 15:19+4YouCompleteMe использует clang для автокомплита. И так же поддерживает clang CompilationDatabase
mpetrunin
06.07.2016 16:46+1Если честно, после такого громкого заголовка ожидал увидеть примеры, на которых IDE наголову бьёт VIM (набором плагинов для языка).
К сожалению, ничего сверх процитированного
Принципиально IDE от редактора отличается тем, что IDE оперирует синтаксическим деревом редактируемого кода на целевом языке (или неким к нему приближением), а редактор оперирует символами и строками.
почерпнуть из текста не удалось :(
Очень хочется уже нормального разбора от приверженца IDE, который покажет примеры из жизни программиста, в которых без возможностей IDE (которых нет в VIM) — ну никак. Хочется увидеть особенности вашего рабочего процесса (workflow, если хотите). Хочется, чтобы в нём существенно были задействованы фишки IDE, хочется, чтобы было видно, что они экономят вам человеко-часы. Чтобы IDE делало рутинную работу за вас и т.п.
Жду вот такого материала.
А разоблачения в стиле "VIM — редактор текста", и "голый VIM малопригоден для программиста, в то время как в IDE анализатор кода!!!". Ну право слово, даже обидно как-то.
Delphinum
06.07.2016 16:57почерпнуть из текста не удалось
И не удастся. Авторы подобных статей когда нибудь поймут, что один редактор от другого может отличаться только наличием или отсутствием плагинов. Нет там больше никакой особой магииapple.Posigrade
06.07.2016 17:08Delphinum, магии действительно нет, но разница (принципиальная) есть. поправьте меня, но vim же не может графику.
Vim — нормальный текстовый UI для работы с тем, что можно представить в виде текста. Типа да «текстовый редактор», но «текст» — не в смысле «чо-то там типа на каком-то языке, где есть абзацы», а в смысле данные в текстовом формате, последовательности печатных символов. Если кому-то не нравятся абзацы и естественный язык, а нравится что-то другое, то пусть прикручивает clang или roslyn или libxml2. Т.е. имхо в реальности у vim есть (а может и был. я по событиям ~5летней давности говорю) всего один фатальный (для тех, кому это важно, в т.ч. для меня) недостаток — он чисто текстовый, т.е. открыть firefox или построитель графиков внутри какого-то окна внутри, скажем, gvim нет возможности.Delphinum
06.07.2016 17:16+1но vim же не может графику
Смотря что подразумивать под «мочь графику».
Vim так или иначе следует Unix-way, и я считаю это правильным. Если вам нужно, к примеру, в редакторе собрать модель классов на UML и на основе ее сгенерить пачку классов, то лучше воспользуйтесь для этого сторонним инструментом, который умеет это делать и специально для этого заточен. Да, Vim из коробки такого не умеет, и я считаю, что это правильно.
открыть firefox
А в чем проблема открыть firefox из vim?
построитель графиков внутри какого-то окна внутри, скажем, gvim
Вызывайте какую нить системную тулзу, типа display и радуйтесь.
что можно представить в виде текста
Совершенно так. Народ сравнивает две кружки так, как будто это кружка и слон. Нет, текст, с которым работает Vim и текст, с которым работает IDE это одно и тоже. Вот если бы IDE работали с диаграммами, а Vim с текстом, то это уже была бы принципиальная разница. В общем да, я согласен с вами.Posigrade
06.07.2016 18:26>мочь графику
всмысле 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 это одно и тоже.
факт!Delphinum
06.07.2016 18:30но вот в Vim графику
Вам стоит больше беспокоится о синхронности Vim, а не об этом, поверьте )
mirror13
07.07.2016 12:00+1Как вам уже сказали: браузер и графика в Vim — это не Unix-way. А для такого ворклфоу, как описываете вы, хорошо подходят тайлинговые менеджеры окон. Тогда получается, что всё что надо живёт в своих тайлах и переключаться между ними удобно и быстро.
Posigrade
08.07.2016 00:37спасибо за совет, уточнения:
1) это было 5 лет назад
2) 5 лет назад это решилось переездом на Emacs, т.к. в Emacs можно и текст и графику.
>тайлинговые менеджеры окон
а под виндой это будет работать? я просто из любопытства спрашиваю, вопрос вообще не стоит.Delphinum
08.07.2016 13:23+1т.к. в Emacs можно и текст и графику
И кофе он варить умеет, и вообще это тайный проект Столмана по разработке свой собственной ОС. Знаем )
mirror13
08.07.2016 18:40Про винду сказать не могу — не пользуюсь. Но вот что есть на reddit: https://www.reddit.com/r/windows/comments/2rn775/best_tiled_window_manager_for_windows/
develop7
06.07.2016 19:12Нет, текст, с которым работает Vim и текст, с которым работает IDE это одно и тоже.
Однако внутреннее представление этого текста различно. Соответственно, довольно существенная разница заключается в накладываемых представлением ограничения на возможные операции с этим текстом.
Вот если бы IDE работали с диаграммами, а Vim с текстом
Vim работает с текстом, IDE — с абстрактным/конкретным синтаксическим деревом, полученным из этого текста.
Delphinum
06.07.2016 19:22+1Соответственно, довольно существенная разница заключается в накладываемых представлением ограничения на возможные операции с этим текстом
И это вопрос уровня плагинов. IDE включает в себя плагин синтаксического анализатора и плагины на его базе, Vim такого плагина в себе не включает. Вся разница в этом, не нужно больше ничего придумывать от себя, как автор этой статьи, про некие «задачи» или «различные инструменты». И то и другое, это всего навсего редактор текста.
Vim работает с текстом, IDE — с абстрактным/конкретным синтаксическим деревом, полученным из этого текста
Повторюсь, и то и другое работает с текстом. Некоторый плагин в IDE позволяет ей этот текст представить в виде дерева с контекстными связями. Повторите этот плагин в Vim и он станет IDE. Другими словами Vim это редактор, IDE это редактор + плагин. В сравнении двух редакторов «с» и «без» плагина не вижу вообще никакого смысла, особенно разводить на этой почве холивар. Это разный функционал.develop7
06.07.2016 21:27-3IDE включает в себя плагин синтаксического анализатора
Да? Тогда этот плагин должен быть опубликован на plugins.jetbrains.com|Eclipse Marketplace|plugins.netbeans.com
Delphinum
06.07.2016 22:18+1Кто это такое необычное требование выставил JetBrains?
develop7
07.07.2016 11:49Конкретно JB даже платные плагины публикует у себя в галерее. Соответственно, логично искать «плагин синтаксического анализатора» именно там.
Borz
07.07.2016 16:18не все плагины публикуются — некоторые идут строго в сборке (bundled-plugins)
develop7
07.07.2016 18:17это да, однако я уверен, что «плагин синтаксического анализатора» отсутствует и среди них
Borz
07.07.2016 18:40ну, он может ещё быть как неотключаемый плагин ядра (читайте «модуль»), тогда вы его не увидете в списке плагинов.
А так, есть же статический анализ кода: flexible static code analysis, который, как я понимаю, лежит в библиотеке openapi.jar
ЗЫ: а вообще, думается человек просто описался говоря «плагин» — в остальном же правильно сказалDelphinum
08.07.2016 13:27думается человек просто описался говоря «плагин»
Нисколько, я всего навсего пытаюсь просто и понятно излагать свои мысли, так как читать это будем не только мы с вами, а мыслить в контексте плагинов редактора, а не в контексте функционала ядра, многим проще.
Delphinum
08.07.2016 13:25Давайте назовем это не плагином, а «функционалом», так, возможно, вам станет понятнее о чем я говорю.
VolCh
06.07.2016 18:09Чтобы IDE делало рутинную работу за вас и т.п.
Рефакторинг. Например, банальное переименование метода класса. Конкретного метода конкретного класса с учётом возможных дублей как имени класса так и имени метода в каталоге проекта. Причём для динамически типизированных языков.
Автодополнение с учётом контекста.mpetrunin
06.07.2016 18:14Это всё обсуждалось в комментариях тут множество раз. Для VIM есть куча плагинов, которые делают эту работу, в т.ч. посредством анализа кода, в т.ч. для динамически типизированных языков.
Моё мнение, нужны не общие слова (вроде тех, что вы привели), а конкретные примеры для конкретных языков, где <ФИЧА> не работает или работает плохо в VIM, работает отлично в IDE, и где объяснено, почему <ФИЧА> — это очень полезная вещь, и как она ускоряет/облегчает процесс разработки.
VolCh
06.07.2016 18:23Сейчас не буду настраивать vim для PHP, но года три назад я не мог банально перейти по имени класса в конструкции типа $obj = new SomeClass(), если SomeClass существовал в каталоге проекта не в одном экземляре, а в нескольких (с разными неймспейсами). Куда перейти однозначно определялось кодом в каталоге проекта, никакой неоднозначности не было, если знаешь о том, что конструкции языка namespace и use изменяют области видимости.
Delphinum
06.07.2016 18:25Да и сейчас вам это нормально не удастся.
VolCh
06.07.2016 18:31Почему-то не удивлён.
Delphinum
06.07.2016 18:42А перейти к объявлению метода по тыку на него это рутинная работа?
VolCh
06.07.2016 18:47+1Да. Либо перейти, либо увидеть всплывающую подсказку с сигнатурой и прочей документацией.
Delphinum
06.07.2016 18:49Не завидую я вам.
VolCh
07.07.2016 06:40+1Почему? Я не должен помнить все сигнатуры всех методов приложения, библиотек, фреймворков, стандартной библиотеки и т. п.
develop7
07.07.2016 11:00-3Конечно, должны. ЭВМ придуманы не для того, чтобы делать за вас рутинную работу. </irony>
Delphinum
08.07.2016 13:33Я могу ошибаться, но мне кажется что вы либо работаете с совершенно непонятным проектом с кривым интерфейсом, либо с совершенно незнакомыми пакетами. В первом случае это звоночек о рефакторинге, а подобное поведение IDE только отсрочило неизбежное. Во втором случае вы как то не верно подходите к процессу подключения пакета, пропуская этап изучения манов.
Или, возможно, вы плохо знакомы с используемой платформой, на базе которой разрабатываете свое приложение?
Хотя, если вам так удобно, то возражений нет. Просто для меня это как то необычно, но кого интересуют мои предпочтения? )))VolCh
08.07.2016 14:03Зачем лезть в маны, если код самодокументированный и в манах то же самое написано, поскольку они автосгенерированные по коду?
Delphinum
08.07.2016 14:14То есть вы работаете с уже готовым кодом, в котором вызовы методов некоторого пакета были написаны до вас, и вы по этим вызовам ходите и смотрите, что эти вызовы делаю?
VolCh
08.07.2016 15:19Как вариант. Или просто помню (или автокомплит напомнит) название метода, а нюансов вроде типа или семантики параметров не помнишь. Переходишь на объявление метода и смотришь сигнатуру метода, *doc комментарии к ним, а иногда и в исходники лезешь, когда, например, не понятно что в граничных случаях происходит.
Delphinum
09.07.2016 00:17Да, не завидую я вам. И у вас это настолько часто, что аж рутинно?
VolCh
10.07.2016 11:52Я вас не понимаю. Вы программист, но вы не читаете код?
Delphinum
10.07.2016 15:25+1Я изучаю пакет/библиотеку/фреймворк с которым буду работать. Если мне и бывает нужно вспомнить семантику того или иного класса, я открываю его и читаю. К счатью, мне это бывает необходимо не очень часто (раз-два в день), и в рутину это не превращается.
RomanArzumanyan
06.07.2016 17:13+1Все перепробованные мной IDE под Linux дохли (или переставали корректно работать — ломался синтаксический анализатор, не работали переходы), стоило только начать работать с исходниками ядра. Ибо анализаторы в них слишком сложны и медленны для интерактивной работы с реально большими проектами.
Остались только cscope, ctags и SublimeText. Так что редакторы ещё повоюют.
myxo
06.07.2016 17:21+1Извините, но ваша аргументация очень странная. Все равно, что говорить «Танк — настоящее оружие убийства, он для того и сделан. А то, что вы прикрепили на ваш уазик пулемет — это фигня, все равно он предназначен для езды, а не для убийства».
Вообще несколько сомнительно сравнивать современные продукты и программу вышедшею 25 лет назад. Естественно тогда были совсем другие цели. К тому же затрагиваете довольно философский (а значит неотвечаемый) вопрос: если добавить плагин, анализирующий код, можно считать, что вим знает что-то о языке или нет?
ps. Наверное, я все-таки ожидал (смотря на название статьи) списка различий IDE и vim, а точнее говоря IDE и любого directory oriented editor'а (vim, emac, sublime, etc...). Но тут этого нет.Delphinum
06.07.2016 17:26-1Правильнее так:
Танк — настоящее оружие убийства, он для того и сделан. А то, что вы прикрепили на ваш уазик пулемет — это позерство, и вообще, не служил, не мужик!
begemot_sun
> Удалить три слова 3dw
проблема в том, что удаляете вы не слова а термы языка, и как то не комильфо смешивать 2 разных парадигмы.
Вам просто повезло что 3 слова в редакторе = 3 термам языка. Попробуйте редактировать код на брайнфаке. Я думаю IDE и для него можно сделать с подсветкой :)