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

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

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

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

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

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

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

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

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

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

Современные IDE, к примеру QtCreator 4, студии под рукой нет, к сожалению, но думаю и там тоже, умеют делать такие трюки, как выведение типа auto для С++, хотелось бы посмотреть на плагин к текстовому редактору, который это сумеет :)
неужели нельзя сделать аналогичный плагин на основе какого нибудь llvm?
UFO landed and left these words here
Автор начал о возможностях двух редакторов, а закончил про «из коробки». Эхх… Откуда же вы лезите?
Только вот на хабре принято начинать, аргументировать и заказчивать одну мысль.

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


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


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

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


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


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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

ps. Наверное, я все-таки ожидал (смотря на название статьи) списка различий IDE и vim, а точнее говоря IDE и любого directory oriented editor'а (vim, emac, sublime, etc...). Но тут этого нет.
Правильнее так:
Танк — настоящее оружие убийства, он для того и сделан. А то, что вы прикрепили на ваш уазик пулемет — это позерство, и вообще, не служил, не мужик!
Only those users with full accounts are able to leave comments. Log in, please.