Если вы недавно начали: 1) пользоваться Sublime Text и/или 2) пользоваться плагином Vintage и/или 3) редактировать много текста на русском (или наоборот английском) языке с использованием ST3+Vintage, то скорее всего уже почувствовали какая боль связана с командами назначенными на символы пунктуации — "$", ";", ".", ",", """ и т.п. В небольшой заметке под катом я хочу предложить вам пару костылей, которые помогают эту боль в значительной степени облегчить.
История одного плагина
12 мин
Туториал
Все началось с того, что у меня перестал работать tagbar. Плагин падал с ошибкой, якобы текущая моя версия Exuberant Ctags вовсе не Exuberant. Покопавшись немного в исходниках, я понял, что последняя внешняя команда завершалась с ошибкой, а v:shell_error выдавал -1, что говорит о том, судя по документации vim'a, что "the command could not be executed". Я не стал копать дальше и установил fzf. Fzf, как и ctrlp, позволяет проводить нечеткий поиск по файлам, тегам, буферам, ..., но в отличии от последнего, работает гораздо шустрее, однако, не без минусов. Приложение работает напрямую с терминалом и каждый раз затирает мне историю вводимых команд. Это также означает, что мы не можем отобразить результаты поиска в буфере (neovim, судя по некоторым скринкастам, может), например, справа от основного буфера, когда ищем нужный тег. В отличие от sublime, fzf не придает больший вес имени файла, из — за чего я часто получал в топе вовсе не те результаты, которые ожидал увидеть. Ко всему прочему, отсутствие полной свободы в настройке цветовой схемы, что в общем-то не слишком важно для обычного пользователя, но только не для меня, с моим повышенным вниманием к мелочам. Под свободой я понимаю, как минимум, разграничение цвета для обычного (нормального) текста и строки запроса.
Всё это подтолкнуло меня к написанию своего плагина, внешний вид которого напоминает стандартный просмотрщик директорий — netrw. Я опишу проблемы, с которыми сталкивался, и пути их решения, полагая, что этот опыт может быть кому-то полезен.
Семантический перенос строк
5 мин
Перевод
От переводчика:
Некоторое время назад на Хабре публиковался перевод статьи под названием "Искусство командной строки". Среди прочего, в статье было рекомендовано освоить vim. Исходник статьи, выложенный на Гитхаб, по иронии судьбы, оказался совершенно непригодным к редактированию именно этим редактором, так как в нём на один абзац приходилась ровно одна строка.
Я тогда выразил своё недоумение автору и попросил его выровнять текст на 80 символов. Но после непродолжительной дискуссии в коментариях дали ссылку на описание форматирования исходников литературных текстов по семантическому принципу. Идея, заложенная в этом принципе в общем довольно простая, но я был поражён её глубиной, которой, пусть и запоздало, хочу поделиться с окружающими.
Хочу предупредить, что не все ссылки в статье работоспособны, но я решил оставить их как есть — мало ли что.
Почему, ну почему, эти #?@! придурки используют vi?
12 мин
Предлагаю читателям "Хабрахабра" перевод статьи "Why, oh WHY, do those #?@! nutheads use vi?" за авторством John Beltran de Heredia.
Да, даже если вы не можете в это поверить, у редактора vi, увидевшего свет более тридцати лет назад (и его более молодого, всего-то пятнадцатилетнего лучшего клона & большого улучшения — vim) очень много фанатов.
Нет, они не динозавры, которые не хотят идти в ногу со временем — сообщество пользователей vi продолжает увеличиваться: я, который начал только два года назад (после десяти лет работы программистом). Мои друзья переходят на vi сейчас. Черт, большинство пользователей vi даже еще не были рождены, когда он был написан!
Да, есть конкретные причины, почему модель редактирования vi/vim превосходит любую другую. Вам не надо быть экспертом в Unix, чтобы использовать vi — он доступен бесплатно практически для любой существующей платформы; для большинства IDE существуют плагины, позволяющие использовать его возможности. Давайте же развеем некоторые заблуждения и рассмотрим пару примеров, демонстрирующих его превосходство.
Текстовые редакторы vs IDE
5 мин
В последнее время наблюдается тенденция бессмысленных, с моей точки зрения, дискуссий относительно того, что лучше, — текстовый редактор или IDE. При этом, в темах, где обсуждается данный вопрос, зачастую 400 и более комментариев. Значит, людей этот вопрос интересует. Значит, надо писать статью.
Итак, какие цели статьи?
1. Что же лучше для программирования: текстовый редактор или IDE
2. Vim и Emacs — не текстовые редакторы
Итак, какие цели статьи?
1. Что же лучше для программирования: текстовый редактор или IDE
2. Vim и Emacs — не текстовые редакторы
Vim и IDE — это разные вещи
3 мин
Увидел очередную статью про vim и IDE и решил поделиться своими мыслями — вдруг кому-то покажутся полезными, чем черт не шутит?..
По сути, статья будет развернутым пояснением идеи, высказанной другим пользователем в комментарии к статье «VIM: зачем, если есть IDE, и как?».
По сути, статья будет развернутым пояснением идеи, высказанной другим пользователем в комментарии к статье «VIM: зачем, если есть IDE, и как?».
Принципиально IDE от редактора отличается тем, что IDE оперирует синтаксическим деревом редактируемого кода на целевом языке (или неким к нему приближением), а редактор оперирует символами и строками.
VIM: зачем, если есть IDE, и как?
4 мин
Сегодня вышел текст о том, как человек перешёл с Sublime на VIM. В комментариях, как обычно это бывает, появились сообщения в духе "Зачем мне тратить время на Vim, если есть IDE, где всё работает?" (люди даже статьи на эти темы пишут). Хотел внести свои пять копеек, но объём написанного плавно перевёл текст из разряда "комментарий" в разряд небольшой статьи.
В целом, всё, что ниже — это вкусовщина, конечно. Нравится вам ваша IDE (или ваш текущий инструмент), да и пожалуйста. Используйте для текущих задач то, чем вы владеете лучше всего, это аксиома эффективной работы. Но если у вас вдруг появилось немного времени на повышение вашей эффективности в целом, то попробую вас заинтересовать именно Vim'ом, сравнивая его с некой обобщенной IDE.
Опыт перехода с Sublime на Vim
22 мин
Данная статья не раскрывает всех премудростей перемещения по тексту или его редактирования. Основные движения можно узнать в vimtutor, остальные комбинации изучаются в процессе работы. Некоторые из них, особо важные в процессе программирования, я освещу позже.
Я достаточно долгое время использовал sublime (около 4 лет) в качестве основной среды разработки, но в последнее время кое-что изменилось: я освоил слепой 9-ти пальцевый метод печати. В тот момент я начал понимать людей, которым неудобно тянуться к мышке или стрелочкам. Убирать пальцы с «домашних» позиций стало неестественно и непродуктивно. Тогда я включил vintage. Проблема, вроде бы, стала неактуальна, но чего-то не хватало. Не помню, что заставило меня пересесть за vim, но мне всегда нравилось, как в нем выделяются фигурные скобки (MatchParen) и как выглядит курсор :). Vim я пробовал и до этого, когда правил конфиги на сервере, правда, вся «магия» ограничивалась переходом в режим вставки и успешным сохранением/выходом из редактора.
Humane VimScript: Инициализация редактора
5 мин
Введение
При каждом запуске редактора Vim, им выполняется процесс инициализации, обеспечивающий удобный интерфейс для пользователя. На первый взгляд модель инициализации может показаться простой и понятно, но это далеко не так.
В этой статье я предлагаю вам ознакомиться с процессом инициализации редактора Vim. Данную тему я считаю одной из наиболее сложных в ходе изучения редактора, от чего материал, изложенный мной, может быть очень полезен как новичкам, начинающим этот тернистый путь, так и опытным пользователям и разработчикам.
Сложность этой темы обусловлена нетривиальной моделью загрузки скриптов редактора, а так же количеством групп, на которые эти скрипты делятся. Запомнить порядок инициализации редактора достаточно сложно, но это очень важно для написания собственных плагинов для него.
Что нового в Vim 8
2 мин
В репозитории Vim на Github появился первый черновик документации для версии Vim 8.0. В нём указано, что исправлено большое количество багов и добавлено несколько новых фич.Асинхронный ввод/вывод, каналы
Vim теперь умеет обмениваться сообщениями с другим процессом в фоне (например, с сервером Python). Сообщения принимаются и обрабатываются, когда Vim ожидает ввода символа.
С каналами связана широкая поддержка JSON, его легко использовать для коммуникации между процессами, что позволяет написать сервер на любом языке. Используются функции
|json_encode()| и |json_decode()|.Humane VimScript: минималистичная объектная ориентация
4 мин
Я считаю VimScript крайне недружелюбным, но неожиданно мощным языком. К счастью его возможно одружелюбить, чем я и предлагаю вам заняться в этом цикле статей. Здесь мы рассмотрим некоторые решения типичных задач на VimScript с использованием объектно-ориентированной парадигмы, но не будем касаться основ этого языка. Возможно статья будет интересна так же программистам, интересующимся нестандартной реализацией ставших нам привычными решений.
Oбновление Vim FileStyle
1 мин
О прошлом
В декабре прошлого года, я писал о плагине который позволяет при открытии файла увидеть несоблюдение некоторых аспектов кодинг стандарта.
Прошло время и плагин получил новый функционал.
Работа с цветом в vim
3 мин
Казалось бы текстовый редактор не предназначен для работы с цветовыми палитрами, обычно для этого используют специальные программы, одной из неплохих программ подобного рода, например, является GPick.
Специализированные программы для редактирования html в лучшем случае предлагают простой диалог для выбора цвета из списка или цветового круга. Но vim и здесь демонстрирует выдающиеся качества — расширяемость, универсальность и способность работать без мыши, с одной клавиатурой.
Специализированные программы для редактирования html в лучшем случае предлагают простой диалог для выбора цвета из списка или цветового круга. Но vim и здесь демонстрирует выдающиеся качества — расширяемость, универсальность и способность работать без мыши, с одной клавиатурой.
Ближайшие события
Vim как не IDE
5 мин
Очень давно хотел написать что-нибудь полезное, но не знал, чем можно поделится, и тут наткнулся на очередную статью про рассуждения, что же все-таки лучше — vim, emacs или IDE? Сначала я хотел написать сравнение IDE и vim, но слишком мало пользовался IDE и боюсь быть необъективным. Поэтому просто опишу причины, по которым использую vim. Просто чтобы показать, что редакторы занимают свою нишу. Также попробую рассказать о проблемах, с которыми я столкнулся, используя vim, и как я их решал.
Редактор или IDE? Очередная попытка анализа
6 мин
Хотелось бы в очередной раз поднять эту довольно спорную тему.
С тех пор, как я начал заниматься программированием, этот вопрос не даёт мне покоя, а многочисленные темы на форумах и хабре ясности не внесли. Плюс к этому, мне кажется, некоторые аргументы как за одну, так и за другую сторону не были приведены. А у тех, что приведены, неверно расставлены приоритеты и упущен контекст.
В статье я постараюсь исправить это упущение и расставить ещё немного точек над «ё».
Приглашаю всех поучавствовать в поисках идеального инструмента.
С тех пор, как я начал заниматься программированием, этот вопрос не даёт мне покоя, а многочисленные темы на форумах и хабре ясности не внесли. Плюс к этому, мне кажется, некоторые аргументы как за одну, так и за другую сторону не были приведены. А у тех, что приведены, неверно расставлены приоритеты и упущен контекст.
В статье я постараюсь исправить это упущение и расставить ещё немного точек над «ё».
Приглашаю всех поучавствовать в поисках идеального инструмента.
Vim по полной: Библиотека, на которой все держится
10 мин
Оглавление
- Введение (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 нет библиотек, решающих множество базовых задач, отчего все авторы плагинов постоянно наступают на одни и те же грабли. В этой статье я постараюсь освятить решение этой проблемы.
Vim по полной: Тестирование с помощью xUnit
3 мин
Оглавление
- Введение (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)
- Другие полезные плагины
Мне еще не приходилось работать в компаниях, которые тестируют свой код так, как это положено делать для последующего сопровождения и рефакторинга. В России даже крупные IT компании избегают процесс модульного тестирования, не говоря уже об общесистемном, что приводит к тоннам затхлого и окаменевшего кода. Да, я считаю, что тестируемый код, это качественный код, но почему же люди этого избегают? Как я понял, причины две:
- Незнание методологий и инструментов тестирования
- Сложность в запуске тест-случаев (test-case)
Первая проблема вне темы этой статьи, а вот вторую, особенно для пользователей редактора Vim, я постараюсь здесь решить.
Vim по полной: Деплой
3 мин
Оглавление
- Введение (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)
- Другие полезные плагины
Мне нравится, когда клиент может сразу увидеть результаты моих трудов. Я могу корректировать развитие проекта согласно желаниям заказчика, что сильно спасает от недопонимания. Думаю и клиенты не против быть в курсе, куда уходит бюджет и на каком этапе их проект. Добиться этого достаточно просто, благо есть даже целая методология, называемая «Непрерывной интерграцией», позволяющая в кратчайшие сроки деплоить мелкие изменения, но как сделать, чтобы это было достаточно удобно для программиста? Ведь никому не хочется писать код, а после переключаться в контекст системы деплоя или даже использовать ssh соединение чтобы развернуть мелкие изменения на продакшене (или на dev сервере).
Именно нежелание часто переключать внимание между редактором и системой деплоя побудило меня реализовать плагин, о котором я вам хочу рассказать.
Vim по полной: Работа с Git
6 мин
Оглавление
- Введение (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)
- Другие полезные плагины
Часто ли вам приходится использовать Git? В смысле, вы коммитите изменения каждый час или каждые несколько минут? Я делаю это очень часто и не слежу за чистотой репозитория, так как считаю его не более чем журналом изменений, а не произведением искусства. Такой подход требует от редактора хорошей интеграцией с Git, позволяющей в пару нажатий клавиш создать новый коммит, вернуться в прежнее состояние, перейти на другую ветку и так далее. Если вы используете современную среду разработки, в которой реализована интеграция с Git, вам очень повезло, но что делать пользователям редактора Vim? Есть ли плагин, который не просто реализует Vim-команды по тиму GitCommit, GitCheckout и GitBranch, а предоставляет удобный интерфейс в лучших традициях редактора?
Vim по полной: Компиляция и выполнение чего угодно
3 мин
Оглавление
- Введение (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)
- Другие полезные плагины
Как можно назвать редактор удобным, если он не умеет запускать то, что мы программируем? Особенностью описываемого мной в данной статье плагина, является возможность запуска чего угодно, будь то программный код, plantUML, LaTeX, Less и всего, что можно написать и запустить. Плагин vim-quickrun может показаться довольно запутанным и сложным, не смотря на прекрасную документацию, потому я решил коротко осветить его в этой статье, дабы вы могли быстрее начать им пользоваться.