Комментарии 62
проблема в том, что удаляете вы не слова а термы языка, и как то не комильфо смешивать 2 разных парадигмы.
Вам просто повезло что 3 слова в редакторе = 3 термам языка. Попробуйте редактировать код на брайнфаке. Я думаю IDE и для него можно сделать с подсветкой :)
Таким образом можно получить редактор, совмещающий лучшее из двух миров. Emacs добавляет:
— расширяемость на стероидах (привет elisp вместо vim script)
— асинхронность
— org-mode
Из минусов я бы назвал долгое время старта. Однако это не важно в случае, если редактор используется только на одном компьютере.
Не использую nerd_tree/dired, но в чем проблема у последнего переопределять все хотели и сделать их как в nerd_tree? Либо, если там совсем отличается воркфлоу, то просто выучить новый?
Возможно вам нужно использовать одновременно и vim, и evil? В таком случае синхронизация конфигов действительно будет головной болью. Я могу полностью перейти на емакс — редактор нужен только на моей рабочей/домашней машине, никакого редактирования по ssh.
eclim примерно это и делает. Хотя тот еще франкенштейн.
Прикручивали, кстати, eclim к VIM? Работает?
Для java и android я даже действительно этим пользовался (потому что что с чистым eclipse, что с android studio у меня получалась не работа, а война). Для чего-то другого (питон, си) пока не пробовал.
Однако vim это действительно не IDE: vim не знает ничего кроме синтаксиса, и понятия не имеет, например о содержимом структур данных и классов, и соответственно не в состоянии валидировать семантику. Современная IDE должна уметь это делать, и должна определять доступность классов и объектов в контексте редактируемого кода. Да почему современная? Древние Borland-овский Turbo Pascal и Turbo C из конца 80-х прошлого века умели это делать. vim не умеет. А также не забываем о сторонних фреймворках используемых в Вашем проекте, знания о которых у vim просто быть не может.
Для небольших проектов (до 10-15 фалов), я например, продолжаю использовать vim, т.к. вполне в состоянии удержать информацию такого объёма в голове. И в таком случае продуктивность использования vim выше чем IDE. Как только объём информации необходимой для работы с кодом становится таким, что я начинаю забывать детали реализации в каком либо из классов, или суммарная информация о проекте не умещается в моей голове, я перевожу проект на любимую IDE (NetBeans).
Если честно, после такого громкого заголовка ожидал увидеть примеры, на которых IDE наголову бьёт VIM (набором плагинов для языка).
К сожалению, ничего сверх процитированного
Принципиально IDE от редактора отличается тем, что IDE оперирует синтаксическим деревом редактируемого кода на целевом языке (или неким к нему приближением), а редактор оперирует символами и строками.
почерпнуть из текста не удалось :(
Очень хочется уже нормального разбора от приверженца IDE, который покажет примеры из жизни программиста, в которых без возможностей IDE (которых нет в VIM) — ну никак. Хочется увидеть особенности вашего рабочего процесса (workflow, если хотите). Хочется, чтобы в нём существенно были задействованы фишки IDE, хочется, чтобы было видно, что они экономят вам человеко-часы. Чтобы IDE делало рутинную работу за вас и т.п.
Жду вот такого материала.
А разоблачения в стиле "VIM — редактор текста", и "голый VIM малопригоден для программиста, в то время как в IDE анализатор кода!!!". Ну право слово, даже обидно как-то.
почерпнуть из текста не удалось
И не удастся. Авторы подобных статей когда нибудь поймут, что один редактор от другого может отличаться только наличием или отсутствием плагинов. Нет там больше никакой особой магии
Vim — нормальный текстовый UI для работы с тем, что можно представить в виде текста. Типа да «текстовый редактор», но «текст» — не в смысле «чо-то там типа на каком-то языке, где есть абзацы», а в смысле данные в текстовом формате, последовательности печатных символов. Если кому-то не нравятся абзацы и естественный язык, а нравится что-то другое, то пусть прикручивает clang или roslyn или libxml2. Т.е. имхо в реальности у vim есть (а может и был. я по событиям ~5летней давности говорю) всего один фатальный (для тех, кому это важно, в т.ч. для меня) недостаток — он чисто текстовый, т.е. открыть firefox или построитель графиков внутри какого-то окна внутри, скажем, gvim нет возможности.
но vim же не может графику
Смотря что подразумивать под «мочь графику».
Vim так или иначе следует Unix-way, и я считаю это правильным. Если вам нужно, к примеру, в редакторе собрать модель классов на UML и на основе ее сгенерить пачку классов, то лучше воспользуйтесь для этого сторонним инструментом, который умеет это делать и специально для этого заточен. Да, Vim из коробки такого не умеет, и я считаю, что это правильно.
открыть firefox
А в чем проблема открыть firefox из vim?
построитель графиков внутри какого-то окна внутри, скажем, gvim
Вызывайте какую нить системную тулзу, типа display и радуйтесь.
что можно представить в виде текста
Совершенно так. Народ сравнивает две кружки так, как будто это кружка и слон. Нет, текст, с которым работает Vim и текст, с которым работает IDE это одно и тоже. Вот если бы IDE работали с диаграммами, а Vim с текстом, то это уже была бы принципиальная разница. В общем да, я согласен с вами.
всмысле 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 это одно и тоже.
факт!
но вот в Vim графику
Вам стоит больше беспокоится о синхронности Vim, а не об этом, поверьте )
1) это было 5 лет назад
2) 5 лет назад это решилось переездом на Emacs, т.к. в Emacs можно и текст и графику.
>тайлинговые менеджеры окон
а под виндой это будет работать? я просто из любопытства спрашиваю, вопрос вообще не стоит.
Соответственно, довольно существенная разница заключается в накладываемых представлением ограничения на возможные операции с этим текстом
И это вопрос уровня плагинов. IDE включает в себя плагин синтаксического анализатора и плагины на его базе, Vim такого плагина в себе не включает. Вся разница в этом, не нужно больше ничего придумывать от себя, как автор этой статьи, про некие «задачи» или «различные инструменты». И то и другое, это всего навсего редактор текста.
Vim работает с текстом, IDE — с абстрактным/конкретным синтаксическим деревом, полученным из этого текста
Повторюсь, и то и другое работает с текстом. Некоторый плагин в IDE позволяет ей этот текст представить в виде дерева с контекстными связями. Повторите этот плагин в Vim и он станет IDE. Другими словами Vim это редактор, IDE это редактор + плагин. В сравнении двух редакторов «с» и «без» плагина не вижу вообще никакого смысла, особенно разводить на этой почве холивар. Это разный функционал.
А так, есть же статический анализ кода: flexible static code analysis, который, как я понимаю, лежит в библиотеке openapi.jar
ЗЫ: а вообще, думается человек просто описался говоря «плагин» — в остальном же правильно сказал
Чтобы IDE делало рутинную работу за вас и т.п.
Рефакторинг. Например, банальное переименование метода класса. Конкретного метода конкретного класса с учётом возможных дублей как имени класса так и имени метода в каталоге проекта. Причём для динамически типизированных языков.
Автодополнение с учётом контекста.
Это всё обсуждалось в комментариях тут множество раз. Для VIM есть куча плагинов, которые делают эту работу, в т.ч. посредством анализа кода, в т.ч. для динамически типизированных языков.
Моё мнение, нужны не общие слова (вроде тех, что вы привели), а конкретные примеры для конкретных языков, где <ФИЧА> не работает или работает плохо в VIM, работает отлично в IDE, и где объяснено, почему <ФИЧА> — это очень полезная вещь, и как она ускоряет/облегчает процесс разработки.
Или, возможно, вы плохо знакомы с используемой платформой, на базе которой разрабатываете свое приложение?
Хотя, если вам так удобно, то возражений нет. Просто для меня это как то необычно, но кого интересуют мои предпочтения? )))
Остались только cscope, ctags и SublimeText. Так что редакторы ещё повоюют.
Вообще несколько сомнительно сравнивать современные продукты и программу вышедшею 25 лет назад. Естественно тогда были совсем другие цели. К тому же затрагиваете довольно философский (а значит неотвечаемый) вопрос: если добавить плагин, анализирующий код, можно считать, что вим знает что-то о языке или нет?
ps. Наверное, я все-таки ожидал (смотря на название статьи) списка различий IDE и vim, а точнее говоря IDE и любого directory oriented editor'а (vim, emac, sublime, etc...). Но тут этого нет.
Vim и IDE — это разные вещи