На reddit большое комьюнити, которое посвящено vim: neovim, vim, vimplugins, vimporn. И чтобы не пропускать какие-то интересные вещи, которые случаются в мире vim, я накидал bash-скрипт. Скрипт выводит топ-5 лучших постов за год по каждому сабредиту. В статье будет сам скрипт, а также я своими словами расскажу о каждом посте, который попал в топ.
Впервые я познакомился с Vim в университете, и с тех пор он был желанным спутником на протяжении большей части моей карьеры разработчика. Работа с программами на Python и Go казалась мне естественной с Vim, и я всегда чувствовал себя продуктивным. А вот Java была другим зверем. Когда появлялась возможность поработать с Java, я сначала пробовал Vim, но возвращался к IntelliJ и плагину IdeaVim, чтобы воспользоваться богатыми возможностями языка, которые открывает полноценная IDE.
К сожалению, у IntelliJ есть свои проблемы. В случайные, а иногда и в неподходящие моменты она просто перестаёт работать, пока не будут восстановлены все кэши, перезагружены проекты и не будет проведено полдня или больше за работой по устранению её неполадок. Пройдя через всю эту песню несколько месяцев назад, и глядя на прогресс в Vim, Neovim, спецификации протокола языкового сервера (Language Server Protocol, LSP) и их различных реализаций, я подумал, что, возможно, пришло время ещё раз взглянуть на использование Neovim в качестве Java IDE.
Возможно ли это? Да.
Рекомендую ли я это делать? Возможно.
Сошел ли я с ума? Возможно :)
Когда я возобновил публикации про vim летом этого года, я совсем не ожидал, что вскоре прочитаю столь печальную новость.
Я отдыхал две недели, а потом у меня отказал старый ноутбук. Пришлось достать из чулана железку поновее и потратить некоторое время на её настройку.
Привет, Хаброжители!
Будете ли вы использовать markdown или нет, - это вы должны решать сами. Но если вы читаете эту статью, то, очевидно, есть некоторый интерес к теме.
В этом тексте коротко рассказывается о возможностях работы с markdown, которые предоставляет Vim. Vim довольно часто включается в обзоры лучших редакторов markdown. Но небольшие настройки редактора в этом случае всё же существенно облегчают работу.
Краткое введение в vim
Будем мы использовать vim в 2023г.?
Мастер использует тот инструмент, который, по его мнению, даст наилучший результат, независимо от того, используется ли он всеми остальными или нет. А хороший мастер делает свои собственные инструменты, когда это необходимо. Брам Муленар, создатель vim
В этой статье я расскажу о том, как я выстроил работу с терминалом в Linux под себя и какие инструменты использовал для этого.
Сергей хочет открыть Slack. Запускает Spotlight и в нем начинает писать "Slack". Печатается "Ыдфсл". Ок, нужно стереть "Ыдфсл", а для этого эксплуатировать лучезапястный сустав в попытке дотянуться до BACKSPACE... Когда Slack наконец-то(!) открылся, Сергей пишет сообщение и хочет вставить ссылку в текст, используя привычный <CMD+K>, но Slack начинает поиск по личным сообщениям.
Как помочь Сергею, мы сейчас и разберемся. Статья не является туториалом - скорее, набором идей, которые желающий сможет забрать себе.
Теоретически если вы решили пересесть с классического Vim на более современный его клон - Neovim - вам делать ничего особенного не надо. В файле ~/.config/nvim/init.vim прописать source ~/.vimrc ну и скачать или скопировать словари. Идея в том, что Neovim должен поддерживать все конфигурации Vim по умолчанию. Однако, если у вас установлено множество плагинов и разных к ним расширений, то с высокой вероятностью конфигурация загрузится с ошибками, предупреждениями и другими, не очень желательными нюансами. Да и вообще вся фишка, вся разница Neovim заключается в том, что он поддерживает настройки и плагины написанные на Lua вместо vimscript.
Lua - более современный интерпретируемый язык, на нем удобнее писать, его проще читать. А еще, считается, что работает интерпретатор на порядок быстрее родного языка. На счет порядка я бы засомневался, но действительно тяжелые плагины работают вроде как расторопнее и глаже. Впрочем и классический Vim известен не тем, что он медленный или глючный, так что тут спор скорее софистический. А вот с первыми тремя утверждениями я абсолютно согласен.
Более того для Neovim именно на Lua в последнее время выбор современных плагинов и расширений, что уж тут говорить, куда богаче. Вопрос даже не в том лучше ли эти аналоги, а в скорее в свежести, динамике развития и в целом в оптимизме сообщества. Очень похоже на то, что не сегодня так завтра Neovim повторит судьбу предшественника и займет свое место в распространенных дистрибутивах Linux в качестве стандартной замены устаревшему Vim. Заменит полностью? Ну, я бы не был так категоричен в этом вопросе, но вероятность такая существует.
Этот туториал описывает часть функционала плагина «Langmapper.nvim», ссылка на него будет в конце статьи. Для остальных, кто хочет настроить Neovim для работы с русской или другой раскладкой, описаны необходимые шаги и приведён упрощенный код.
Говоря о профессиональном программировании на Java нельзя не отметить, что усредненные сценарии применения несколько отличаются от ранее рассмотренных баз данных и PHP. Разработка будь то бекэнда или мобильных приложений на Java или под JVM всё-таки связана с промышленными и крупными проектами, для которых важна стабильность, быстродействие, кроссплатформеность и прочие плюшки получаемые в комплекте. Не пишут лендинги или отчеты на Java в заметных количествах - на Java, как правило, написаны серьезные системы под руководством крупных компаний не имеющих острого дефицита в финансовых ресурсах. В экосистеме Java cложилась ситуация даже, с некоторой точки зрения, обратная PHP, у которой средства разработки в основном коммерческие, а продукты малопригодные к тиражированию и нужные только владельцам некоторого основного бизнеса. В мире же Java недостатка в бесплатном и довольно качественном инструментарии как будто и нет, но для профессиональных разработчиков нет проблем с тем что бы и приобрести замечательные коммерческие продукты производства JetBrains или специализированные инструменты типа PWS Studio.
Поэтому сценариев когда во что бы то ни стало надо использовать бесплатные инструменты мало. С предложением разработать какой-нибудь продукт на платформе Java скорее всего выйдет какой-нибудь крупный заказчик у которого не возникнет вопросов с предоставлением вам рабочего места или каких-то лицензионных продуктов. Либо вам предложат такую сумму, которая будет подразумевать сопутствующие расходы. Вряд ли, если вы опытный Java разработчик, и у вас есть проблемы с личным оборудованием, которое не потянет последнюю редакцию IntelliJ Idea или Eclipse JDT. Но, да, это если вы действительно опытный специалист.
В этот раз мы научимся работать с окнами и фолдами в Nvim, и в итоге сможем контролировать все те строки кода, которые попадают в поле нашего зрения.
Проекты PHP в данный момент у меня заморожены или переданы коллегам, поэтому толком попрактиковаться в Vim пока особенно не получается. Тем не менее есть что обозначить и пусть данная заметка будет эдаким введением в проблематику. Если на первый взгляд кажется что её нет и вовсе - проблематики, то на второй взгляд становится понятно, что не всё так однозначно и просто, примерно так же как и с базами данных.
Если загуглить "vim php lsp" то с высокой вероятностью вы попадете на проект Intelephence и плагины его использующие. Который платный. Вообще удивительно, но вокруг в общем-то опенсорсного PHP многие компании, с упорством достойным лучшего применения, пытаются создать платную инфраструктуру. Является ли при этом PHP Group каким-то бенефициаром такого положения вещей не совсем очевидно. Тем не менее воз и ныне там - кто только не разрабатывает инструментарий, только не сами авторы. И так сложилось, что лидерами в производстве инструментов являются наиболее жадные коммерческие компании как JetBrains и разработчики указанного Intelephence.
Если вы тот кто считает, что это правильно и нужно поддерживать поддерживать производителя рублем, если вы разработчик промышленных решений - нет проблем - к вашим услугам PhpStorm и Zend Studio. И в них правда нет ничего плохого. Более того, они действительно поддерживают всё и вся связанное с PHP причем самой последней версии. Но, знаете, городить огород с покупкой лицензий для эпизодической поддержки легаси кода, которого нынче значительно больше какого-то передового, мне лично не кажется целесообразным. Только вот с бесплатными инструментами всё несколько запутано.
Что чаще всего нужно программисту от форматирования? Расстановка отступов? Или может быть разбиение списков параметров по вертикали? Следование каким-то конвенциям стиля? А вот и нет. Мне, как программисту, жутко не хватает программы, которая бы расставляла за меня запятые. Ну, или удаляла оттуда там где их быть не должно. На данный момент я так понимаю, можно воспользоваться каким-нибудь онлайн-сервисом или, в лучшем случае, как-то подцепиться к API. Есть на этот счет пара вариантов типа https://text.ru/api-check, https://sinoni.men/ или https://languagetool.org/ru/.
Однако, понятно, это всё ограничено и недешево. Да и это скорее эдакие линтеры, которые могут достаточно хорошо предположить и указать на явные ошибки. Про линтеры отдельный разговор. Вот бы было здорово сделать локальный LSP сервер для русского языка? Как вам идея для стартапа? Я провел достаточно много времени с экспериментами над грамматическим и морфологическим разбором предложений на русском языке. Была даже попытка прикоснуться к лингвистическим корпусам и нейронным сетям. Не могу сказать, что эксперименты закончились чем-то примечательным. Однако могу утверждать, что до определенной степени такую затею вполне можно воплотить даже в одного. Всё зависит лишь от желаемой точности и универсальности продукта. Если, положа руку на сердце, оценить, то как пишут даже вполне грамотные люди, то достичь уровня десятого класса средней школы уже было бы достижением. Если текст состоит не из помеси трех языков, топонимов, имен древнеегипетских богов и сложносочиненных оборотов, коих большинство, то каких-нибудь 90% точности при расстановке запятых и двоеточий хватило бы за глаза.
Существует три основных способа работы с базами данных. В первую очередь, это конечно же родной графический или веб интерфейс. Который, помимо прочего, разбирается как в устройстве СУБД, так и может на лету подгружать структуру текущей БД. Вряд ли кто-то не согласен с тем, что это наиболее удобный способ составления сложных запросов и процедур на целевом диалекте SQL. Да, и сегодня речь конкретно о реляционных БД.
Второй, не менее распространенный способ, это использование, опять же, графического клиента большой комплексной IDE. Отличие заключается в том, что встроенный клиент IDE, как правило, более универсален, использует либо какую-то внешнюю библиотеку-драйвер, и тем самым может быть несколько ограничен возможностями этой библиотеки или степенью поддержки специфических функций. Надо сказать, современные IDE это отличие максимально пытаются нивелировать. Так что для каких-то не самых сложных задач такой способ тоже достаточно оправдан и популярен.
Однако есть и третий сценарий. Это работа с клиентским консольным приложением и вынесенными в файлы скриптами или исходными кодами запросов и объектов БД. Вариант относительно не частый, но он существует. Более того, с внедрением автоматизированных конвейеров развертывания приложений нынче реализуется всё чаще. Современное приложение должно быть способно не только единожды устанавливаться на статическую БД, но и автоматически разворачиваться в виртуальных средах, обновляться и контролировать собственную целостность.
До какой-то степени работать с отдельными файлами можно и при помощи графических клиентов, но это, как правило, довольно таки избыточный процесс - графические средства предназначены всё-таки больше для редактирования объектов и данных в БД "напрямую". Да, в итоге это всё-равно текстовые запросы, но средства отображения и редактирования заточены именно под визуальное взаимодействие. Скрипты же для развертывания и обновления чаще всего не интерактивные и не нуждаются в каком-то форматировании вывода. Естественным образом возникает необходимость в некоем "оперативном" редакторе, который бы запускался быстро и при этом имел какие-то минимальные средства подсветки синтаксиса, автоматического дополнения ключевых слов, форматирования и даже непосредственного исполнения и отладки.
Перед тем как перейти к использованию LSP и более навороченным плагинам предлагаю проникнуться более продвинутыми встроенными функциями Vim дабы освоить те приемы работы, прежде всего с исходным кодом, которые будут доступны вам с нуля на практически любом дистрибутиве в любом удаленном терминале.
Необходимо немного поговорить о способе размещения конфигураций. Существует два радикально противоположных подхода к способу размещения конфигурационных файлов Vim. Одни аккуратно разбивают конфигурацию на несколько файлов и кладут их в разные места, оставляя в основном файле .vimrc только вызовы :source. Это то как бы поступил адекватный программист. Другие не считают конфигурацию Vim настолько серьезным предприятием и советуют класть всё в кучу, поделив настройки лишь на некие логические секции. Общее мнение - не набивать конфигурацию совсем рандомно.
Я бы наверное изначально поступил первым способом и разложил бы всё по неким "модулям", однако с Vim не всё так просто. Дело в том, что различные расширения подгружаются в редактор последовательно и более того часто взаимодействуют друг с другом - зависят друг от дружки. То есть придумать способ организовать файлы, когда в одном месте у нас только горячие клавиши, в другом цветовая схема, по большому счету нельзя. Каждый плагин отдельно будет иметь свои горячие клавиши, возможно какие-то тонкие настройки цвета, интеграцию с другими плагинами.
Кроме этого, в Vim встроены плагин, который подгружает дополнительные конфигурации в зависимости от типа файла (ftplugin). Что делает картину еще более не очевидной. Другими словами, разбивая конфигурацию на отдельные файлы велик риск наоборот только запутать себя. Поэтому предлагаю еще один компромисс.
В основной файл .vimrc я положил только то что будет работать практически в любом случае в любом окружении. И в конце подгрузил ~/.vim/plugins.vim в котором всё то что касается расширений. То есть всё что в директории .vim можно безопасно отключить в любой момент. Внутри же максимально попытался разделить файл на секции с комментариями по которым потом можно будет найти интересующий плагин или его конкретные настройки.
Навигация - визитная карточка Nvim. Мы можем молниеносно перемещаться по коду-тексту, не ограниченные скоростью мыши или человеческими возможностями. Говорят, что эксперименты Либета доказали, что человек сначала перемещается, а потом думает… В колдовском редакторе все будет именно так.
