Comments 252
vim очень хорош в плане редактирования текста, безусловно. Но чтобы заменить полноценную IDE в моей вселенной ему надо научится эффективно использовать мульти-мониторную конфигурацию, когда например исходники программы в одном рабочем столе, а стек-трейс и содержимое переменных к нему в другом. Как у него с этим?
Запустите в одном окне терминала Вим, а в другом — дебаггер и перетащите их в разные окна
*на разные экраны
И кроме отладчика, как бысть с остальными данными? В работе у меня обычно на отдельном мониторе помимо отладчика: список предупреждений/ошибок, результаты поиска, список использований и т.п. Конечно, можно в отдельных окнах пооткрывать терминалы и там делать например grep, но это всё медленно будет до ужаса и без обратной связи.
Сейчас даже GUI реализации Вима при создании нового окна просто открывают новый инстанс редактора. Подобное решение происходит из того, что он — программа консольная, из чего следуют эти ограничения (при открытии нового виртуального терминала вы тоже, считайте, входите в новую сессию). Полная поддержка нескольких мониторов появится, когда разработчики начнут уделять больше времени GUI версиям.
Пока единственное решение проблемы, которое я вижу, — сделать плагин, который будет дампить данные об предупреждениях и ошибках (и прочее) во временные скрытые файлы и открывать их в новой сессии Вима, но подобных готовых решений вроде нет.
Можно также купить широкоформатный монитор или привыкнуть к идеологии минимализма, но это не решение самой проблемы
Но чтобы заменить полноценную IDE в моей вселенной ему надо научится эффективно использовать мульти-мониторную конфигурацию, когда например исходники программы в одном рабочем столе, а стек-трейс и содержимое переменных к нему в другом. Как у него с этим?
vim — не IDE, а программистский настраиваемый редактор.
Так же как и Sublime, Atom и т.п.
И с просмотром переменных у него так себе.
У него все хорошо с автодополнениями, проверкой синтаксиса и ее подсветкой, шаблонами/сниппетами, подсветкой и закрытием тегов, скобок и парных операторов.
Но интерактивная отладка — это не сильный конек подобных инструментов.
Это не так. К тому же — что значит работа с UI? Рисовать формочки в дизайнере?
Ну, так извините — разработка не ограничивается фронтом. Есть еще бекендеры, которым УИ до одного места. И системные инженеры, которые фигачат инфраструктурный код… Им реально нужен редактор + расширенный функции по рефакторингу и автоподстановкам. БД — да, но там удобнее отдельные инструменты (типа DataGrip).
И как с помощью vim сделать рефакторинг по выделению интерфейса из класса?
И как с помощью vim сделать рефакторинг по выделению интерфейса из класса?
Ваш вопрос смысла лишен.
vim — это база, основа. На котором уже надстраиваются плагины под конкретную ситуацию, под конкретный язык.
Рефакторинг с Go и vim, к примеру, делается с использованием инструментов golang.org/x/tools/cmd/guru и golang.org/x/tools/cmd/gorename. С помощью планига go-vim эти инструменты интегрируются с vim и — вуаля, рефакторите как хотите.
vim — это база, основа.
Вот именно
На котором уже надстраиваются плагины под конкретную ситуацию, под конкретный язык.
И вот сборка из этих плагинов будет иметь меньше фич, чем IDE, заточенная под конкретный язык. Суровая правда жизни (((
И вот сборка из этих плагинов будет иметь меньше фич, чем IDE, заточенная под конкретный язык. Суровая правда жизни (((
1) Это касается только массово распространенных языков. Для тех, что еще не стали широкораспространенными и/или никогда не станут таковыми — IDE или не существуют или они убоги. Как пример, Go. При всём многолетнем уже хайпе/победоносном шествии Go в серьезных/тяжелых проектах нормальная поддержка в IDE появлась только в этом году. До этого vim (с плагинами конечно) предлагал ровно такой же функционал что и предлагали IDE.
2) IDE дают это всё далеко не бесплатно. И в смысле потребных им ресурсов. А иногда и в смысле денег. Именно поэтому на ноутбуке в дороге я пользуюсь vim, а на мощном десктопе — Jetbrains IDE.
3) Из принципиальных преимуществ IDE — пошаговая отладка, видеть/менять переменные вживую. Но, скажем, в моей ситуации — при отладке микросервисов, логи куда как более полезны, чем брейкпойнты в многопоточном коде. А всё кроме этого в vim/Atom/Sublime/emacs — уже есть.
Это касается только массово распространенных языков.
Есть такой момент.
Для тех, что еще не стали широкораспространенными и/или никогда не станут таковыми — IDE или не существуют или они убоги.
Наверное настанет такой момент, когда плагин для IDE будет написать легче, чем плагин для vim, но вроде пока не настал.
Именно поэтому на ноутбуке в дороге я пользуюсь vim, а на мощном десктопе — Jetbrains IDE.
Если вы действительно используете vim на ноутбуке потому, что IDEA слишком прожорливая, то имеет смысл начать копить на новый ноутбук с быстрым процессором и большим количеством оперативной памяти. Хотя вроде из моего опыта следует, что i7 U восьмого поколения и 16 гигабайт оперативной памяти в общем хватает.
Важный вопрос. Какие плагины у вас установлены в Jetbrains IDE?
Если вы действительно используете vim на ноутбуке потому, что IDEA слишком прожорливая, то имеет смысл начать копить на новый ноутбук с быстрым процессором и большим количеством оперативной памяти.
Спасибо за подсказку, но и без умных ваших советов — у меня MacBook Pro свежий в околотоповой конфигурации.
Дело в расходе аккумулятора при автономной работе.
Да, я знаю про режим экономии электроэнергии у IDE Jetbrains. Но при его включении IDE превращается практически в тыкву — мало что может, чего ожидаешь получить от современной IDE.
Важный вопрос. Какие плагины у вас установлены в Jetbrains IDE?
Дефолтные в среде Jetbrains IDE для Go и EmmyLua и Vim-эмулятор. Вроде все.
Спасибо за подсказку, но и без умных ваших советов — у меня MacBook Pro свежий в околотоповой конфигурации. Дело в расходе аккумулятора при автономной работе.
И получается, что вам лучше долгое время работать в виме, чем какое-то недолгое в идее. Из этого я делаю вывод, что по фичам у Идеи и вима получается плюс минус паритет. А почему когда есть мощный десктоп вы предпочитаете Идею? Что там такого хорошего?
А почему когда есть мощный десктоп вы предпочитаете Идею? Что там такого хорошего?
Ибо «хочу все знать». Любопытство.
Ну и куча интересных причин — Windows на десктопе (MacOS на шустром десктопе — это слишком радикально и дорого; Linux же, извините, подключивает, пытался неоднократно — то принтер отваливается, то видеокарта), а vim на Windows не очень комфортен; и любопытство, чтобы все же самому сделать выводы, а не просто начитаться чужих мыслей на форумах и только на этом основании «спорить о вкусе устриц с теми, кто их ел», но для этого нужно и то и то попробовать самому…
Кстати, именно потому что я лично опробовал оба варианта длительное время — могу точно сказать — лишь совсем недавно механизмы подсказок (auto-completion) и пошаговая отладка в IDE Jetbrains для Go стали принципиально удобнее, чем в vim. Еще только в том году у IDE Jetbrains преимуществ не было от слова вообще. Но я надеялся и ждал, веря, что та фирма веников не вяжет.
P.S.:
Кстати плагины Go для vim тоже развиваются.
Язык какой? Или сферический рефакторинг в вакууме? Ну, так извините — не любой IDE позволит рефакторить код на любом языке.
Язык какой?
Давайте Джаву, мне она актуальна
Давайте Джаву, мне она актуальна
Java как раз неудачный пример, один из немногих.
Под Java уже лет 20 как целенаправленно точит свой софт Jetbrains. А их IDE — одни из лучших на планете.
Решения есть и для Java, конечно, eclim.org/vim/java/refactor.html
Java как раз неудачный пример, один из немногих.
К джаве нужно добавить ещё C#, C++, Kotlin, Groovy, Scala, TypeScript, возможно JavaScript, не уверен. Подозреваю, что ещё в этот список попадут Go, Ruby и Python.
Под Java уже лет 20 как целенаправленно точит свой софт Jetbrains. А их IDE — одни из лучших на планете.
Ну во-первых не только под Java, а во вторых кроме JetBrains есть ещё и другие конторы )))
Решения есть и для Java, конечно
Конечно есть. И они, увы, хуже того, что есть в IDE.
Вот Жаба — чуть ли не самый лучший пример превосходства IDE над вимом. Шарп, наверное, на втором месте. Благодаря дизайну языка.
Чуть шаг в сторону от Джавы — всё становится хуже. Даже для такого старого и популярного языка как C++ выгоды IDE уже не так очевидны. Разобрать 100500 макросов и шаблонов, понять в контексте какого шаблонного значения вы хотите сделать поиск или рефакторинг — и добро пожаловать в ад. Особенно хорошо это заметно при взгляде на VS — вроде бы, одна и та же IDE, а работа с шарпом и работа с плюсами — две большие разницы.
Чуть шаг в сторону от Джавы — всё становится хуже. Даже для такого старого и популярного языка как C++ выгоды IDE уже не так очевидны.
Для С++ IDE дело сдвинулось с мёртвой точки только тогда, когда появился clang, тут дело как раз в том, что язык старый и IDE для него, как я заметил, раньше больше акцентировались на отладке и кодогенерации.
А чем новее язык, тем проще для него сделать IDE, вот как-то так выходит.
Не знаю, как сейчас (сам вимоид), но лет 5 назад студия пыталась много чего поддерживать. В простых хелловорлдах инспекция кода, рефакторинги, и прочее работало хорошо и быстро. Но такого же нигде нет, всё заросло шаблонами и тоннами ифдефов и инклюдов.
Дело именно в языке. Не хочу умалять труд гениев из JetBrains, но Ява видимо хорошо устроена для IDE.
airline->lightline хотя бы потому что писать свои дополнения к нему проще
YouCompleteMe->coc проще собирается-устанавливается.
Про Powerline говорить уже нет никакого смысла, он скорее мёртв, чем жив, проект со шрифтами только и остался.
let &t_SI.="\e[5 q" "SI = режим вставки
let &t_SR.="\e[3 q" "SR = режим замены
let &t_EI.="\e[1 q" "EI = нормальный режимХорошо, но имеет смысл в контексте эмулятора терминала и/или мультиплексора. Для tmux это всё несколько забавней выглядит.
Не увидел let mapleader=","
Для консольного vim:
silent !stty -ixon
autocmd VimLeave * silent !stty ixon просто потому что я привык по C-s сохранять буфер (привычка вредная, но что есть, то есть), а не фризить терминал.
airline->lightline хотя бы потому что писать свои дополнения к нему проще
Имхо потому что lightline легче.
YouCompleteMe->coc проще собирается-устанавливается.
Имхо github.com/Shougo/deoplete.nvim потому что асинхронность.
Сделан для neovim, но с плагинами дополнительными, обеспечивающими совместимость, работает и в vim 8.1 — лично использую.
P.S.:
YouCompleteMe сложно устанавливать только под Windows без WSL.
На Linux/FreeBSD/WSL — устанавливается по инструкции с полпинка.
Имхо github.com/Shougo/deoplete.nvim потому что асинхронность.
Я за coc, потому что https://github.com/neoclide/coc.nvim/wiki/Using-coc-extensions ну и не заметил проблем с асинхронностью. Короче, вкусовщина и YCM уже не торт.
YouCompleteMe сложно устанавливать только под Windows без WSL.
На маке там тоже квест был.
Было бы здорово, если бы кто-нибудь про emacs написал подобное.
https://www.youtube.com/watch?v=qjUglyGa-vA Про emacs видяшку знаю, в начале там правда чуток по i3
Сначала, у меня был один .vimrc to rule them all, но когда плагинов становится больше дюжины, становится сложно отслеживать настройки. Некоторые опции (deoplete) надо было настраивать до загрузки плагинов, некоторые — после. Что-то настраивалось через `let g:...`, что-то через `call plugin#function(...`. Потом я разбил на много файликов, отдельно для каждого плагина и source'ил их из .vimrc — стало легче читать, но сложнее редактировать. С Literate .vimrc стало возможным накидать markdown-якорей по конфигу, заголовков, нумерованных списков, e.t.c., а потом просматривать всё в браузере через markdow-preview.
Странно, что чем больше практикуешься в программировании, тем меньше стоит вопрос скорости написания кода. Ведь программирование это о решении проблем. Фризы IDE не вызывают какого-то особого раздражения и желания переходить на текстовые редакторы.
Дело не в скорости.
Дело в комфорте.
Фризы IDE тянут за собой спотыкание мысли.
P.S.:
Более 30 лет в программировании.
vim освоил лет 5 назад для оптимизации работы с клавиатурой/мышью на нотубуках в дороге и для снижения риска RSI (отказ от мыши так как не всегда удобный стол, а тач-пад запястьями задеваешь; меньше тянуться к клавишам-модификаторам, меньше выкручивать пальцы)
Фризы IDE не вызывают какого-то особого раздражения и желания переходить на текстовые редакторы.
P.P.S.:
Разные инструменты для разных целей:
На мощном десктопе использую IDE Jetbrains.
В дороге при питании ноута от аккумулятора использую vim. На серверах удаленно — разумеется тоже vim (причем даже можно и без плагинов, голый дефолтный vim)
Да, я в курсе, что у IDE Jetbrains есть режим экономии электроэнергии. Но при этом отключается значительная часть функционала, того что и превращает продукты Jetbrains в настоящую полноценную крутую IDE.
Правда, vim на плюсах тоже так себе ведёт, у него там даже подсветка ломается периодически.
Просто откройте для себя асинхронность и замените старые синхронные плагины на новые асинхронные.
Это сравнительная новинка в vim. Возможно, что ваши плагины еще под vim 7 написаны, где не было асинхронности.
После перехода на современные реинкарнации плагинов раздражающая вас в vim проблема (что и меня раздражала) — исчезла.
Если бы кто-нибудь рассказал, как это делать в vim, было бы гораздо полезнее, как мне кажется.
Сколько читаю, до сих пор не понял, как в vim вызвать автодополнение при наборе текста, какой командой?
Это?
github.com/Shougo/deoplete.nvim
Если новый vim, тот, что с поддержкой асинхронности.
Это?Да, похоже на то, что нужно! Но почему-то кажется, что «новый vim, тот, что с поддержкой асинхронности», уверенно движется в сторону Visual Studio с каким-нибудь Visual-Assist, судя по видеоскриншотам по ссылке. Если бы не сказали что это vim, подумал бы, что какой-нибудь привычный современный IDE, а там любой дурак работать сможет, ну типа меня. А вообще хотелось бы как раз расширить кругозор, вкусить прелестей особого пути vim, не такого как у всех, более продуктивного и по итогу удобного (когда поймешь и проникнешься, естественно).
Если бы не сказали что это vim, подумал бы, что какой-нибудь привычный современный IDE, а там любой дурак работать сможет, ну типа меня.
Нет. Он не туда движется. В последних версиях добавлена асинхронность, встроенный менеджер плагинова, собственные терминалы…
Но чистый vim — очень скромен по внешнему виду.
Вам придется самому его кастомизировать, чтобы получить то, что вы упоминаете. Это не сам vim — это всё его плагины. Само ядро vim реализует только базовый функционал, он используется как фундамент для планинов.
Кстати, рекомендую статью Ian Langworth. Vim спустя 15 лет и полезные комментарии под ней.
Там у автора больше опыта и более полезная подборка.
В этой же статье, под которой мы вами пишем свои комментарии — часть советов базируется на устаревших технологиях. Хотя отмечаю целеустремленность автора этой статьи и объемный и хорошо организованный материал.
Сколько читаю, до сих пор не понял, как в vim вызвать автодополнение при наборе текста, какой командой?
Ctrl-X Ctrl-O, например, и не забываем про то, что в виме документировано практически всё:
:he ins-completion
Попробуйте https://github.com/neoclide/coc.nvim — всё перечисленное в нем есть, настраивается легко.
Напоминает сборку опенстека руками. :-)
Думаю, vim пользовался бы куда большей популярностью, если бы были готовые сборки для широко распространенных задач. Для большинства хватает настроек по умолчанию, а остальные легко затюнят под себя небольшие мелочи. Делать же каждому вот это вот from scratch — ну, такое себе…
Готовые сборки есть. Например, https://github.com/SpaceVim/SpaceVim
Думаю, vim пользовался бы куда большей популярностью, если бы были готовые сборки для широко распространенных задач.
Их полным-полно.
То, что лично вы о них не знаете — совсем не означает, что таковых нет.
Тоже раньше пользовался vim-ом. Как на linux, так и на windows. На винде сейчас использую редактор far manager-а. Удобная быстрая отзывчивая штука, и совсем не требует настройки.
Тоже раньше пользовался vim-ом. Как на linux, так и на windows. На винде сейчас использую редактор far manager-а. Удобная быстрая отзывчивая штука, и совсем не требует настройки.
Голый без настройки FAR?
Голый vim тоже умеет быть нормальным простым редактором, когда он без настройки.
Ну у меня, конечно, есть парочка своих макросов. Я не говорю, что редактор far хуже или лучше vim-а. Но в far как в файловый менеджер в связке с текстовым редактором лично для меня закрывает необходимость ставить vim.
Но в far как в файловый менеджер в связке с текстовым редактором лично для меня закрывает необходимость ставить vim.
Дык согласен.
И практикую тоже.
И есть знакомые, что прямо таки в FAR и занимаются разработкой.
В виме для есть netrw, некоторые меняют его на другие, например, nerdtree.
У меня vim-dirvish как минимальный файл браузер и vim-eunuch для простых операций над файлами. А так, в-основном, fzf для удобного переключения между файлами/буферами.
Но FAR намного более удобен как файловый мендежер — ибо он для этого и рожден.
Я даже задумывался — а почему собственно большому числу людей (и моих знакомых и мне) FAR столь удобен как замена IDE, при том, что и близко нет функционала IDE.
Теперь тестирую Denite от него же в качестве замены FZF и Bufergator.
vim ценен не тем, что он текстовый редактор, а тем, что он модальный текстовый редактор. Сравнивать vim и фаровский редактор, да ещё в разрезе лучше/хуже, ну такое себе.
О да, исследуя ее мир я впервые почувствовал нечто, чему после некоторых поисков нашел название — Моно но аварэ, собственно оттуда и начался интерес к японской эстетике
Спасибо за отличную статью, много нового узнал.
Но пожалуйста, пишите комменты в коде на английском. Использовать национальные языки в программировании/конфигурировании — это ужасно.
Ничего ужасного, чистая вкусовщина. Мне, например, нравится — выделяет комментарий даже без цветовой разметки. И вообще, билингвизм — наше достоинство.
Не совсем вкусовщина. В команде всегда есть куча иностранцев, не владеющих языком. А если их нет, то наверно компания очень маленькая и деревенская. Поэтому комменты на родном языке и есть признак местечковости.
Кстати, билингвальность — это немножко другое. Это не про знание двух языков, а про владением ими с детства.
Не совсем вкусовщина. В команде всегда есть куча иностранцев, не владеющих языком. А если их нет, то наверно компания очень маленькая и деревенская.
Отнюдь.
Полагаете, скажем, в Яндексе на английском ради 0,01% инстранных сотрудников говорят.
Локализация комментариев в коде. Лекция Яндекса
Но даже если не брать во внимание проблемы Яндекса, а говорить о небольших проектах. Ну не знаю, мещанство это какое-то. Безкультурие чтоли. Это не объяснить, это чувствовать надо.
В процессе выхода на международный рынок с API Карт мы решили отказаться от комментирования кода на русском языке.
Было бы странно, если бы они этого не сделали при выходе на международный рынок. Ибо там же написано следующее во втором предложении:
При этом на основе комментариев формируются справочники сервиса, которые затем публикуются у нас на портале
Однако «отказаться от комментариев на русском» как бы намекает — что комментарии на русском в Яндексе вполне себе по-умолчанию/норма.
Ну не знаю, мещанство это какое-то. Безкультурие чтоли
Да ладно.
Было бы интересно поглядеть на ваши глаза, когда вы пытаетесь понять по-английски фразы специфической предметной области типа «вычет на детей от налога с доходов физических лиц».
Комментарии пишутся не для понтов, не для того чтобы показать какой я крутой и международный, что я не деревня — а для решения вполне конкретных задач, чтобы другому программисту было понятно.
- Для тренировки в английском в собственном личном проекте — да, это можно понять.
- Когда это действительно нужно коллегам, не знающим русский, — да это логично.
- Но когда вы вносите в проект, на 100% разрабатываемый русскоязычной командой, дополнительные сложности, создаете риски недопонимания, только потому, чтобы кому-то доказать, что вы не деревня — неправильно это как-то.
чтобы в проекте со 100% русскоязычными разработчиками кому-то доказывать, что вы не деревня, гм… а вы уверены, что вами не манипулируют?
Немножко грубо прозвучит — сразу извиняюсь, но уж больно классная аллегория, не могу отказаться.
Вы уверены, что когда вас просят не мочиться на людях, вами не манипулируют? Потому что очень удобно мочиться на траву с тротуара, когда приспичило, а не рисковать и терпеть до дома. Зачем показывать, что вы не деревня и не мочитесь на людях? Кому вы хотите пыль в глаза пустить?
Вам бы понять одну простую истину: культура — это всегда что-то иррациональное. Нерационально смотреть картины, нерационально не материться при женщинах, нерационально слушать музыку, нерационально носить сюртуки и шляпы — это все для наших гуманитарных/эмоциональных потребностей, а не потому что есть четкое логическое обоснование данного поведения.
Так вот у программирования тоже есть культура. И культурный человек — это человек, который ведет себя культурно даже там, где это другие не видят. Ему не нужно обоснование "ну ведь у нас нет иностранцев". Потому что культура — это не Потёмкинские деревни.
Так вот у программирования тоже есть культура. И культурный человек — это человек, который ведет себя культурно даже там, где это другие не видят. Ему не нужно обоснование «ну ведь у нас нет иностранцев». Потому что культура — это не Потёмкинские деревни.
Слабая аргументация.
Вы так думаете? По моему, лучше не скажешь...
Вы так думаете? По моему, лучше не скажешь...
Подробно что такое культура и бескультурие в программировании рассказал рядом:
habr.com/en/post/468265/#comment_20693581
Так вот у программирования тоже есть культура.
Культура в программировании не та, что вам кажется. Это не стремление доказать, что то что ты может писать «как-то по-международному». Ибо программирую больше 30 лет — знаю.
Писать код/комментарии, которые коллеги смогут понять однозначно — это да, это культура программирования.
Но писать не так чтобы коллеги максимально однозначно понимали — это как раз безкультурие в программировании.
Чтобы там не говорили, что программист должен знать английский — все же большинство знает его весьма средненько-посредственно.
Если проект международный — да, тут нужно только на английском, не важно как ты его знаешь. Деваться некуда. Имеем риск косяков, но все равно нужно.
Если на код будут глядеть только русскоязычные разработчики — стремление выпендрится со знанием английского — запросто сыграет злую шутку.
Сколько-нибудь сложные вещи в англоязычных комментариях будут наверняка и написанны неграмотно и поняты некорректно, даже если грамотно написаны.
Если комментарий относится к предметной области, а не непосредственно к кодированию — это запросто может быть нетривиальная фраза, которую вам даже на родном языке будет непросто сформулировать и непросто на родном понять.
Не совсем вкусовщина. В команде всегда есть куча иностранцев, не владеющих языком.
Мы здесь таки в контексте. На русском сайте. Эту статью читают только люди, хорошо владеющие русским.
Кстати, билингвальность — это немножко другое. Это не про знание двух языков, а про владением ими с детства.
Говорят, даже минимальный уровень знакомства с другим языком бывает полезен. Расширяет кругозор и число идей, которые могут придти в голову. Скажем, в русских сказках нет лис-самцов. И мультик "губка Боб" (про мальчика) в России бы никогда не сняли. Потому что лиса и губка в русском — женского рода. Например.
Нет никаких причин не писать комментарии на английском. И есть причины не писать их на русском. Нельзя предсказать будущее, нельзя гарантировать, что ваш код никогда не попадёт на глаза нерусскоязычному. А если даже и не попадёт, так что с того?
Нет никаких объективных причин упрекать в использовании русских комментариев на русском сайте, в русской статье. Об этом был мой комментарий.
Когда разговор об общем коде или общении в (хотя бы потенциально) интернациональной компании — другое дело. Сам в такой работаю, всегда топлю за английский.
Нет никаких причин не писать комментарии на английском. И есть причины не писать их на русском. Нельзя предсказать будущее, нельзя гарантировать, что ваш код никогда не попадёт на глаза нерусскоязычному. А если даже и не попадёт, так что с того?
Дык легко найти причины:
Уровень познаний в английском у наших программистов редко когда очень уж хороший.
Да, нужно знать, «язык профессии».
Однако фактически:
Один плохо знающий выразил свою мысль неоднозначно на неродном. Второй плохо знающий эту мысль понял еще более криво.
А если комментарий не про само программирование, а про предметную область — ситуация усугубляется: можно и на родном сидеть и тупить над фразами типа «вычет на детей с налога на доходы физических лиц»
А с английским вероятность получить полное искажение смысла как в игре «Испорченный телефон» — довольно высока.
Оставлю здесь ссылку на проект с годной сборкой вима:
https://spacevim.org/
Вдруг кому-то пригодится.
Спасибо за хорошую статью и популяризацию хорошего редактора!
Лет 7-8 сидел на (нео)виме, до сих пор им пользуюсь. Justinmk, tpope, junegunn и многие другие — очень им благодарен за их труд...
Пару месяцев назад решил-таки попробовать emacs+evil. Несмотря на все его (для меня незначительные) косяки, радуюсь до сих пор как ребёнок. :D После Vimscript, elisp — просто счастье. Fugitive — это хорошо, но Magit — это Magit :D Projectile, опять же. По ощущению, всё, чего мне не хватало в виме, есть в emacs. Жаль, что их нельзя как-то объединить.
Человечеством ещё не было придумано более удобного способа пользоваться Git, чем через терминал.
Тоже так думал, пока Magit не попробовал. После него обратно в консоль, вообще, не тянет.
Я не говорю, что там нельзя это сделать, но мне было лень в этом разбираться.
А в чем претензия? Ну нравится вим, так и пользуйтесь на здоровье! :)
Мне в в виме не хватало нескольких критичных фич, которые я нашёл в емаксе. Потому и перешёл на него. Да и вим не забываю и поглядываю, как там и что.
А про за фичи-то?)) А то у меня закладывается мысль, что они мне тоже нужны xD
(Я по профилю не разработчик, а DevOps, и кодить приходится не очень часто и, скорее, скрипты. Поэтому языковые фичи для меня имеют второстепенное значение. Гораздо важнее удобство работы с кучей разнообразных проектов (Terraform, Ansible, CI/CD, Dockerfiles и т.п.), между которыми нужно постоянно переключаться.)
Удобная работа с проектами типа Projectile для Emacs. Я думаю, в виме такое можно реализовать, но готового решения я не нашёл, а делать или компоновать своё на вимскрипте не хотел.
Удобная работа с Git. В виме я пользовался fugitive, но с ним иногда вообще было непонятно, что происходит, а в недра лезть не хотелось. В Emacs попробовал Magit — он просто работает, в нём есть всё, что нужно, он понятный и очень, очень удобный.
Файл менеждер. netrw был большой и, кажется, глючный. Перешёл на dirvish — минималистично, но даже слишком. Емаксовский dired подошёл как раз впору.
Удобная документация. В емаксе реально удобно пользоваться документацией. В виме тоже более-менее, но не настолько.
Графичесий режим. В емаксе он реально графический, а в виме это, скорее, обёртка консольного.
Кастомизация. В емаксе можно менять, по ощущению, вообще всё. Всюду можно встроить свой хук, обработчик и т.п. И на елиспе это делать проще и понятнее, чем на вимскрипте.
РЕПЛ. Он в емаксе интегрированный. Не надо танцев вокруг tmux и т.п. — вот он, репл, не в терминале, а в соседнем окне редактора. Я им пока немного пользовался и только для Python-скриптов, но уже то, что видел, впечатляет.
- Вот документация в емаксе мне не понравилась: жмём C-h, потом выбираем где будем искать по функциям, по переменным, или где-то там ещё… а мне бы просто узнать, что это, вообще, за буквы, я не знаю функция это, или что-то другое. В Виме же :help wadafuckisthis и вот она справочка.
- В Vim 8 есть уже :terminal. А про танцы вокруг tmux, как-то странно такое слышать от DevOps'а… :)
Вот документация в емаксе мне не понравилась: жмём C-h, потом выбираем где будем искать по функциям, по переменным, или где-то там ещё… а мне бы просто узнать, что это, вообще, за буквы, я не знаю функция это, или что-то другое. В Виме же :help wadafuckisthis и вот она справочка.
C-h a
В Vim 8 есть уже :terminal. А про танцы вокруг tmux, как-то странно такое слышать от DevOps'а… :)
Доктор, что-то не так? Я странный девопс? Мне нужно начать пользоваться tmux, чтобы стать нормальным?
Давайте, может, не будем спорить? Вам нравится вим, так и пользуйтесь. Мне, по перечисленным выше причинам, нравится емакс, поэтому перешёл на него. Вимом продолжаю пользоваться, радуюсь, когда кто-то его для себя открывает. Может, кому-то мой опыт емакса пригодится. Какая разница, здесь важно, на мой взгляд, не спорить, а сотрудничать. :)
Спасибо за развернутый ответ!
Единственное, по 1-му пункту, свои "пять копеек". Связка i3wm+vim перекрывает все вопросы работы с файловой системой, проектами, множеством мониторов и прочие плюшки, и почти не надо пользоваться мышкой))
Да, спасибо! Пробовал такой вариант, но после трёх дней настройки i3 (который уже даже частично преднастроен в моём Manjaro), понял, что это не для меня. Встретив эту статью, понял, что я не один такой лузер, не осиливший i3, и успокоился окончательно. :D
В итоге моё рабочее место состоит из ноутбука (закрытого) и двух мониторов:
- один с воркспейсами: почта, браузер, Slack и т.д.
- второй без воркспейсов: Emacs fullscreen
- терминал: Tilix в обычном или quake-режиме (там же и vim, при необходимости)
- tiling/window management: гномовские шорткаты, как в упомянутой статье
- на совещаниях/в дороге emacs "переезжает" на ноутбучный монитор
Вот такой вариант :)
Ну я не знаю, после освоения вима, вопросов с освоением i3 не встало (предлагаю попробовать еще раз с этой вот инструкцией ). Единственное, надо было подпилить напильником, в течение месяца после запуска.
Но! Теперь конфиг мигрирует со мной по всем тачкам из гита, и везде одинаковое окружение получается, что не может не радовать.
Насчёт настройки — согласен, требуется больше времени, зато и гибкости больше. Ну и поначалу куча непоняток с elisp и т.п. В прошлые попытки попробовать этот непонятный загадочный emacs я его закрывал минут через 5-10. А в этот раз любознательность пересилила лень, открыл мануал, повтыкал вдумчиво, заинтересовался, и пошло-поехало. Ну и еще хотелось попробовать какой-нибудь лисп и repl-driven development.
В емаксе очень много хорошего: и elisp, и репы с плагинами, и org-mode, и ещё вагон всего с телегой! Изучать это всё — кайф и разминка для ума. Но пользоваться этим невозможно. Я два месяца честно пытался, в рамках эксперимента, вдохновившись вот этим вот видосом освоить emacs (честно говоря, это был уже, кажется, третий подход к снаряду). Нет. Это реально — evil. И evil-mode это жалкое подобие режимов vim (к сожалению, все без исключения vim-эмуляторы этим страдают).
Кстати, рекомендую с того же канала посмотреть стендапы про Vim. Не сказать, что прям ну очень много познавательного, но имеется. Я на этих материалах осваивал аудирование иностранной речи.
В студенческие годы у меня тоже был вим с кучей плагинов и настроенных конфигов, и он вполне справлялся со студенческими проектами. Но сейчас я обычно использую IntelliJ/PyCharm/CLion с Vim-плагином. Все кнопки как в Vim, только еще есть полноценный IDE и никаких плясок с бубнами. Выбрал шрифт, цвета по вкусу, сочетания клавиш и поехали.
CLion, правда, на прошлой работе я в итоге выкинул. Он жутко тормозил даже на моей 54-ядерной рабочей станции со 128 ГБ памяти. В итоге я установил IntelliJ Community Edition и использовал его как текстовый редактор без функций IDE. Все равно удобдней, чем Vim с плагинами.
Либо я пропустил, либо тема навигации в большом проекте не раскрыта. Сколько ни пробовал разных плагинов для переключения между файлами, везде есть какие-то проблемы или тормоза.
А fzf не пробовали? У меня даже на большом проекте в тысяч десять файлов работал нормально.
Либо я пропустил, либо тема навигации в большом проекте не раскрыта. Сколько ни пробовал разных плагинов для переключения между файлами, везде есть какие-то проблемы или тормоза.
Плагин fzf, команды Files, Tags, Buffers
Ух, сколько тут: и fzf, и Ag скоро приедет.
Могу в свою очередь представить такие интересные буквосочетания:
gf
gd
gDYCM это clang зависимый (с точки зрения C/C++) плагин, к нему подход нужен тонкий, поскольку он "гарантированно" работает с libclang, который сам же и скачивает. Чтобы он работал с системным, или с тем, который используете вы, ему нужен для этого специальный пендель на этапе сборки плагина. Если же вы не используете в проекте clang, то вам придётся, пойдя на некоторые компромиссы, подрихтовать .ycm_extra_conf.py
IntelliJ/PyCharm/CLion с Vim-плагином. Все кнопки как в Vim, только еще есть полноценный IDE и никаких плясок с бубнами.
Нет, вот с "все кнопки как в Vim" это очень не так. Далеко не все, и не сказать чтобы "как в Vim". Скорее: "некоторые кнопки примерно как Vim".
YCM это clang зависимый (с точки зрения C/C++) плагин
Да, я знаю. В моем проекте кто-то уже проделал основную работу по интеграции YCM и я пытался использовать этот готовый конфиг. Но что-то он не справлялся.
Нет, вот с «все кнопки как в Vim» это очень не так. Далеко не все, и не сказать чтобы «как в Vim». Скорее: «некоторые кнопки примерно как Vim».
Согласен, что не «прям все». Но я каких-то супер-продвинутых функций vim не использую, поэтому особой разницы не замечаю. Просто привык работать с командами перемещения/редактирования/поиска и модальному интерфейсу, которые работают без проблем. Если ваши запросы сильно выше, то наверное у вас будет другой опыт.
На каком языке пишете в vim? В случае с типизированными языками банальный рефакторинг с переименованием класса уже проблема, не говоря уже о таком же рефакторинге в языке с динамической типизацией.
В случае с типизированными языками банальный рефакторинг с переименованием класса уже проблема, не говоря уже о таком же рефакторинге в языке с динамической типизацией.
Не факт.
Скажем для языка Go механизмы, используемые vim и IDE Jetbrains, чтобы понять что там в исходном коде чем является — впоть до недавних пор были вообще полностью идентичны, использовались в конечном итоге та же самая программа gocode, тот же самый пакет go/ast и т.п…
Мои основные языки — C++ и Python. Мне пока для рефакторинга относительно больших код-баз хватало обычных средств редактирования и регулярных выражений.
К недостаткам интеграции с Jupyter в частности, и с работой с ячейками кода в общем — можно отнести отсутствие визуального выделения ячеек. Подскажите знающие, сложно ли запилить следующую логику:
If (строка начинается на #%%):
вывести под этой строкой дополнительную горизонтальную линию
if (курсор находится в ячейке):
изменить цвет фона на более светлый
>> Он очень быстрый. Ввиду особенностей его рендера
>> если на него слишком много плагинов, то он поползёт со скоростью улитки.
Ну вот так вот всегда. Сперва критика сред разработки по поводу глюка прокрутки, а потом…
PS: Пользуюсь и тем и другим. Но интерактивная работа с код+интерпретатор+ячейки пока под вимом не очень.
Добавить горизонтальную черту — не проблема. Есть плагины, которые умеют вставлять в текст символы, которые не будут сохранены на записи. Разные цвета фона делаются только через костыли.
Вим быстрый, но некоторые плагины, например старые проверяльщики синтаксиса, могут результировать в подвисаниях. Просто найдите им асинхронную альтернативу.
статья реально слабая, а тема очень интересная. Жаль, что она не раскрыта полностью. Например, я очень люблю vim, т.к. зачастую это единственный вменяемый вариант (nano? серьезно? ни за что!) что-то на удаленном сервере понастраивать без каких-либо извращений. Ну, или вот отличия vi, vim и neovim — я не понял из статьи в чем они
действительно vim можно сделать красивым и удобным, но я видел какой-то оверинжиниринг, когда коллеги на маках выступают с докладами, код показывают в vim и… Vim тормозит! Реально тормозит. Тема почему это так и как можно все идеально настроить тоже раскрыта очень поверхностно.
не раскрыта тема интеграции с теми же lang-серверами (а-ля как в rust).
А ваши вопросы они ближе к основам. А основы, они как были так и остались: «Your problem with Vim is that you don't grok vi». Этот ответ набрал на So более 2.8к+.
Можно за деревьями не увидеть леса. Можно за всеми этими плагинами, красивостями не использовать всю мощь слепой печати и команд vim-a. И что тогда они будут стоить все эти плагины и украшения? Да, ровным счетом ничего, уж лучше тыкать мышкой в IDE.
Изучение слепой печати и команд в vi — это инвестиция в себя. Один раз научился и все.
Плагины будут приходить и уходить, IDE будут умирать и приходить новые, но навык слепой печати и команд на уровне рефлексов в vim останется на всю жизнь.
Извините, Вы вообще читаете, что я пишу?
Подчеркну — я тоже считаю, что vim отличный тулинг и при прочих равных я им и пользуюсь. Другой вопрос, что статья совершенно не раскрывает всей магии. О чем и речь.
Автор взялся (взялась?) за популяризацию инструмента… но "не шмогла"
Сорри, если что не так.
На счет neovim, рекомендую это видео:
www.youtube.com/watch?v=NmHuu3UjQ7k
Толково, на мой взгляд рассказано. Будет ясная картина.
А по поводу, отличия vi и vim — это в книжке, хорошо расписано:
www.ozon.ru/context/detail/id/19698693
На счет того что у кого-то что-то там тормозит, в общей форме не ответишь. Надо разбираться индивидуально.
Решением проблем с производительностью является использование легковесных плагинов с поддержкой асинхронности.
Различия между Vim и NeoVim более значительны для их разработчиков, чем для пользователей.
Различия между Vim и NeoVim более значительны для их разработчиков, чем для пользователей.
Согласен, могу чуть дополнить про Neovim:
- более современные дефолты, благодаря им, удалось вполовину сократить конфиг
- хорошо интегрируется, благодаря чему для него есть интересные GUI-фронтенды
- перспективный roadmap
- открытая community-driven модель разработки (в Vim — единоличная с BDFL)
Сейчас меня почти все устраивает, кроме дебага. Но я нашел приемлемый для меня вариант ":!code .". vscode подхватывает все изменения файла извне так что я дебажу в нем, а редактирую в vim
До сих пор не понимаю зачем новичкам Vim.
Даже на вашу статью посмотреть:
— Установили вим? Олтично, теперь скачайте 100500 плагинов, настройте их, и можно начинать работать!
Вопрос — нафига так мучаться?
— Установили вим? Олтично, теперь скачайте 100500 плагинов, настройте их, и можно начинать работать!
Ну вас же лично никто не заставляет это делать?
Просто поверьте, подстроенный под себя инструмент это здорово.
Вопрос — нафига так мучаться?
Там потом мультиоргазмы начинаются, когда осваиваешься.
Серьезно.
VSCode — быстрый, почти как редактор, при этом мощный как IDE (и мультикурсор прямо как в саблайме)
VSCode в данном контексте даже смешно.
Ресурсов жрет немало, но при этом как редактор — такой же банальный как и Atom, Sublime и пр. Ну хорошо, хорошо — по дефолту немного настроенный лучше под программиста. Но — это все его достоинства.
Если уж брать конкурента vim — то брать нормальную IDE. Там можно рассуждать, что будет совсем другой уровень.
А VSCode — стоит в одном ряду с банальными текстовыми редакторами и это ничуть не лучший и не худший выбор — он просто очередной редактор и только.
(и мультикурсор прямо как в саблайме)
Не аргумент даже рядом.
Мультикурсоры в vim из коробки уже лет 20 как есть.
Реализовано конечно по своему по вимовски, не так как вы привыкли в VSCode. Но есть уже очень и очень много лет как.
Просто поверьте, подстроенный под себя инструмент это здорово.
Это вы мне, человеку который сидел долгое время нa саблайме с миллионом плагинов рассказываете?
VSCode в данном контексте даже смешно. Ресурсов жрет немало, но при этом как редактор — такой же банальный как и Atom, Sublime и пр
…
А VSCode — стоит в одном ряду с банальными текстовыми редакторами и это ничуть не лучший и не худший выбор — он просто очередной редактор и только.
Извините, но вы совершенно неправы. Посмотрите хотя бы страницу VSCode — https://code.visualstudio.com
И после этого назовите хоть одну вещь, которая есть в «IDE» и нету там (без всяких плагинов).
Мультикурсоры в vim из коробки уже лет 20 как есть.
Нифига их там нет. Мультикурсор, если не изменяет память, появился еще в Textmate, тожe нцать лет назад. Ничего общего с вимовскими командами и макросами он не имеет, а является альтернативой им.
VSCode — такой же редактор, как и Vim, и под него тоже нужно ставить плагины для комфортной работы. У Vim также немерено встроенного функционала, как тут многие в комментариях уже отмечали. Если вам хватает дефолтного состояния Студии, то вы либо разрабатываете под веб, либо у вас ещё не было необходимости в решении комплексных задач.
А насчёт скорости работы — ну может быть в сравнении с IDE и Atom он быстрый...
VSCode — такой же редактор, как и Vim
Полная противоположность реальности.
У VSCode «из коробки» дебаггер, intellisense, рефакторинг, git, поддержка кучи языков и т.п.
По сути ваше мнение о ВСКоде такое же как мое о Виме — нe пользуюсь, но осуждаю :)
Давайте хоть в этом признаемся.
Я иногда пользуюсь VSCode. Мне он нравится значительно меньше Vim, так как он более мудрёный в самом плохом смысле. Сделать в Vim кастомную функцию и забиндить её вызов на какое-то событие — пару строк в конфиге. В VSCode вам придётся создавать для этого отдельный проект на JavaScript.
То, что в текстовый редактор заранее добавили несколько плагинов не делает его IDE. Тем более, что это результирует в этой ужасной полосе иконок слева. Это не только впустую тратит место, так ещё на неё понавешано большое количество функциональности, и даже если вы её скроете, то вам все равно её придётся часто вызывать по сочетанию клавиш.
Мне нравится, что вы упомянули intellisense, так как vim-coc является его прямым портом под Вим. Git полностью обслуживается vim-fugitive и vim-gitgutter. Vim имеет встроенную поддержку подсветки моря языков и, если вдруг ваш не поддерживается или вам она не нравится, то это чинится плагинами. Под рефакторинг есть общие плагины и специализированные программы типа eclim.
Отсутствие некоторых вещей в базовой комплектации делает Vim только лучше, так как он становится более универсальным. Многие его используют как блокнот. Конечно, если есть желание, то для этого можно подрубить и Xcode, и Visual Studio, но я думаю, что не стоит объяснять почему это глупо.
Единственное из перечисленного, что делает Vim хуже — поддержка дебаггеров. Но про это тоже в комментариях всё пояснили.
Есть причина, по которой я пользуюсь Vim и она состоит в том, что мною не было найдено альтернативы лучше. Но вы, конечно, можете всегда это оспорить и написать про это статью в хаб, посвящённый VSCode. Стоп...
Сделать в Vim кастомную функцию и забиндить её вызов на какое-то событие — пару строк в конфиге
Вот честно — ни разу не надо было. Вы это все на vimscript'e пишите?
То, что в текстовый редактор заранее добавили несколько плагинов не делает его IDE. Тем более, что это результирует в этой ужасной полосе иконок слева.
А что по-вашему делает иде — «IDE»? И что для вас вообще означает это понятие? Для меня это не «полоска слева», я ее совсем не замечаю, для меня IDE — это intellisense, документация по библиотекам при наведении курсора, подсказки ошибок, индексация кода и т.д. Все это есть в VSCode «из коробки». Про 100500 плагинов и был мой изначальный комментарий.
Для меня это не «полоска слева», я ее совсем не замечаю, для меня IDE — это intellisense, документация по библиотекам при наведении курсора, подсказки ошибок, индексация кода и т.д. Все это есть в VSCode «из коробки».
Для любого языка?
vim потому и надо настраивать, что есть разные языки.
Впрочем, можете просто взять готовую сборку vim для вашего языка.
Вот честно — ни разу не надо было. Вы это все на vimscript'e пишите?
Он справляется со своей задачей. При желании можно использовать другие языки в NeoVim.
А что по-вашему делает иде — «IDE»? И что для вас вообще означает это понятие? Для меня это не «полоска слева», я ее совсем не замечаю, для меня IDE — это intellisense, документация по библиотекам при наведении курсора, подсказки ошибок, индексация кода и т.д.
Если вы мне сможете объяснить зачем MicroSoft держит два одинаковых продукта под одним брендом, то я вам поверю, что VSCode — IDE.
Еще как блокнот многие используют notepad.exe, он от этого тоже становится немножко редактором кода?
И тут любители nano резко оскорбились
сли вы мне сможете объяснить зачем MicroSoft держит два одинаковых продукта под одним брендом, то я вам поверю, что VSCode — IDE.
При чем тут это? Откуда я знаю зачем им опенсофтверная иде, может хотят захватить рынок разработчиков, которым Visual Studio нафиг не сдалась? Еще и гитхаб купили. Хмм…
Скачайте обычную Студию и потыкайте в неё. Со временем понимание придёт.
Простите за грубый ответ, но чтобы не писать чушь в интернете.
Как я могу разговаривать с человеком, у которого нет опыта работы с темой спора и который не хочет этот опыт обрести?
Пользуйтесь VSCode на здоровье, никто его у вас не отнимет.
Вы вот в привели такой аргумент: «Если вы мне сможете объяснить зачем MicroSoft держит два одинаковых продукта под одним брендом, то я вам поверю, что VSCode — IDE.»
А я не Microsoft, я не знаю зачем они что-то делают. Но я могу предположить что т.к. оба продукта их — то им пофиг, там нет дифференциации. Тем более обычная Visual Studio — ориентирована на совсем другой рынок.
Если разговор начался про конкретные плюсы в разных редакторах, а вы переходите на какие-то мутные разговоры про microsoft — то мне кажется что это мне с вами не о чем говорить, а не вам со мной.
Тем более обычная Visual Studio — ориентирована на совсем другой рынок.
Не уж то вы сами ответили на мой вопрос? Два продукта для двух разных рынков. Первый покрывает аудиторию любителей полнофункциональных IDE, а второй — легковесных текстовых редакторов.
Классические попытки Майкрософт в монополию.
Вопрос — нафига так мучаться?
Для того, чтобы иметь возможность пользоваться модальным редактором
Если вы не девопс/сисадмин — нафига?
Я, к примеру, выучил vim для возможности работы в неудобных местах без стола на ноутбуке в дороге.
В классических редакторах нужно руки выкручивать для shortkeys или мышью пользоваться.
Собственно, модальность vim это и есть его киллер-фича.
Все остальное есть и в других инструментах.
Плюс экономия заряда батареи в дороге важна — а vim требует меньше ресурсов процессора, чем полноценная IDE или VSCode. Потому и взял vim как основной редактор для ноутбука в дороге.
Я, к примеру, выучил vim для возможности работы в неудобных местах без стола на ноутбуке в дороге.
Не вижу никакого аргумента не пользоваться ide нa том же ноутбуке. У меня вообщe есть только ноутбук.
В классических редакторах нужно руки выкручивать для shortkeys или мышью пользоваться.
Ну блин, это жe совсем не так.
Мой обычный «воркфлоу» мультикурсором выглядит как-то так (для примера разделение словаря на отдельные переменные):
(Я тут еще немного «camera shy», в обычной работе все происходит быстрее)
При наборе и навигации по тексту мышкой я нe пользуюсь. Но, например когда просто просматриваешь код — часто удобнее нажать «jump to definition» на тачпаде, а не на клавиатуре.
У вас пример в Gif довольно неудачный, так как это самые базовые вещи, на которые способен Vim
Приведите свой пример.
Тут вы пытаетесь доказать, что мультикурсор в Vim что-то не умеет ==> действует презумпция невиновности ==> это от вас нужно ждать пример комплекснее.
Ваши действия можно повторить сочетанием клавиш: dd3jdd0<C-q>3k3lcconst<Esc>$<C-q>3jd
это от вас нужно ждать пример комплекснее
А вы свой комментарий выше перечитайте:
> пример в Gif довольно неудачный, так как это самые базовые вещи, на которые способен Viм
«Презумция невиновности» действует на меня в этом случае ;)
Ваши действия можно повторить сочетанием клавиш: dd3jdd0<C-q>3k3lcconst$<C-q>3jd
Куда проще.
Давайте попробуем разобраться в вашей логике.
1). Вы прислали простой пример.
2). Вам указали, что пример простой и попросили пример, способный "разбить Vim вдребезги".
3). Вы сказали, что это вам должны привести пример, который "разобьёт VSCode вдребезги".
Если мы говорим про курсор в целом, а не только в плане "мультикурсоности", то с этим плагином вы можете одной командой перейти в любую точку на экране с клавиатуры. Я уже не говорю о встроенных методах перемещения. Добавим к этому широкий арсенал редактирования и мы получим, что Vim по определению способен на "большие свершения".
3). Вы сказали, что это вам должны привести пример, который «разобьёт VSCode вдребезги».
Нене, вы неправильно мою логику трактуете. Я сказал — привидите мне пример, который на ваш взгляд «разобьет VSCode вдребезги», чтобы я знал с чем мне работать :)
с этим плагином вы можете ...
Ну епрст, опять про плагины. Для VSCode есть vim плагин. Шах и мат.
Нене, вы неправильно мою логику трактуете. Я сказал — привидите мне пример, который на ваш взгляд «разобьет VSCode вдребезги», чтобы я знал с чем мне работать :)
У меня есть подозрение, что вы просто не можете придумать более сложного примера.
Ну епрст, опять про плагины.
Вчитайтесь в название. Это просто обёртка вокруг стандартных команд.
Для VSCode есть vim плагин. Шах и мат.
Тут снова проявляется ваше ограниченное знание темы, ибо эмуляторы Vim в других редакторах — это очень кривые костыли.
У меня есть подозрение, что вы просто не можете придумать более сложного примера.
Да у меня про вас точно такое же подозрение. Вы сказали «это базовый уровень» Так приведите пример не базового. Или вам весь мой рабочий процесс в гиф записать?
Покажите как вы можете прыгнуть в любую точку экрана с клавиатуры в VSCode.
так же можно перейти в любой файл / модуль / функцию и т.д.
В easymotion вы можете дать поиск по словам или по букве, после чего сразу перейти к результату, введя шорткат, показанный на экране. Перейти к строчке по её номеру несложно (самый простой вариант — gg300j).
Но он его не предлагает автоматически скачать при открытии файла...
Vim умеет бегать влево-вправо по словам, по окончаниям слов, а также умеет повторять поиск символов в строке. У вас так можно?
Поиск и изменение слов в Vim осуществляется либо регулярными изображениями, либо плагином vim-multiple-cursors.
Вим умеет клавиатурой скроллить экран построчно, либо по половине экрана, либо по целому экрану. Также в нём можно сделать скроллинг кастомного размера, прыгая по количеству строк и можно сразу перейти к началу файла или его концу.
Поиск по регуляркам понятно дело есть, причем быстрый.
Навигация:
По строке — cmd + arrow
По экрану — pgUp / pgDown
Конец/начало файла — cmd + end/home
Скроллинг и в Vim без плагинов.
В Vim есть система переходов. Если вы перешли из одного файла в другой, а из него в третий, то вы можете перемещаться по этому списку комбинациями клавиш, без использования табов.
Вот вам еще пример — перемещение блоков кода клавиатурой с автоматической индентацией и складывание кода в одну строку и обратно:
Красивого сдвига там нет. Блок кода можно по-старинке либо выделить построчно с помощью V, потом его удалить, прыгнуть на нужную строчку и вставить. Также можно его сразу двинуть в нужное место командой :m <номер строки>.
В принципе, для этого можно самому написать мини-плагин. Тут есть пример как сдвигать одну строчку. Для range это будет немногим сложнее.
Форматирование лечится с помощью плагина Autoformat, но можно повторить выделение gv и его сдвинуть ручками с помощью >> (а потом . если надо несколько раз). Текст вытягивается в одну строку с помощью J.
В Vim есть встроенное автодополнение. Он умеет подбирать слова, имена файлов, теги и данные из Lang-серверов, если они могут в omnifunc.
Намного интереснее — контекстное автодополнение и автодополнение по строкам.
Намного интереснее — контекстное автодополнение и автодополнение по строкам.
Не очень понял что вы имеете в виду, но в вскоде есть такие штуки:
Вы бьёте по контекстному автодополнению, пока оно не найдёт нужное вам слово, после чего начинается магия. По последующим нажатиям он начинает подставлять слова с той строчки (контекста), с которого вы взяли первое слово. Но вы также можете изменять значения по мере ввода. Таким образом вы можете быстро набрать несколько похожих строк или кусков строк с небольшими изменениями.
Автодополнение по строкам просто скроллит строчки, которые вы бы хотели вставить.
Предлагаю на этом закончить.
В этом видео подробно рассказано про эти трюки.
Предлагаю на этом закончить.
Отличная идея, так как мы никогда к логическому завершению не придём.
Форматирование лечится с помощью плагина Autoformat
gg=G для всего файла
=G для текущего блока
Перейти к строчке по её номеру несложно (самый простой вариант — gg300j).
Самый простой — 300gg
Перейти к строчке по её номеру несложно (самый простой вариант — gg300j).Самый простой — 300gg
Можно короче 300G
Правда количество нажатий клавиш — то же, что и в предыдущем примере.
Ваши действия можно повторить сочетанием клавиш: dd3jdd0<C-q>3k3lcconst$<C-q>3jd
Это надо зачитывать до того, как черной курице голову отрубишь или после?
Парсер-лох.
Я, к примеру, выучил vim для возможности работы в неудобных местах без стола на ноутбуке в дороге.
Не вижу никакого аргумента не пользоваться ide нa том же ноутбуке. У меня вообщe есть только ноутбук.
Если на ноуте работаете именно в дороге, то тогда вам должно быть понятны ситуации:
- Только разработался, а заряд уже закончился.
- Когда работаешь где попало, запястья постоянно задевают за тачпад.
- Нажимем клавишу-модификатор, а ноут, стоящий не на твердой поверхности, перекашивается.
- Негде ездить мыши, а тачпадом не получается так быстро и точно как мышью
Только разработался, а заряд уже закончился.
Это знакомо, но к редактору мало имеет отношения на мой взгляд (vscode это не хром все-таки, и тем более не inteliJ)
Когда работаешь где попало, запястья постоянно задевают за тачпад.
Извините, но у вас хреновый тачпад, который не замечает ложные нажатия.
Нажимем клавишу-модификатор, а ноут, стоящий не на твердой поверхности, перекашивается.
Вообще «надуманый» аргумент, у меня например клавиши Q,W,A,S,Z,X все располагаются левее главной клавиши модификатора (Command)
Да и даже держа ноут на коленках нe могу представить с какой силой надо жать на клавиши чтобы он перекосился.
Только разработался, а заряд уже закончился.
Это знакомо, но к редактору мало имеет отношения на мой взгляд (vscode это не хром все-таки, и тем более не inteliJ)
Но все же по жручести — VSCode далеко и не vim
Извините, но у вас хреновый тачпад, который не замечает ложные нажатия.
На MacBook Pro?
Считается лучшим тачпадом в мире.
Возможно, у меня руки такой формы.
;)
Вообще «надуманый» аргумент, у меня например клавиши Q,W,A,S,Z,X все располагаются левее главной клавиши модификатора (Command)
Да и даже держа ноут на коленках нe могу представить с какой силой надо жать на клавиши чтобы он перекосился.
Как бы то ни было — тем не менее это так. У меня. Дико мешает и раздражает колбание ноута.
Ноут больше качается, когда хочешь заменить неудобный тачпад клавиатурными сочетания в классических редакторах.
В vim с его модальностью — сочетания выполняются последовательно и не нужно ни руки выкручивать, и ноут шатается меньше.
На MacBook Pro?
Считается лучшим тачпадом в мире.
Возможно, у меня руки такой формы.
Не поверите — у меня такой же ноутбук, и вроде все ОК :)
Ноут больше качается, когда хочешь заменить неудобный тачпад клавиатурными сочетания в классических редакторах.
В vim с его модальностью — сочетания выполняются последовательно и не нужно ни руки выкручивать, и ноут шатается меньше.
Ну согласитесь, совсем «edge case» аргумент.
Ну согласитесь, совсем «edge case» аргумент.
Какая разница edge case это или нет? У человека есть проблема, он нашёл какое-то решение. У меня с тачпадами на ноутбуках кстати точно такая же проблема.
Какая разница edge case это или нет?
Большая. Говорить что в виме тачпад не задеваешь руками, а в остальных редакторах задеваешь — это еще проверить надо.
Говорить что в виме тачпад не задеваешь руками, а в остальных редакторах задеваешь — это еще проверить надо.
Ну я думаю skrimafonolog проверил )). Я, кстати, задеваю тачпад независимо от редактора, просто когда пользуешься чем-то вроде вима — тачпад можно отключить.
Большая. Говорить что в виме тачпад не задеваешь руками, а в остальных редакторах задеваешь — это еще проверить надо.
Я не это говорил.
Он просто отключен, когда я в vim.
vscode это не хром все-таки
Как сказать. Electron, на котором работает Vs Code, это, по сути, Chromium.
Если вы не девопс/сисадмин — нафига?
Чтобы работать было удобно.
Разумеется я не пытаюсь никого из вимеров отговорить им пользоваться, но мне не понятно зачем новым людям учить этот инструмент. Тут в комментариях уже несколько раз говорили что вим умеет что-то, что недоступно в других редакторах, но пример никто так и не привел. Я уже несколько примеров привел где мультикурсором можно делать все тоже самое что командами вима.
Ага, а еще скажите, что любой редактор можно настроить так, что у него комбинации клавиш будут как в виме, чтобы у вимоводов подгорело (долой конвенциальные сочетания типа ctrl+v — это для нубов, ога)
Меня лично vim спасает неоднократно именно в админских историях.
Меня лично vim спасает неоднократно именно в админских историях.
Да я уже выше писал что с админами и девопсами все понятно — там это один из основных инструментов по сути.
Да я уже выше писал что с админами и девопсами все понятно — там это один из основных инструментов по сути.
Да ладно.
А почему все таки не nano, который безрежимный?
Нано по-вашему «современный редактор»?
Когда я админю — то vim там на серверах с дефолтными настройками, по умолчанию все и без плагинов.
Не вижу причин почему с nano это не прокатит.
Не вижу причин почему с nano это не прокатит.
Вы это серьезно? nano по возможностям навигации и манипуляций текстом к виму и близко не подошел (а к современным редакторам тем более)
Вы это серьезно? nano по возможностям навигации и манипуляций текстом к виму и близко не подошел (а к современным редакторам тем более)
Серьезно.
Крупные манипуляции с серверными конфигами так, чтобы вам понадобился весомый функционал, делать удаленно нельзя.
code.visualstudio.com/docs/remote/remote-overview
Можно хоть в удаленный докер контейнер зайти, хотя я согласен что для манипуляций с конфигами — это оверкилл.
Конфиги, по возможности, лучшe локально править, и деплоить их по всем правилам.
nano пользоваться невозможно по сути. Вырвиглазный отстой. Извините. Лучше уж — mcedit тогда :-))))))))) Хотя бы навевает воспоминания о молодости. Norton, Volkov Commander и FAR ))))
Ну так я и говорю о том что сейчас есть гораздо более удобные и современные инструменты чем вим. Без адского «learning curve».
И без режимов.
Разумеется я не пытаюсь никого из вимеров отговорить им пользоваться, но мне не понятно зачем новым людям учить этот инструмент.
Для того, чтобы иметь возможность пользоваться режимами.
Тут в комментариях уже несколько раз говорили что вим умеет что-то, что недоступно в других редакторах, но пример никто так и не привел.
Несколько раз привели. Продублирую. В виме есть режимы. В других редакторах их нет.
Несколько раз привели. Продублирую. В виме есть режимы. В других редакторах их нет.
Ни разу нe привели (дайте ссылку) Про режимы вы сейчас в первый раз упомянули. Тем более это все равно ничего не объясняет, просто «потому что там есть режимы»
Режимы там есть, потому что вим вышел когда на компьютерах ни то что мышек не было, а даже стрелочек на клавиатуре (оттуда кстати и перемещение по hjkl)
В современных редакторах можно одновременно и манипулиовать текстом и осуществлять навигацию, находясь при этом в режиме ввода.
Я ожидал увидеть пример каких-то манипуляций с текстом, часто используемых в работе, где виму реально нет равных.
Тем более это все равно ничего не объясняет, просто «потому что там есть режимы»
Режимы — это как раз самое приципиальное отличие vim от прочих редакторов.
Все прочие — равны между собой, и там можно рассматривать соревнование этих редакторов по количеству плагинов, встроенный язык для программирования плагинов и т.п.
Но vim — потому и стоит особняком — из-за природы работы в разных режимах.
Режимы там есть, потому что вим вышел когда на компьютерах ни то что мышек не было, а даже стрелочек на клавиатуре (оттуда кстати и перемещение по hjkl)
Да.
И именно поэтому в нем до сих пор без мыши удобно работать.
Например, мне критично в некоторых случаях — таких как работа с ноутом на коленях в трясущемся транспорте.
Вот и получается, что созданный 30 лет назад редактор все еще полезен. Задуманные тогда концепции очень даже удобны и сейчас. Пусть и для других целей, на новом витке эволюции компьютеров, с совсем другой техикой.
В современных редакторах можно одновременно и манипулиовать текстом и осуществлять навигацию, находясь при этом в режиме ввода.
Пфф. Можно подумать здесь этого кто-то не знает.
Но в ряде случаев это не шибко удобно — см. выше.
vim потому и так популярен — что работы с режимами полноценной нет у других развитых редакторов.
Я ожидал увидеть пример каких-то манипуляций с текстом, часто используемых в работе, где виму реально нет равных.
Вам же привели уже:
dd3jdd0<C-q>3k3lcconst$<C-q>3jd
Я так понимаю, что коллега оппонирует к другому — что на современных нормальных клавах есть PgUp, PdDn, End, Home и прочие кнопки управления курсором. По факту — нафигацией (именно так, это не описка). На самом деле это и так, и не так. Потому что современный тренд таков, что все лишние кнопки с клавы выпилили в угоды дешевизне. Уже куча ноутбуков, у которых PgUp/PgDwn и прочие нажимаются как Fn + нечто. И поэтому возможность набора на кнопках с алфавитноцифровыми символами ОПЯТЬ в цене и повышает эффективность работы. Как минимум — позволяет не отвлекаться на "а где же мой PgUp". Я уж не говорю, что на маках нет даже Del (да, там можно его сэмулировать через комбинацию)...
Я так понимаю, что коллега оппонирует к другому — что на современных нормальных клавах есть PgUp, PdDn, End, Home и прочие кнопки управления курсором.
Ну вы так прямо пишете будто бы вимоводы не имеет этих клавиш или не пользуют и обычными редакторами.
vim их поддерживает эти клавишы.
Но я сознательно отказался от этих клавиш, когда работаю на ноутбуке в дороге. Ибо и так неудобно — а еще и руку переносить.
Я вам больше скажу, некоторые гики себе клавиатуры сокращенные делают/покупают и утверждают, что с ней удобнее:
статья «Выбираем и собираем 60% клавиатуру»
Я вот попробовать собрался. Когда лично попробую тогда и буду утверждать.
например на ноуте вместо home/end можно нажимать cmd+up/down
К тому же, со времен textmate'a эти шорткаты почти не изменились.
И именно поэтому в нем до сих пор без мыши удобно работать.
Я и говорю про то что в любом нормальном редакторе без мыши можно спокойно работать.
Вам же привели уже:
То был ответ на мой комментарий, где я сделал то же самое, только меньшим количеством команд.
https://habr.com/ru/post/468265/#comment_20693615
Я и говорю про то что в любом нормальном редакторе без мыши можно спокойно работать.
Смотря что делать. Мы же про разработку? Одними Ctrl+V — не обойтись.
Речь вот о чем:
В обычных редакторах полный отказ от мыши исчерпывает комбинации быстро и мы приходим к конструкциями вида Ctrl+Alt+Shift+V.
При этом, напротив, командный режим vim (основной) позволяет нажимать кнопки команды последовательно, а не одновременно. Поэтому необходимости в таких выламыващих руки нажатиях нет.
Смотря что делать. Мы же про разработку? Одними Ctrl+V — не обойтись.
Ну вот опять этот снобизм. Я думал я достаточно уже гифок запостил где ctrl+V дело далеко не ограничивается.
В обычных редакторах полный отказ от мыши исчерпывает комбинации быстро и мы приходим к конструкциями вида Ctrl+Alt+Shift+В
Это не так. <CMD/Ctrl/Alt + буква> — и вот у вас ужe вся клавиатура разных команд только с одним модификатором.
У меня v повседневной работе нет ни одного шортката из 4х клавиш.
Ни разу нe привели (дайте ссылку)
Вот ссылка. https://habr.com/en/post/468265/#comment_20687629
Про режимы вы сейчас в первый раз упомянули.
Нет, не в первый. Вот первый — https://habr.com/en/post/468265/#comment_20693261. А так то я целый пост на эту тему сделал когда-то https://habr.com/en/post/339908 .
Тем более это все равно ничего не объясняет, просто «потому что там есть режимы»
Вас же интересует зачем пользоваться вимом? Ответ — для того, чтобы иметь возможность использовать режимы. Зачем использовать режимы это другой вопрос. Тут ответ простой — потому что это удобно. Об этом я тоже говорил.
Режимы там есть, потому что вим вышел когда на компьютерах ни то что мышек не было, а даже стрелочек на клавиатуре (оттуда кстати и перемещение по hjkl)
Ну да. К счастью причина по которой появились режимы не делает модальные редакторы менее удобными.
В современных редакторах можно одновременно и манипулиовать текстом и осуществлять навигацию, находясь при этом в режиме ввода.
В виме тоже можно, только это неудобно. Как и в других редакторах.
Я ожидал увидеть пример каких-то манипуляций с текстом, часто используемых в работе, где виму реально нет равных.
Таких нет. Киллер фича вима — режимы.
Ну так я и говорю о том что сейчас есть гораздо более удобные и современные инструменты чем вим. Без адского «learning curve».
Вы серьезно?
Думаете, что вимоводы не освоили других редакторов? Тем более, что они «более простые».
vim ни у кого не является первым редактором — с «более удобными» редакторами мы сталкиваемся гораздо раньше.
Это осознанное решение после знакомства с безрежимными редакторами.
Не могу не кинуть камень в ваш огород — а вот у вас — это не так, знаете только одну сторону и считаете только её «светлой».
Вы серьезно?
Думаете, что вимоводы не освоили других редакторов? Тем более, что они «более простые».
Не совсем, просто очень часто от пользователей вима слышу заблуждения о том что в других редакторах надо постоянно возить мышкой, что мультикурсор — это несерьезно и т.п.
Не могу не кинуть камень в ваш огород — а вот у вас — это не так, знаете только одну сторону и считаете только её «светлой».
Отчасти с вами согласен, я с вимом знаком на базовом уровне, могу конфиг или коммит поправить. Но опять же, считаю многие доводы о современных редакторах не соответствуют действительности.
ПС как например в виме сделать вот так?
(знаю что скорее всего можно, просто любопытно какими командами)
какой-то странный кейс. Если нужно таких паттернов нагенерить пачку (более 100 строчек), то проще взять jinja + небольшой цикл написать… И получившийся код скопипастить.
что мультикурсор — это несерьезно и т.п.
Да что вы так за мультикульсор уцепились. Мультикурсор есть и в vim.
Если вас не устраивает тот длинный вариант, что вам привели — есть и чрезвычайно сокращенные варианты мультикурсора в vim, нужно только плагин поставить соответствующий.
часто от пользователей вима слышу заблуждения о том что в других редакторах надо постоянно возить мышкой
Мы, в отличие от вас, не по наслышке знаем о том, как работать в обычных редакторах.
Если бы у вас был опыт и там и там (каковой есть у вимоводов), тогда бы вы могли кидаться фразами про «заблуждение».
Но пока заблуждаетесь именно вы, ибо не видели обоих сторон — и с vim и с обычными.
Но опять же, считаю многие доводы о современных редакторах не соответствуют действительности.
Дык и никто не говорит, что они убоги.
Речь о том, что у них нет полноценных режимов, которые есть в vim.
Речь о том, что у них нет полноценных режимов, которые есть в vim.
Я же говорю что режимы и не нужны, вместо этого есть палитра комманд и мощная система манипуляции текстом. Они выполняют те же функции что и режимы по сути.
Я же говорю что режимы и не нужны, вместо этого есть палитра комманд и мощная система манипуляции текстом. Они выполняют те же функции что и режимы по сути.
Когда в результате у вас очень большое число команд (мы же о развитых редакторах, приближающихся к IDE) — то в обычном редакторе вызываются они уже только с мышью. Или весьма сложными шорткатами, когда вам необходимо нажимать много клавиш одновременно.
Когда в результате у вас очень большое число команд (мы же о развитых редакторах, приближающихся к IDE) — то в обычном редакторе вызываются они уже только с мышью
Если какие-то специфичные ui штуки — то возможно мышкой, но абсолютно вся манипуляция текстом и навигация по файлам осуществляется клавиатурой. А что еще надо то?
Я же говорю что режимы и не нужны
А вам отвечают, что нужны ))
вместо этого есть палитра комманд и мощная система манипуляции текстом. Они выполняют те же функции что и режимы по сути.
Только с режимами пользоваться всеми этими функциями удобнее.
Только с режимами пользоваться всеми этими функциями удобнее.
Нет, режимами пока пользуешься — надо постоянно переключаться еще :)
Нет, режимами пока пользуешься — надо постоянно переключаться еще :)
В «безрежимных» редакторах вы тоже нажимаете много клавиш, пусть и по-другому
например, поиск:
в обычном
Ctrl+F (две клавишы)в vim из командного режима
/ (даже меньше клавиш)а если в режиме редактирования были, то
Esc / (не больше клавиш, чем в обычном) Проблема, получается, только запомнить эти комбинации.
И, да, не забывайте, что вы не можете забиндить любые комбинации. Например, Alt + F* у меня перехватываются операционной системой (точнее — графической оболочкой к ней).
Ну и на самом деле в повседневной разработке используется максимум 10 разных команд, к тому же всякие поиски нa тех же шорткатах что и по всей системе обычно (тот же ctrl+F работает и в браузере и в ворде, и в редакторе)
Нет, режимами пока пользуешься — надо постоянно переключаться еще :)
Проблем с переключением между режимами не больше, чем проблем с переключением между состоянием, когда Ctrl зажат и когда он отпущен. А по субъективным ощущениям так и меньше.
ПС как например в виме сделать вот так?
(знаю что скорее всего можно, просто любопытно какими командами)
Мультикурсор отдыхает по сравнению с вим-макросами. Серьёзно, просто погуглите про них. Вы набираете 'qw' ('q' — начать запись, 'w' — имя макроса, можно любую клавишу) и делаете что хотите — редактируете строчку, копируете куски, всё, что угодно. Потом ставите курсор в начало строки и заканчиваете запись (просто 'q'). После этого в любой нужной строчке вызываете свой макрос ('@w'). Надо несколько строчек/кусков кода подряд? Работают все модификаторы ('10@w').
Это всё очень естественно, просто и удобно. И позволяет делать очень крутые вещи — превращать серию case'ов в switch'е в вызовы функций, превращать списки констант в enum'ы и прочее.
Как-то хохмы ради развернул список ошибок (табличные данные — код ошибки, идентификатор, описание) в длиннющий список вида case'ов вида:
case 10:
debug() << "Failed with error (10) WRONG_PWD 'Incorrect password'";
return new Error("10 WRONG_PWD");
… на несколько сотен строк. Помню шок у людей на code review :)
Всякие диспетчеры сообщений вида
case NEW_ORDER_REQUEST: onNewOrderRequest(message); break;
case ORDER_CANCEL_REQUEST: onOrderCancelRequest(message); break;
...(обратите внимание на разный стиль) тоже делаются на раз-два.
Мультикурсор отдыхает по сравнению с вим-макросами. Серьёзно, просто погуглите про них.
Макросы были и в Textmate'e, и в Саблайме, в VSCode есть через плагин.
Я прекрасно знаю как ими пользоваться, и пользуюсь иногда, но мультикурсор заменяет их в 90% случаев.
Работает по сути точно так же, только сначала вы выделяете сначала все варианты, a потом разом меняете.
Я тут в комментариях несколько гифок уже приложил с примерами.
Я бы как-то так делал:
jqwwwywWvlpvbgU0jq2@wV%yO<Esc>Pc3wimport<Esc>j^dWj.j.ja from './entity-base'
Записываю макрос копирования, перевода в верхний регистр и перехода на начало следующей строки. 2@w выполняет макрос ещё два раза. Затем копирую блок в фигурных скобках (можно было не переходить для этого в визуальный режим, это просто привычка), заменяю в скопированном блоке const test = на import (опять же, можно было сразу без него скопировать). Далее dWj.j. удаляет из каждой строки фрагмент до пробела. Ну и добавляю from './entity-base'.
И ещё, если бы список был длинным, я бы применил макрос ко всем строкам через Vi}:normal @w<Enter>, а не считал бы строки.
Чем мне не нравятся макросы в такой ситуации — приходится немного больше планировать само написание (т.к. все изменения будут видны только после применения). И еще, если после прогонa макросов замечаешь что нечаянно в самом макросе опечатался — приходится заново все делать, в то время как курсоры применяются после выделения и их можно нa месте сразу поправить.
VsCodeVim существует и довольно популярен не без причины. ;)
Конечно, он для тех кто уже к вим командам привык, но хочет пользоваться современным редактором
Если бы пользователями vim были исключительно старые замшелые разработчики, подсевшие на него в прошлом веке — то, да.
Но:
Ну исходя из того, что vim изучают и довольны довольно молодые люди, как автор этот статьи.
Исходя из того, что vim практически все изучают далеко не первым редактором.
То это не может быть так, как вы сказали.
https://marketplace.visualstudio.com/items?itemName=vscodevim.vim&ssr=false#review-details
Люди, которые перешли со всяких саблаймов будут использовать фишки саблайма (мультикурсор и прочее, то что в виме называется мультикурсором работает совсем не так и совсем не заменяет макросы)
Те кто перешел со всяких «больших» IDE — им скорее всего вообще пофиг (если только там раньше тоже не использовали что-то подобное)
Новичек с большей долей вероятности будет использовать оригинальный вим.
Там 90% ревью — это пользователи вима жалуются на то, что что-то работает не как в виме :)
Вам именно об этом и говорят, — vim сам по себе типичный программистский редактор, каких в нашей современности есть еще и других много.
Но его есть киллер-фича — это режимы.
И переходя на другие инструменты, люди желают получить режимы vim`a и от тех других инструментов.
(мультикурсор и прочее, то что в виме называется мультикурсором работает совсем не так и совсем не заменяет макросы)
Поиск говорит, что есть как минимум 2 плагина для vim, реализующих полноценную мультикульсорность «как в Sublime».
И переходя на другие инструменты, люди желают получить режимы vim`a и от тех других инструментов.
Ну да, переходя с вима на другие инструменты — они хотят получить то, к чему привыкли.
Поиск говорит, что есть как минимум 2 плагина для vim, реализующих полноценную мультикульсорность «как в Sublime».
Ну так это для пользователей саблайма, которые перешли на вим и хотят вернуть мультикурсор :)
У тех плагинов, которые я видел — есть один косяк, который ломает все: после создания нескольких курсоров, если например прыгнуть назад на одно слово — то первый прыгнет правильно, а остальные нa такое же количество символов как и первый, a нe тоже на одно слово назад. Это абсолютно лишает смысла всю затею и не позволяет пользоваться мультикурсором как макросами.
да и spell checker тож есть, чо уж…
Спасибо за интересную и актуальную статью! Для меня самым важным моментом здесь было автоматическое переключение раскладки при смене режима со вставки на командный и обратно. Сделать по инструкции на macOS не получилось, может сможете подсказать что не так? При русской раскладке в режиме вставки после нажатия Esc ничего не происходит, а я ждал перехода на английскую.
Вот дополнительная информация:
[13:33]d.vinokurov@MacBook-Pro-DVinokurov[hacking]$ ls /usr/local/lib/libxkbswitch.dylib
/usr/local/lib/libxkbswitch.dylib
[13:36]d.vinokurov@MacBook-Pro-DVinokurov[hacking]$ ls /usr/local/bin/xkbswitch
/usr/local/bin/xkbswitch
[13:36]d.vinokurov@MacBook-Pro-DVinokurov[hacking]$ /usr/local/bin/xkbswitch
Usage: xkbswitch -g|s [-n|e] [value]
-g get mode
-s set mode
-n setting and getting by numeric mode (default)
-e setting and getting by string mode
-l list all available layouts (their names)И кусок конфига:
filetype plugin indent on "Включает определение типа файла, загрузку...
"... соответствующих ему плагинов и файлов отступов
set encoding=utf-8 "Ставит кодировку UTF-8
set nocompatible "Отключает обратную совместимость с Vi
syntax enable "Включает подсветку синтаксиса
if empty(glob('~/.vim/autoload/plug.vim')) "Если vim-plug не стоит
silent !curl -fLo ~/.vim/autoload/plug.vim --create-dirs "Создать директорию
\ https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
"И скачать его оттуда
"А после прогнать команду PlugInstall, о которой мы сейчас поговорим
autocmd VimEnter * PlugInstall --sync | source $MYVIMRC
endif
call plug#begin('~/.vim/bundle') "Начать искать плагины в этой директории
Plug 'lyokha/vim-xkbswitch'
call plug#end() "Перестатьэто делать
set keymap=russian-jcukenmac
set iminsert=0
set imsearch=0
let g:XkbSwitchEnabled = 1И кстати curl пришлось прогнать вручную, не работало.
Похоже vim-xkbswitch не был установлен, исправил выполнением :PlugInstall, перезапустил, получаю:
Error detected while processing function <SNR>47_xkb_switch:
line 7:
dlerror = "dlopen(/usr/local/lib/libxkbswitch.dylib, 0x0005): code signature in (/usr/local/lib/libxkbswitch.dylib) not valid for use in process: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed."
E364: Library call failed for "Xkb_Switch_getXkbLayout()"Попробовал подписать своим сертификатом из Xcode командой codesign --options library --force --deep -s 'MY_EMAIL' /usr/local/lib/libxkbswitch.dylib и теперь получаю dlerror = "dlopen(/usr/local/lib/libxkbswitch.dylib, 0x0005): code signature in (/usr/local/lib/libxkbswitch.dylib) not valid for use in process: mapping process is a platform binary, but mapped file is not"
Делаем из Vim-а конфетку