Вот уже второй год я активный пользователь и поклонник редактора Vim. За это время я прошел путь от двух команд в .vimrc, до файла в несколько килобайт и обратно. Я испробовал очень много плагинов, а так же активно писал собственные, и теперь это мой основной текстовый редактор для работы и отдыха.
В этой серии статей я решил поделиться собственными наработками и, возможно, показать, на что может быть способен этот редактор в руках программиста. Серия будет состоять из следующих частей:
- Введение (vim_lib)
- Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
- Уровень проекта и файловая система (vim_prj, nerdtree)
- Snippets и шаблоны файлов (UltiSnips, vim_template)
- Компиляция и выполнение чего угодно (vim-quickrun)
- Работа с Git (vim_git)
- Деплой (vim_deploy)
- Тестирование с помощью xUnit (vim_unittest)
- Библиотека, на которой все держится (vim_lib)
- Другие полезные плагины
Хочется сразу заметить, что я не преследую цель «посадить как можно больше людей на иглу Vim», так как статья больше расчитана на опытных пользователей, нежели на новичков.
Что не так с плагинами для Vim
Основная проблема редактора (если не считать VimLanguage), это огромное количество разнообразных плагинов на все случаи жизни. Казалось бы, что в этом плохого? Дело в том, что плагины пишутся огромным сообществом, от чего они крайне плохо стыкуются между собой. Часто можно столкнуться с тем, что один из твоих плагинов частично умеет то же, что и два других, просто потому, что автор этого плагина решил добавить в него побольше «плюшек». Если заглянуть в код большинства плагинов, можно встретить множество дублирующихся от плагина к плагину решений и алгоритмов, которые по хорошему должны быть вынесены либо в VimLanguage, либо в некоторую единую библиотеку. К сожалению некоторые авторы плагинов пытаются реализовывать эти библиотеки, но после нескольких простеньких плагинов, созданных на базе этих библиотек, они прекращают поддержку и помимо десятка не слишком различающихся плагинов, вы должны установить парочку библиотек.
Когда я занялся разработкой под Vim, моей основной целью было написание единой библиотеки (да, еще один стандарт) для всех моих, а главное, чужих плагинов. Отличительной особенностью моей идеи от других было то, что я собирался реализовать все основные плагины на базе этой библиотеки, а если есть готовые решения, то привести их к стандартам библиотеки. Другими словами я хочу реализовать весь «джентльменский набор» плагинов, которые будут стыковаться друг с другом «из коробки» и использовать единую библиотеку.
Два года работы
Свое движение к «чистому и прекрасному» я начал с написания библиотеки. Переписывал ее я целых три раза, ибо мне нужно было хорошенько разобраться во всех тонкостях VimLanguage, его возможностях и ограничениях, а их, я вам скажу, там множество! В результате получилась библиотека vim_lib, которая меня полностью удовлетворяет.
Особенностью библиотеки является то, что она определяет структуру редактора в целом (как фреймворк), добавляя новый уровень действия скриптов — проектный. На деле, это позволяет вам настроить ваш редактор для конкретного проекта и даже установить плагины, которые будут работать только в этом проекте. Это особенно полезно, когда вы работаете с несколькими ЯП.
Вот вам небольшой пример. Предположим, мы работаем с web-проектом используя PHP и JavaScript, а в свободное время пишем книгу с помощью LaTeX. Что вам могу предложить я и Vim:
- Все общие настройки выносятся в каталог ~/.vim/, после чего они будут доступны во всех проектах
- Настройки для web-проекта мы положим в каталог webProject/.vim/, а для работы с книгой в bookProject/.vim/
- Каждый раз, открывая окно редактора Vim, мы будем видеть список недавних проектова перейдя в проект, он откроется в месте его последнего редактирования с восстановлением всех окон
- Чтобы каждый раз не создавать файлы в чистого листа (например Unit-тесты, классы Mapper для бизнес-логики или главы книги), мы создадим готовые шаблоны файловв каждом проекте (например для Unit-тестов webProject/.vim/templates/test/___Test.php)
- Кто захочет постоянно набирать
Пусть это сделает за нас Vim. Создадим несколько snippets на все случаи жизниforeach(...) - Для работы с LaTeX установим прямо в проект bookProject специфичные для LaTeX плагины
- Но мы не одиноки, потому поделимся с нашими соратниками своими наработками с помощью Git, а для этого у нас есть удобный интерфейс прямо в Vim
- Закончили очередную главу и хотите посмотреть на нее в pdf читалке? Не вопрос! Нажимайте F9 и книга будет скомпилирована и показана вам незамедлительно. Есть ли смысл упоминать о других скриптах, которые можно выполнить столь же просто?
- Решили запустить тестирование конкретного класса? Не вопрос, и для этого найдется плагин
- Пришло время слить изменения в продакшн? Нажимаем одну кнопку и они уже там
Опытные пользователи Vim скажут: «Пфф… Для всего этого есть куча готовых плагинов. Велосипед!» — но вы просто не знаете на что способны предлагаемые мной решения. Мало того, что они легко стыкуются друг с другом, так они еще и более функциональные по сравнению с аналогами среди плагинов Vim! В этом вы сможете убедится в следующих статьях цикла, просто наберитесь терпения.
Что если не терпится
Практически все свои плагины я сопровождаю подробной документацией, потому попробовать вы их можете уже сейчас. Вот перечень реализованных на сегодняшний день решений:
- vim_lib — базовая библиотека, без которой у вас ничего работать не будет. Она так же определяет порядок загрузки редактора
- vim_plugmanager — моя реализация пакетного менеджера для Vim без «фатальных недостатков». Особенностью этого решения является возможность установки плагина как в пользовательский каталог, так и в каталог проекта без необходимости изменять конфигурацию плагина, а так же автоматическое разрешение зависимостей устанавливаемых плагинов
- vim_prj — очень полезный плагин, позволяющий сохранять и восстанавливать состояние проекта при его открытии и закрытии
- vim_start — плагин реализующий стартовое меню с возможностью быстрого перехода к недавним проектам
- vim_git — очень мощный плагин для работы с Git прямо из Vim
- vim_grep — поиск в проекте
- vim_deploy — плагин для работы с любыми системами деплоя (за счет адаптеров к ним). На сегодня реализовано только два адаптера: shipit и gradle
- vim_unittest — плагин для работы с любыми системами xUnit (за счет адаптеров к ним). На сегодня реализован только адаптер для phpunit
- vim_template — очень полезный плагин, позволяющий гибко настраивать шаблоны для новых файлов
- vim_write — автоматическое сохранение проекта
- vim_winmanager — работа с окнами Vim
Для установки создайте каталог ~/.vim/bundle (можно использовать любое имя) и скопируйте туда vim_lib.
git clone https://github.com/Bashka/vim_lib.git ~/.vim/bundle/vim_lib
После добавьте в ваш .vimrc следующую запись:
filetype off
set rtp=~/.vim/bundle/vim_lib
call vim_lib#sys#Autoload#init('~/.vim', 'bundle') " Адрес до вашего ~/.vim/bundle
Plugin 'vim_lib'
" Другие плагины
filetype indent plugin on
В общем, все как всегда.
Пока все
Поддерживаю этот проект я в свободные от работы дни, поправляя найденные в течении недели баги и добавляя тот функционал, который мне был нужен в процессе работы. Если у вас есть пожелания, чего бы вам лично не хватало в Vim, пройдите опрос, и рано или поздно это будет реализовано в виде очередного плагина для Vim.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (85)
uvelichitel
06.06.2015 21:25+1Где можно найти вменяемое описание актуальных флагов сборки самого Vim из исходников, желательно всех флагов, желательно одним документом?
n0dwis
06.06.2015 21:53+5Скажите, а с проектами какого размера вы работали в vim?
Дело в том, что мне тоже нравится этот редактор, но я просто не могу использовать его для чего-то более-менее серьёзного. Очень не хватает как раз перехода к классам, объявлениям методов и т.п. Да, конечно есть ctags и т.п. но до idea ему далеко.
Как, скажем, вы поступаете, какими инструментами пользуетесь, если нужно быстро посмотреть код вызываемого метода в symfony? Или найти, где реализован метод интерфейса?
Verkholantsev
06.06.2015 22:38+1А чего нет в ctags, что есть в Idea?
f0rk
08.06.2015 12:17Я в основном пишу на JS в WebStorm, в Vim у меня получится настроить корректный автокомплит с учетом jsdoc аннотаций, с поддержкой алиасов, шаблонов и т.д.? Ну например что-то типа такого:
iiShrimp
06.06.2015 23:12+3На работе активно работаю с 3 проектами; один на ПХП (500к строк), 2 на руби (сумарно более 100к строк). Кроме того еще есть две дюжины мелких проектов; типа деплой скриптов и прочего. Для навигации в проектах использую Silver Searcher. До ВИМа использовал много разных ИДЕ в связке с различными технологиями (визуал студио, пайчарм, рубимайн, нетбинс, эклипс); если честно то я не могу себе даже представить уход от ВИМа в сторону чего-либо другого — настолько деревянным, медленным и невозможным в использовании оно мне сейчас кажется.
BelBES
06.06.2015 23:47+1Я немного из другой секты, но проблемы с навигацией по проектам в emacs впринципе теже… в итоге пока я пришел к тому, что из «умных» фич я использую только автокомплит по содержимому открытых буферов. А навигацию по проекту осуществляю тупо грепом… зачастую получается даже быстрее, чем когда пользовался QtCreator'ом. Но от полноценной поддержки работы с проектами все же наверно не отказался бы)
Delphinum Автор
07.06.2015 00:25Проблема и там и тут в отсутствии толковых семантических анализаторов.
avkoval
27.06.2015 22:08Советую присмотреться к projectile, helm. И то и другое дали очередной прирост производительности лично мне. Потом если в dired научиться пользоваться выборками/глобальными заменами вообще круто получается.
BelBES
27.06.2015 22:12projectile я пробовал, но он мне показался каким-то глючным и вообщем дело у меня с ним не сложилось. А helm я пробовал только как замену ido, но тоже отказался, т.к. ido показался мне более удобным.
з.ы. а может быть поделитесь ссылкой на свой .emacs файл, может у вас как-то более правильно эти можули сконфигурированы)
Delphinum Автор
07.06.2015 00:24Для всех текущих проектов я использую Vim. От небольших книг, до web-сервиса на 4 связаных сайта.
Проблем с переходами у меня нет, так как я очень подробно изучаю используемый инструмент (это не камень в чей то огород, не подумайте). Если возникает необходимость что то вспомнить, у меня под рукой всегда есть самописный справочник с удобной навигацией.
Я планирую реализовать полноценный синтаксический и (возможно) семантический анализатор кода под Vim на базе Lex-Yacc (или PLY, еще не решил), вот тогда уже будут плагины с возможностью перехода к объявлениям.
rsi
07.06.2015 04:20+4Я понимаю, что из вима можно собрать все что угодно за счет плагинов. Но неужели он реально удобнее чем ide от jetBrains? Зачем мучатся со сборками и написанием своих плагинов, когда можно поставить инструмент где уже все есть из коробки? Многие приводят в пример скорость, но из всех ide приведенной выше фирмы с которыми мне доводилось работать, медленно стартует только intellij idea. И даже при работе с ней это не доставляет дискомфорта, ведь я не запускаю новый проект каждые две минуты, а 30 секунд запуска ничто по сравнению с часами работы над проектом.
Delphinum Автор
07.06.2015 11:39Но неужели он реально удобнее чем ide от jetBrains?
Удобство складывается из множества мелких деталей. На пример быстрое приведение кода к общему code-style очень удобно, а так же умное автодополнение и возможность перехода к объявлениям тоже, но это лишь составляющие удобства.
Тяжело объяснить, чем именно привлекает Vim, но когда вливаешься в его, оторваться становится сложно.
Зачем мучатся со сборками и написанием своих плагинов, когда можно поставить инструмент где уже все есть из коробки?
Поверьте, далеко не все, особенно если вы любите «точить инструмент» и умеете программировать свою IDE.
ведь я не запускаю новый проект каждые две минуты
Это может показаться глупый, но я запускаю проекты очень часто. Я могу программировать мой рабочий проект, а затем внезапно перейти к исправлению бага в этой библиотеке, затем снова вернуться к моему проекту и так далее.
Agel_Nash
07.06.2015 11:53- быстрое приведение кода к общему code-style очень удобно
- умное автодополнение
- озможность перехода к объявлениям
Это все есть в ide от jetBrains. Тот же самый phpStorm
rsi
07.06.2015 12:02Видимо дело вкуса. Сам я не запускаю проекты часто, а если требуется быстро поправить somefile в someprodject могу открыть и сублим. Вим я запускаю только на удаленных серверах, где выбирать не приходиться и любовью к нему не проникся, впрочем как и ненавистью, но для работы мне его мало.
PerlPower
07.06.2015 03:24Как, скажем, вы поступаете, какими инструментами пользуетесь, если нужно быстро посмотреть код вызываемого метода в symfony? Или найти, где реализован метод интерфейса?
Для первого вполне хватает ctags. Когда нам нужно найти где «реализован метод интерфейса» мы используем ack или ag. Или коротенький самописный скрипт. Нет, мы не идиоты. Да, мы знаем про возможности жыдеи. Просто нам большую часть времени нужен удобный редактор для написания кода, а не кододробилка заточенная под рефакторинг.
alaska332
07.06.2015 22:42Я в виме делаю большие проекты, никаких проблем нет.
Есть куча плагинов, которые превращают вим в иде, но они абсолютно не нужны на самом деле.
Так же, как не нужно автодополнение, и масса прочих «фич», которыми гордятся коммерческие редакторы.
К нему тяжело привыкнуть (нужно около года использования), но я не видел ни кого, кто-бы об этом пожалел и хотел бы вернуться обратно в мир IDE.BelBES
07.06.2015 23:00Есть куча плагинов, которые превращают вим в иде, но они абсолютно не нужны на самом деле.
Так же, как не нужно автодополнение, и масса прочих «фич», которыми гордятся коммерческие редакторы.
Они нужны многим, но что в Vim, что в emacs все эти фичи реализованы ужасно криво, либо вообще не реализованы. Поэтому приходится утешать себя тем, что эти фичи не нужны)Delphinum Автор
07.06.2015 23:07приходится утешать себя тем, что эти фичи не нужны)
Либо научиться работать без этих фич )
alaska332
07.06.2015 23:10Я могу сравнивать.
Без них легче жить.
В виме есть все, что нужно.
А главное — уникальная концепция.
Не смотря на отсутствие автодополнений и т.д. код в нем пишется гораздо быстрее, да и вообще, теперь вим режима не хватает в любом другом софте, настолько он удобен. Хорошо, хоть для браузеров есть vim плагины.BelBES
07.06.2015 23:46В QtCreator, Eclipse, IDEA насколько мне известно тоже есть Vim-режим редактирования.
Я полностью перешел на редактор «без фич», но таки не сказал бы, что нормальное автодополнение, полноценная работа с проектом как с проектом, а не набором файлов и т.п. мне помешают. По крайней мере в emacs мне автокомплит по буферам и снипеты частенько немного упрощают жизнь.Delphinum Автор
07.06.2015 23:51В QtCreator, Eclipse, IDEA насколько мне известно тоже есть Vim-режим редактирования
Гадость гадкая, поверьте мне.
По крайней мере в emacs мне автокомплит по буферам и снипеты частенько немного упрощают жизнь
В Vim из коробки так же есть автокомплиты, и не только по буферам. Со снипетами из коробки сложнее )alaska332
08.06.2015 00:05Чего, а всяких сниппет / темплейт плагинов хавтает.
Раньше первой программой новичка был калькулятор, а теперь темплейт плагин для вим.
В этой области есть вполне обозримые горизонты и идеалы.
И они достигнуты.Delphinum Автор
08.06.2015 00:09Вы про шаблоны для новых файлов?
alaska332
08.06.2015 00:11Не только. Про сниппеты тоже.
Delphinum Автор
08.06.2015 00:12Ну на счет обозримых горизонтов не соглашусь. Чем разнообразнее программные архитектуры, чем изощренее решения, тем сложнее шаблоны и снипеты к ним. У меня, на пример, ни один проект не обходился без собственного набора шаблонов и снипетов.
alaska332
08.06.2015 00:17Понятно, что шаблоны у каждого свои.
Я имел ввиду средства хранения / управления всем этим.
Тут что-то новое (да еще и действительно полезное) уже тяжело изобрести.Delphinum Автор
08.06.2015 00:21Согласен. Главное чтоб все было достаточно гибко в реализации и удобно в использовании. Я выбрал UltiSnips (хотя и не очень доволен им) и мой vim_template.
alaska332
08.06.2015 00:24Я все делаю на unite, функционал пишу сам.
Зато все единообразно выглядит и работает.
Для меня это важно.
Сейчас почти все уже самописное.
alaska332
07.06.2015 23:59+1Ну, может быть. Меня отсутствие всего этого не напрягало, когда перешел на вим.
Проект — это логичная файловая структура. Если этого нет — это проблема другого порядка.
Не знаю, что еще надо, чтобы работать с кодом, как с проектом, кроме вима и файлового менеджера.
Все субъективно.
Вообще, с ростом знаний, профессионализма и навыков, код быстрее пишется напрямую, без всяких инструментов, которые должны этот код «писать за вас» и всячески помогать, но, естественно, делать этого не могут. ;-)
PerlPower
08.06.2015 03:41А зачем заниматься самоутешением? Вы правда думаете, что профессионально освоить продукт из линейки Jetbrains гораздо сложнее, чем vim или emacs?
BelBES
08.06.2015 10:19Вы правда думаете, что профессионально освоить продукт из линейки Jetbrains гораздо сложнее, чем vim или emacs?
Я этого нигде и не утверждал) Про «самоутешение» я немного утрировал, но смысл тот-же. Некоторые действительно полезные фичи типа автокомплитов или навигации по проекту в каком-то виде настраиваются и в Vim и в emacs, но могли бы быть и лучше. Но при этом удобство работы с текстом и возможность работать без мыши в большинстве случаев перекрывает эти минусы и плюсы больших IDE типа продуктов от Jetbrains.
Creeonix
08.06.2015 09:54Как мне кажется, они нужны тем, кто не способен к слепому набору и не знает кодовой базы проекта. Грэп и быстрый переход к файлу это 98% навигации необходимой для быстрого, реально быстрого перехода и использования кодовой базы проекта. Сколько раз я видел разработчиков, которые пользуются боковой панелью с деревом файлов в IDEA, а ведь можно использовать аналог Cmd+T что экономит где-то пол часа в день.
Лично для меня, IDEA подобные вещи работают слишком медленно, слишком часто встречался с ситуацией когда после нажатия поиска по файлам и начала ввода окно поиска еще не отрисовано, а весь ввод пошел в текущий открытый файл (к слову, у меня восьми-ядерный мак и 24Гб памяти, а IDE этого не хватает для быстрой работы). Так что пользуюсь ST3, есть настроенный vim, но я никак не приспособлюсь к управлению буферами. Еще у простых но мощных редакторов, таких как vim, emacs, st есть большое преимущество перед java-IDE — маленькие редакторы не жрут память и умеют в большие файлы.BelBES
08.06.2015 10:28Сколько раз я видел разработчиков, которые пользуются боковой панелью с деревом файлов в IDEA, а ведь можно использовать аналог Cmd+T что экономит где-то пол часа в день.
Мне кажется, что проблема неоптимальной скорости работы с кодом больше надуманная. В любом случае мало какой человек может написать и отладить сложного осмысленного кода больше чем 500-1000 строк в день, а при таких объемах именно набор текста дай бог 30% времени занимает даже для людей не умеющих набирать в слепую и постоянно елозящих мышкой по столу)
Еще у простых но мощных редакторов, таких как vim, emacs, st есть большое преимущество перед java-IDE — маленькие редакторы не жрут память и умеют в большие файлы.
Я бы не сказал, что emacs очень легкий и быстрый редактор :) Однопоточность — его слабое место, поэтому даже простые, для полноценных IDE, операции типа коментирования 1000+ строк кода могут заставить emacs подвиснуть) А полноценной многопоточной версии что-то пока на горизонте не наблюдается.n0dwis
08.06.2015 13:01Как раз хотел это написать. Акцентирую внимание ещё раз — при всём удобстве работы с текстом в vim/emacs, нужно ли оно для написания программы? Код больше читается, чем пишется — это уже аксиома. А прочитать, или, точнее, разобраться, гораздо проще в ide, чем в чистом редакторе. И всё благодаря удобной навигации, подсказкам, интеллектуальному автодополнению и т.п.
BelBES
08.06.2015 13:37Ну, лично я в emacs пользуюсь связкой yasnippet + autocomplete (ищет только по открытым буферам) + grep + gdb. Это конечно не абы что, но с практикой становится вполне удобно ходить даже по большим проектам. Просто приходится в голове держать структуру той части проекта, с котрой работаешь в данный момент
n0dwis
08.06.2015 14:52А что насчёт projectile? У меня не получилось нормально с этой штукой работать — тормозит очень, не всегда понимает, что находся в проекте — отказывается искать файлы, каталоги.
DrLivesey
08.06.2015 15:15+1Насчет утешения, я не был бы так однозначен.
Приведу как пример дефолтное автодополнение в MSVS. За счет того, что автодополнение работае по абсолютно всем возможным вариантам можно крайне удивиться тому какие варианты попадаются в списке, когда дополняешь имя локальной переменной объявленой 2мя строками выше.
Дефолтное автодополнение в Vim работае по прямому как стрела принципу: есть в открытом буфере — появляется в списке. Да, такое автодополнение не контекстное зато работает в любом месте файла, например в комментариях.
Verkholantsev
06.06.2015 22:37Как вы профилируете плагины? Как находите узкие места в быстродействии?
Delphinum Автор
07.06.2015 00:26Пока никак. Проблем с быстродействием пока не возникало, как появятся, займусь этим вопросом.
Myshov
07.06.2015 16:33Можно использовать встроенные в vim средства (:help profiling, хотя, есть ограничения), недавно это обсуждалось на vi.stackexchange.com.
mbait
06.06.2015 23:02очень мощный плагин для работы с Git прямо из Vim
так они еще и более функциональные по сравнению с аналогами среди плагинов Vim!
Мне показалось, или в плагине git отсутствует команда diff?
Я думаю, ваше стремление с удовольствием приняли бы в каком-нибудь уже существующем проекте. Например, можете посмотреть VCSCommand. Кажется, когда я пользовался им последний раз, там было, над чем работать.Delphinum Автор
07.06.2015 00:27Мне показалось, или в плагине git отсутствует команда diff?
Она работает в зависимости от контекста, на пример diff между двумя ветками, файлами или коммитами. Я расскажу об этому подробнее в других статьях.
ali_aliev
07.06.2015 10:05+2Могу подсказать расширение для работы с git: vim-fugitive. Есть замечательные скринкасты на эту тему vimcasts.org/episodes/fugitive-vim---a-complement-to-command-line-git
dimas
08.06.2015 00:23понимаете, чем удобен VCSCommand — мне не надо вспоминать кто у меня в текущем проекте — git или svn, оно везде работает одинаково… для текучки это достаточно (лично для меня)… и хоткеями обвешивать вроще…
DmitryKoterov
06.06.2015 23:12Может, кто-нибудь подскажет решение, которое позволяет таскать за собой свой vim-конфиг (а заодно и .profile и еще что-нибудь), на какую бы машину вы ни логинились по ssh, и делать это автоматически (по типу того, как, например, таскаются ключи по ssh ForwardAgent)? При этом было бы идеально, если бы изменять конфиг можно было в любом месте, и он бы везде в момент логина обновлялся (по типа Дропбокса). Может, кто-то написал такую утилиту/сервис уже?
alex_bel
07.06.2015 00:46+1DmitryKoterov
08.06.2015 17:01Да, это похоже. Однако оно, насколько я понимаю, не выживает при цепочке логинов notebook -> server1 -> server2 (хотя ForwardAgent — выживает). Мне видится, что система таскания конфигов, однажды установленная на всех машинах по команде типа «apt-get install ssh-sticky-configs», должна скорее быть завязанной за ключ из ForwardAgent и именно по нему загружать конфиги и заливать их сразу же обратно при изменениях…
dimas
08.06.2015 00:27Так таких решений полно, каждый допиливает для себя…
Так, я просто храню конфиг на гитхабе, там же храню простенький самописный скрипт на питоне, котрый берет лежащий там же конфиг со списком плагинов и все вытаскивает. Поэтому для старта мне надо просто вытащить на локал github.com/dimasg/vim и запустить update_bundles.py (идея позаимствована из лежащего там же update_bundles.rb на руби, внутри есть урл откуда было взято).alaska332
08.06.2015 00:32А я храню в дропбоксе и делаю так:
source <( wget -O — dl.dropbox.com/s/xxxxxxxxxx/vim.sh )dimas
08.06.2015 00:38Неудобно, историю изменений не посмотреть :)
alaska332
08.06.2015 00:39там репозиторий.
dimas
08.06.2015 00:40тем более непонятно: чем дропбокс удобнее?
alaska332
08.06.2015 00:45Ничем.
Так исторически сложилось у меня.
Такой же командой можно выполнить этот скрипт из последнего коммита c гитхаба.
С дропбоксом как-то проще, кроме этого мне это надо для других целей.
Я таким образом получаю доступ и к другим файлам, которые не в репозитории.
Cheater
07.06.2015 00:19-2Респект за проделанную работу, но зачем с языком-то так мучиться было? На Perl/Python/Lua/Tcl давно уже можно писать плагины к Vim.
Delphinum Автор
07.06.2015 00:29К сожалению нельзя. С помощью Perl/Python/Lua/Tcl можно обрабатывать некоторые данные, реализовать сетевое подключение и тому подобное, но вот, скажем, открывать новые окна в Vim (и еще много чего) у вас не получится (на сколько мне известно).
Cheater
07.06.2015 00:53Я писал плагинытолько на Perl, для него есть костыль Vim::Perl (http://metacpan.org/pod/Vim::Perl) — умеет обращаться к VimScript-переменным и выражениям. Но вообще да, доступа абсолютно ко всему, как в VimScript, из перла нет. Про другие языки не знаю, мб к ним есть похожие модули.
Delphinum Автор
07.06.2015 01:07Я решил пойти другим путем, а именно реализовать основную логику (какую возможно) в VimLanguage, а то что уже будет сделать нельзя, реализую в Python (ну или на другом, общедоступном ЯП).
alaska332
07.06.2015 23:16Получится.
Можно любую встроенную команду выполнить из, например, перл плагина.
VIM::Eval({expr})Delphinum Автор
07.06.2015 23:20А как на счет функций?
И так же не стоит забывать, что с такой библиотекой придется требовать от пользователей устанавливать еще и используемый ЯП, чего я не хочу.alaska332
07.06.2015 23:28Ничего ставить дополнительно не надо. Это стандартные возможности. Никакие дополнительные библиотеки решать такие проблемы не могут.
А чем функции отличаются? Если не хватает прямых вызовов апи для конкретного встраиваемого языка — вы всегда можете выполнить кусок vim script в eval и получить результат. Это позволяет снять все ограничения.
Я свои плагины делаю на перле.Delphinum Автор
07.06.2015 23:30Ничего ставить дополнительно не надо
То есть если на машине нет интерпретатора Perl, то его заменит сам Vim?alaska332
07.06.2015 23:33А, вы про это.
Ну да, интерпретатор нужен.
Выше человек писал, что он ставит отдельно доп. модуль к перлу — это ерунда.Delphinum Автор
07.06.2015 23:35Согласен, но если есть возможность решить задачу без использования сторонних ЯП, я сделаю это. Когда же дело дойдет до проблем, с которыми не может справиться VimLanguage, выбиру один из ЯП и буду решать такие проблемы на нем.
alaska332
07.06.2015 23:39-1Ну это очевидно.
В виме все хорошо, кроме VimL, сбросить бы это «наследние мрачных времен»…
ali_aliev
07.06.2015 09:54+1В голосовании я нажал на кнопку воздержаться по следующим причинам:
> Быстрого перехода к объявлениям классов, методов, свойств, переменных и т.д.
jedi-vim (leader+g, leader+d) еще очень приятная комбинация leader+n
> Автоматического завершения ввода с подсказками
Настроил в jedi-vim popup on dot, автокомплит срабатывает например так from django.htt…
Есть для этого еще небольшой и очень удобный скрипт, который я всегда использую
" Auto fill import statement after type from A<space> function! CompleteAndImport() if search('\<from\s\+[A-Za-z0-9._]\+\s*\%#\s*$', 'bcn', line('.')) " Enter character and start completion. return " import \<C-x>\<C-o>" endif return ' ' endfunction inoremap <buffer> <expr> <Space> CompleteAndImport()
то есть, когда мы начинаем ввод from django.http автоматически добавляется ключевое слово import и включается автокомплит (данная фича присутствует и в PyDev, очень удобно)
> Доступа к документации ЯП прямо из Vim
В jedi-vim есть комбинация Shift+K
> Анализатора ошибок
syntastic + flake8
> Готовых snippets для некоторого ЯП (какой, напишу в комментариях)
UltiSnips, на гитхабе полно различных сниппетов для разных языков, ну и emmet еще
> Автоматическое форматирование кода под используемый код-style стандарт
для питона есть прекрасное дополнение github.com/hynek/vim-python-pep8-indent заменяет indent по умолчанию
> Интеграции с таск-трекером
этого действительно нет (а быть может и есть?)
Кстати вопрос для питонистов, сейчас мне не хватает в редакторе только одного: мне нужно, чтобы для импортов в файле, который я открываю автоматически срабатывал фолдинг. Может кто то с таким сталкивался? Так как для больших проектов это было бы очень удобно, бывают импорты на половину экрана.
Latobco
Ждем ответ от поклонников Emacs!
BelBES
Что-то типа: запускаем emacs, подключаем evil mode и сводим задачу к предыдущей ?)
avkoval
Я тут, яволь! ;-) В emacs всего хватает, если говорить о Python: есть быстрые переходы по классам, свойствам, файлам. По файлам|каталогам проекта. Автоматическое завершение ввода (3+ способами). Доступ к документации ЯП прямо из. Доступ к snippets, ну и так далее по списку. В emacs самая большая проблема наверное то, что всё вместе настроить и запомнить куда какая кнопка — нетривиальная задача, это многих отпугивает