Говорят, однажды попробовав Vim, назад уже не вернешься.
Для разработчика Vim может быть опасен. Особенно, если коллеги настаивают на его использовании или, как минимум, тонко намекают. Как если бы ты был Нео из «Матрицы», и вдруг в обычный, ничего не предвещающий день…
Опа! Сбой в матрице.
Выбор за тобой. Потом пути назад уже не будет. Примешь синюю таблетку — история закончится, ты проснёшься в своей постели и будешь верить, что GUI — это сила. Примешь красную — и останешься в Стране Чудес, а я покажу тебе, насколько глубока кроличья нора Vim. Помни — я предлагаю только правду, и ничего более.
Красную таблетку или синюю?
Предпочтешь красную или закончим на этом?
Клик — и ты вновь в повседневных иллюзиях…
Клик — и ты войдёшь в Страну Чудес…
Принимаю красную
Как и многие из нас, я выбрал красную таблетку. Если вы программист, то наверняка слышали различные шутки о том, как трудно выйти из Vim и что его изучение подобно катанию на американских горках.
Вопреки распространенному мнению, существует множество причин использовать Vim. Если вы относитесь к тому типу программистов, которые наслаждаются жизнью в терминале и могут легко обходиться без графического интерфейса, то Vim — отличный выбор для редактирования кода.
Явное преимущество Vim становится очевидным при подключении по SSH к удаленным серверам. В таких сценариях VS Code не слишком удобен, в то время как для ввода «vim» с клавиатуры и начала редактирования потребуется всего пара секунд. Не нужно решать потенциальные проблемы с обновлениями, дающими сбой или конфликтующими с расширениями. В таких ситуациях трудоёмкая отладка вам обеспечена. Кроме того, VSCode принадлежит Microsoft, но, являясь продуктом с открытым исходным кодом, потенциально уязвим для злоумышленников. Таким образом риск, связанный с использованием исключительно VS Code, будет неоправданным. С другой стороны, Vim в качестве редактора имеет устойчивую репутацию и, вероятно, останется актуальным даже через 20–30 лет.
Что же такое Vim?
Vim не таит в себе никакого волшебства. Он ориентирован на программистов.
По мере погружения в тайны Vim у меня начало складываться представление о нём. В упрощённом виде его работу отображает эта диаграмма.
Более продвинутые читатели увидят в ней так называемую машину с конечным числом состояний (Finite State Machine, FSM), но для простоты я буду называть ее диаграммой.
Из приведённой диаграммы хорошо видно, как вводится команда, а затем по нажатию < i > осуществляется переход в режим вставки. Далее < ESC > возвращает нас к исходному режиму. Теперь нажимаем < : > и переходим в другой режим, клавишей < w > изменения фиксируются.
Это можно сравнить с работой Git'а, когда после комбинации git add и git commit изменения перемещаются в репозиторий.
Набор важных команд VIM
# Выйти
:q!
# Сохранить и выйти
:wq
# Отменить последнее изменение
u
# Отобразить номера строк
:set number
# Убрать номера строк
:set nonumber
# Изменение текста внутри () {} [] '' открывающих и закрывающих скобок
ci(/{/[
# Перемещение в начало строки
_
# Перемещение в конец строки
$
# Перемещение курсора вверх/вниз
j/k
# Перемещение курсора на 10 строк вверх/вниз
10j/10k
# Перемещение курсора влево/вправо
h/l
# Перемещение курсора на 10 символов влево/вправо
10h/10l
# Перемещение в начало файла
:1
# Или
Нажмите gg
# Перемещение в конец файла
:$
# К последней строке
G
# Открыть файлы в разных окнах по вертикали/горизонтали
vim -o/O file1 file2
# Разделить окно по горизонтали/вертикали
:split/vpslit -
# Открыть файл вместо текущего
:edit PATH/file1
# Перемещение между областями разбиения файла
CTRL+W , → ↑←↓
# Удалить слово
:dw
# Удалить 2 слова
:d2w
# Удалить всю строку
:dd
# Удалить 3 строки
:3dd
# Удалить до символа «а»
:dta
# Удалить от символа 'a'
:dfa
# Копирование/вставка
y/p
# Найти
:/pattern
# Открытие новой пустой вкладки в Vim
:tabnew
# Открыть вкладку с заданным файлом
:tabnew PATH/file
# Закрыть вкладку
:tabclose
# Перейти на следующую вкладку
:gt
# Перейти к предыдущей вкладке
:gT
# Переключение на первую/последнюю вкладку
:tabfirst/tablast
А может, принять обе таблетки?
После долгого воздействия «красной таблетки» вам стало чего-то не хватать? Мне, несмотря на интуитивно понятную привязку клавиш, Vim по-прежнему казался слишком ограниченным. Я решил поэкспериментировать с такими плагинами, как NERDTree, VimBundle, Plug, fzf, NeoVim и т.д. Но даже с многочисленными возможностями кастомизации и притязаниями Vim находиться в топ-листе редакторов, мне так и не удалось избавиться от ощущения странной пустоты.
Чего мне не хватает? — cпросил я у Оракула.
Ты скучаешь по ощущениям. По тем, которые не можешь воспроизвести. Перестань себя обманывать, ведь путь проходит не только там, где ты сейчас, но и там, где ты уже был.
И пришло ко мне понимание — я пытался отрицать тот факт, что мне нравится визуальный подход к написанию кода. Наглядность графического интерфейса помогает мне. От просмотра конфликтов Git до линтинга, выделения строк и всего такого прочего.
Учась языку Java на BlueJ в детстве, я осознал важность графического аспекта. Несмотря на мнение об элитарности Vim, я убеждён, что программирование — многогранная область. Люди обладают разными предпочтениями, некоторые из них более склонны к визуальным, слуховым или математическим подходам.
Если бы редакторы на основе графического пользовательского интерфейса не имели своих преимуществ, у нас не было бы различных плагинов, иконок и прочих надстроек для Vim. Своей простотой он напоминал бы обычный терминал. Веб-интерфейс Jupyter Notebook не был бы создан, если бы Python REPL был реально удобен в использовании. Отпала бы необходимость в PyPI или Git Kraken. По иронии судьбы, сама концепция Vim использует математическую парадигму в виде машины с конечным числом состояний (FSM), которая тесно связана с классом графических моделей. Визуальную и математическую идеологии нельзя просто взять и отделить от кода, они идут рука об руку.
Есть золотая середина: использование VS Code с привязками клавиш Vim. Мне это помогло. Скорость и эффективность Vim сочетается с богатыми возможностями, предоставляемыми Visual Studio Code. Это лучшее из обоих миров. Интересно, сколько людей использует подобные редакторы только для того, чтобы выглядеть крутыми, несмотря на то, что ненавидят этот инструмент?
Выводы
В заключение хочу сказать — моё знакомство с Vim было похоже на принятие красной таблетки и путешествие в страну традиционных сред программирования. Хотя изначально Vim покорил меня своей эффективностью и мощным интерфейсом командной строки, вскоре я осознал ценность поиска баланса. Независимо от того, к какому подходу вы склоняетесь, важно найти золотую середину. На мой взгляд, VS Code с привязками клавиш Vim объединяет всё самое лучшее. Давайте помнить: в стремлении к кодерскому мастерству нам должны сопутствовать гармония и баланс между эффективностью и лёгкостью работы!
Комментарии (137)
Arkasha
01.12.2023 22:02+30tldr: очередной неофит сравнивает редактор с IDE и пользуется ms vs code. Гениальная свежая мысль, к которой пришел автор: используйте vim-mode в IDE
PuerteMuerte
01.12.2023 22:02+20А сколько людей яростно доказывает, что vs code - не IDE, а редактор. И вот те на, достаточно было сравнить его с vim :)
APh
01.12.2023 22:02Но, МС Коде же не ИДЕ, а редактор кода. (Мы все понимаем, что какие-то функции пересекаются.)
PuerteMuerte
01.12.2023 22:02Кстати, а почему не IDE? У стоковой VS Code сразу после установки есть навигация по коду, автодополнение, рефакторинг, интеграция с гитом, средства запуска и отладки и т.д. Чего в ней ещё не хватает, чтобы это была IDE?
Arkasha
01.12.2023 22:02Если я вам дистрибьютив vim соберу со всем вышеуказанным, вы его тоже будете IDE называть? Мне правда интересно понять вашу логику.
PuerteMuerte
01.12.2023 22:02Если я вам дистрибьютив vim соберу со всем вышеуказанным, вы его тоже будете IDE называть?
И будете поставлять это как один цельный продукт и сопровождать сами? Да, естественно. Если вы возьмете современные IDE, там тоже вас встретит не монолитный исполняемый файл со всем функционалом, а пустая, но расширяемая оболочка, и подключаемые к ней плагины/пакеты, которые реализуют весь сопутствующий функционал, будь-то отладка, автодополнение или интеграция с контролем версий. Чем плагины, которые обеспечивают функционал IDE в Visual Studio 2022, отличаются от плагинов, которые обеспечивают функционал IDE в VS Code, если и те, и другие разрабатываются одной и той же конторой, и идут в одном цельном бандле?
MiyuHogosha
01.12.2023 22:02+1Вы получите что-то вроде IDE от ТурбоПаскаля 3.3. А потом они перешли на копирование Голого Деда (GoldEdit)
t3n3t
01.12.2023 22:02К слову, в VS Code vim-like плагины один ужаснее другого. То индентация при undo слетает, то еще что. В IDE-шках от IntteliJ значительно лучше с этим делом, но тоже не блеск.
Cels
01.12.2023 22:02+2'Копирование/вставка - y/p'выделение текста в Vim:
Отметить начало текста при помощи "v", "V" или CTRL-V.
Переместить курсор в конец визуального фрагмента. При этом текст от начала визуального выделения до конца включительно будет подсвечен.
Ввести команду-оператор. Команда выполняет действия над выделенной областью.
nikweter
01.12.2023 22:02А если подключился на удалёнку, копируешь что-то на локальном компе и нужно вставить удалённый vim?
vamal
01.12.2023 22:02Мыша спасает.
nikweter
01.12.2023 22:02+1С какой-то версией ubunty и дебиан по умолчанию мыша не спасает. Вместо вставки включается какой-то режим визибл или что-то в этом роде. Нужно ввести команду set mouse=p вроде. Ну или свой конфиг везде таскать. Меня задолбала эта тема, Я стал использовать нано.
sena
01.12.2023 22:02+17Изучить Вим и не изучить Емакс это как познать инь и не познать ян. Статья о Вим всегда неполна без упоминания Емакс и наоборот.
MAXH0
01.12.2023 22:02+16Просто те, кто упал в нору Vim, уже оценили глубину норы, а кто полез в Емакс еще в полёте!
Вы же в курсе, что кривая освоения Emacs - Странный аттрактор
Ingeniosus
01.12.2023 22:02Тем более, что он так же хорошо работает без гуя, имеет кучу плагинов и релизов типа spacemacs. Который как раз в nw на серваке отлично работает.
Lirix_vladimir
01.12.2023 22:02+2Почему последнее время на хабре все больше и больше статей про вим?
sdramare
01.12.2023 22:02+4NeoVim активно форсят стримеры, типа Primeagen, вот их аудитория и поднимает статьи как стать кулхацкером, программирующим в терминале.
gmtd
01.12.2023 22:02+9Явное преимущество Vim становится очевидным при подключении по SSH к удаленным серверам. В таких сценариях VS Code не слишком удобен, в то время как для ввода «vim» с клавиатуры и начала редактирования потребуется всего пара секунд.
?
Не нужно решать потенциальные проблемы с обновлениями, дающими сбой или конфликтующими с расширениями. В таких ситуациях трудоёмкая отладка вам обеспечена.
??
Кроме того, VSCode принадлежит Microsoft, но, являясь продуктом с открытым исходным кодом, потенциально уязвим для злоумышленников.
???
Таким образом риск, связанный с использованием исключительно VS Code, будет неоправданным.
Кто не рискует, тот не пьёт шампанского!
Спасибо за бодрое начало утра нового дня )
Zakhar_82
01.12.2023 22:02+3В vim нет языковых модулей с подсветкой синтаксиса что ли? Тоже мне причина :) вот глобальный поиск и автозамена по проекту средствами баш ИМХО более серьезная и сложно выполнимая задача. Есть даже аналог gitlens.
PuerteMuerte
01.12.2023 22:02+1вот глобальный поиск и автозамена по проекту средствами баш ИМХО более серьезная и сложно выполнимая задача
А какая разница, каким средствами вы будете делать глобальный поиск и автозамену по проекту?
Zakhar_82
01.12.2023 22:02+3В ide это нормально работает в рамках добавленной папки, оперируя концепцией папка=проект, а в виме нет понятия проект, ну во всяком случае мне не встречался метод это реализовать. Искать по проекту приходится постоянно, чуть реже делать поиск с заменой и я не знаю как это грамотно через вим реализовать,чтобы это не было сложно.
includedlibrary
01.12.2023 22:02+1В виме это можно делать с помощью LSP. Но у меня так и не получилось его нормально настроить, пришлось перейти на emacs, в котором LSP работает нормально.
AndreiNekrasOn
01.12.2023 22:02Если всё-таки хочется попробовать вим с lsp, советую начать с какого-нибудь дистрибутива (в смысле конфига) неовима, типа NvChad или LunarVim.
vtb_k
01.12.2023 22:02+1В Емакс все делается по проекту и поиск и запуск тестов и замена и куча всего другого
https://projectile.mx/
AnimeSlave
01.12.2023 22:02В Vim это на уровне самой операционной системы реализуется. Есть стандартная папка. Обычно папка пользователя. Vim её ставит основной при старте. Для того, чтобы изменить её нужно выполнить команду cd для которой передать путь до папки, где лежит проект. И тогда всё будет работать так же, как в VS Code. А чтобы это происходило автоматически при загрузке файла нужно настраивать Vim. И каждый пользователя это делает сам. И это уже боль в каком-то смысле из-за гибкости настройки Vim
Arkasha
01.12.2023 22:02+1вот глобальный поиск и автозамена по проекту средствами баш ИМХО более серьезная и сложно выполнимая задача
Я это на баше напишу быстрее, чем в ms vs code поиск отработает)
iig
01.12.2023 22:02Удачи рефакторить глобальную переменную i на bash %)
saboteur_kiev
01.12.2023 22:02а почему i а не counter, например?
megasuperlexa
01.12.2023 22:02+4Кроме того, VSCode принадлежит Microsoft, но, являясь продуктом с открытым исходным кодом, потенциально уязвим для злоумышленников.
повеяло Балмером
MiraclePtr
01.12.2023 22:02+9Расскажите автору кто-нибудь, что vim тоже является "продуктом с открытым исходным кодом"...
SergeyMax
01.12.2023 22:02+6Вообще ситуация складывается действительно довольно опасная, получается, что злоумышленники могут просто похитить исходники вашего vim, и не понести никакого наказания?
JYE
01.12.2023 22:02Я недавно скачал vim, он мне не понравился. Как закачать его назад? кому то ведь нужнее
ApeCoder
01.12.2023 22:02+7Переводчик немножко испугался переводить полностью
Additionally, considering that VSCode is owned by Microsoft, an open-source but potentially vulnerable to security breaches, or could face disruptions due to geopolitical events such as sanctions or conflicts, the risk involved in relying solely on it may not be worthwhile.
unclegluk
01.12.2023 22:02+4Сейчас отхвачу минусов много, но как Человек, я хочу перемещаться по тексту максимально просто. Vim и подобные ему, такой очевидной возможности не дают. Но если вам важна скорость набора кода, то теперь мне понятно, из-за чего появляется говнокод.
vtb_k
01.12.2023 22:02+8как Человек,
А те, кто использует Vim/Emacs уже не люди?
Vim и подобные ему, такой очевидной возможности не дают.
Я вам гарантирую, что я перемещаюсь по тексту максимально просто, используя Емакс
unclegluk
01.12.2023 22:02+7А те, кто использует Vim/Emacs уже не люди?
Интересная аналогия. Может расскажете о нелюдях?
Я вам гарантирую, что я перемещаюсь по тексту максимально просто, используя Емакс
Сочувствую. У меня полноформатная клавиатура с блоком со стрелочками. Удобней ничего не придумали еще.
vtb_k
01.12.2023 22:02-2Интересная аналогия. Может расскажете о нелюдях?
Боюсь, не поймете, для вас это слишком "сложно"
Удобней ничего не придумали еще.
Для обезьяны?
includedlibrary
01.12.2023 22:02+2Сочувствую. У меня полноформатная клавиатура с блоком со стрелочками. Удобней ничего не придумали еще.
А чему тут сочувствовать? Каждый пользуется тем, что ему удобно. Мне не нравятся срелочки, я ими не пользуюсь, вам нравится, вы пользуетесь. В чём проблема?
Каждый раз удивляюсь, что люди пишут несколько сотен комментариев, доказывая друг другу, что vim/emacs - хрень, или наоборот, что vim/emacs - классный инструмент.
budnikovsergey
01.12.2023 22:02придумали-придумали: посмотрите про концепцию работы с клавиатурой "home row". Она не про скорость, она про эргономику движений для кистей рук для их здоровья спустя долгие годы и про помощь при слепой работе с клавиатурой. И vim наработал многое из этой концепции. Его ценность не в самой программе vim, а в эргономичном решении, которое можно включить практически в любой IDE или в других продвинутых редакторах вроде Emacs.
AnimeSlave
01.12.2023 22:02+7Выучив некоторые плагины и команды Vim, можно перемещаться максимально просто и быстро не только по тексту, но и по файлам в системе. Тут скорее для вас важен интуитивный подход. Vim в этом случае ломает привычную картину. Тоже самое делает тайловый оконный менеджер. У всего есть свои плюсы и минусы. Но считать, что Vim не даёт очевидной возможности не правильно. Vi появился за долго до современных операционных систем. Его концепция проверена годами. Есть люди, которые не хотят менять свои привычки. И только в этом проблема
DirectoriX
01.12.2023 22:02+3Vi появился за долго до современных операционных систем. Его концепция проверена годами.
Как вам, нормально на проверенном годами ADM-3A работается в 2023?
AnimeSlave
01.12.2023 22:02+2Простите за резкость. Но при чём здесь ADM-3A? Решили блеснуть эрудицией? У вас с контекстом проблемы? Vim используется до сих пор, а ADM-3A нет. Значит Vim прошёл проверку временем, а ADM-3A нет. Почему Vim пользуется популярностью до сих пор вы знаете?
PuerteMuerte
01.12.2023 22:02Простите за резкость. Но при чём здесь ADM-3A
Ну так и vi тут не причём, честно говоря. Vim популярен не столько за саму концепцию работы с текстом, сколько за то, что к ней прилагается крутой и гибко настраиваемый инструментарий.
AnimeSlave
01.12.2023 22:02+1Я отвечу так, вы ошибаетесь. Вся гибкость Vim это наросты, которые притаскивали в него из других мест. Когда-то не было DAP. Не было LSP. Не было приближённого поиска (fuzzy search). Много чего не было. Если бы оно было нужно, то это бы давно «изобрели» сами пользователи Vim, и оно бы стало частью Vim. Но этого нет, так как не всем нужны эти вещи. Vim используют не из-за этого, а именно из-за особенности работы с текстом, из-за его другой концепции. Концепции режимов. Опять же, есть другие редакторы со своими особенностями, и даже, в некоторых случаях, лучшими возможностями настройки (оставаясь обычным текстовым редактором), но при этом Vim не исчез, и даже не теряет популярность. Даже появляются его подражатели, типа Kakoune или Helix (есть и другие)
DirectoriX
01.12.2023 22:02+9Vim, и тем более vi, теряют популярность из-за форков, того же NeoVim.
А вот почему всё семейство пользуется популярностью (относительной) - нет, не понимаю.
Без супер-конфига (кстати, почему скрипты на vimscript/Lua называют "конфигами", хотя тот же
.bashrc- это всё равно скрипт, хоть и настраивающий окружение?) и пачки плагинов сам редактор может выполнять только некоторые... интересные действия, польза которых зачастую сомнительна (типа "прыгнуть на 3 слова вперёд").-
С плагинами - это всё равно не "vim такой мощный и удобный", это "плагины такие мощные и удобные, спасибо vim что имеет поддержку плагинов".
Кстати, один из основных аргументов в пользу vi-семейства - "я могу делать то же самое, что и IDE, с помощью LSP". Интересно, что LSP как технологию придумал и реализовал не кто-нибудь из сообщества vim, а ребята из Microsoft для VS Code... Похоже, что vi-сообществу было нормально не уметь подражать IDE, пока не появился другой редактор, который умеет. Вот она, конкуренция, толкающая прогресс.
Аргумент "нужно нажимать меньше клавиш для редактирования" - странный из-за методики подсчёта. В некоторых случаях - да, соглашусь. В некоторых - наоборот. Почему-то vim-пользователи любят считать горячие клавиши современных редакторов/IDE так: "Ctrl+S = два нажатия", а "Ctrl+Shift+S = три", но при этом и d, и D - одно (хотя второе - это явное "Shift+D"), и обычно совсем игнорируют бесконечные Esc.
Скорость работы самого редактора как обычно демонстрируют (например, упомянутый где-то здесь Primeagen)? Правильно - переключаясь между разными файлами, или вовсе между файлом и навигацией по ФС, раз 5 туда-сюда. Разумеется, переключает это всё не сам редактор, а плагин(-ы). Это примерно как демонстрировать комфорт автомобиля открывая и закрывая багажник.
Часто ещё любят хвалить быстрый запуск (по сравнению с IDE). С появлением и распространением LSP, время старта клиента становится несущественным, потому что всё равно надо дожидаться загрузки и готовности этого самого LSP. А замерять время старта только редактора-оболочки... пустые, без проекта, IDE обычно тоже запускаются довольно быстро, особенно нынче, на SSD. Да и обычно этот запуск происходит всего пару раз за день. Это ж за месяц может суммарно накопиться десяток минут разницы, как раз будет время с конфигом поиграться.
В итоге, большинство аргументов в пользу использования vim-семейства как будто бы являются актуальными не столько для разработчиков, сколько для админов, которым и ходить по разным серверам приходится (а там как раз уже стоит vim!), и вносить точечные изменения в произвольные файлы в произвольные моменты времени (тут и может понадобиться та самая "странная навигация" и быстрый запуск).
Несколько другой вопрос про vim-управление в других редакторах/IDE, но это уже больше дело привычки. Я, например, в своё время не подружился с CLion именно потому, что в IDE от JetBrains горячие клавиши, мягко говоря, отличаются от тех, которые можно встретить в большинстве других IDE/редакторах; ключевым отличием для меня стало то, что Replace (в открытом файле) - это почему-то Ctrl+R, хотя везде это Ctrl+H. И нет, я всё равно не понимаю, зачем в современных, графических редакторах может понадобиться модальность.
Ну и наконец нельзя не вспомнить про другие явления, которые "прошли проверку временем". Сколько проектов в своих стандартах форматирования кода до сих пор требуют ширину 80 символов, потому что перфокарты IBM стандарта 1928 года были шириной в 80 символов (а потом "ну так исторически сложилось, значит прошло проверку временем, значит правильно")?
AnimeSlave
01.12.2023 22:02+4У вас очень странные претензии, будто бы вас пользователь Vim'а покусал и оставил след на всю жизнь.
Этот редактор подходит не всем. У него своя аудитория. У него свой workflow. Если вам он не подходит, то почему он не должен подходит всем? Выглядит, как эгоцентризм. И видно, что вы не пользовались им полноценно.
Я отвечу только на часть тезисов конкретно:
потому что всё равно надо дожидаться загрузки и готовности этого самого LSP.
Не нужно. Плагин, стартует сразу, при старте Vim, а LSP-сервер подгружается в фоне. Редактировать можно сразу. Но если нужны будут возможности LSP, то придётся подождать. И время зависит от конкретного LSP-сервера. Где-то это миллисекунды, где-то десятки секунд.
Сколько проектов в своих стандартах форматирования кода до сих пор требуют ширину 80 символов
Я один из тех, кто приветствует такой подход. И он объясняется банально. Проще читать код, строки которого помещаются сразу на экране. И еще очень удобно такой код распечатывать на бумаге, так как не требует форматирования, и не будет съезжания строк. Опять же, удобнее будет читать. То есть нет тут никакой конкретной привязки к прошлому. Просто для кого-то было удобно тогда, и для кого-то так же удобно сейчас
DirectoriX
01.12.2023 22:02+3Если вам он не подходит, то почему он не должен подходит всем?
Я такого не говорил и даже не подразумевал. Более того, мне вообще без разницы, чем пользуетесь вы или кто-либо другой - старый vi, чуть менее старый vim, neovim, emacs, nano, mcedit, VS Code, IDEA, или вообще LibreOffice Writer, главное чтоб не навязывали свой выбор окружающим.
Не нужно. Плагин, стартует сразу, при старте Vim, а LSP-сервер подгружается в фоне.
Согласен, неверно сформулировал мысль. Хотел сказать что-то вроде " всё равно надо дожидаться LSP для полностью готового окружения". Так-то и в других IDE-редакторах процесс анализа проекта обычно идёт фоном, и можно начинать редактировать файл сильно раньше, чем всё будет готово полностью.
никакой конкретной привязки к прошлому
Логично, что должно быть какое-то разумное ограничение, но речь идёт именно о 80 символах. 80 символов - это примерно треть ширины экрана (обычного, FullHD). Я согласен, что читать текст, размазанный по всей ширине экрана не очень удобно, но ТРЕТЬ? Много проектов перешли на 120 символов в ширину (или требуют их с самого начала), это хотя бы половина экрана получается, спасибо им.
Для печати - возможно, около 80 символов в самый раз (хотя опять-таки, почему не 70 и не 90, а именно 80?) Померил только что размер шрифта в "Совершенном коде" Макконнелла от БХВ - там как раз 80 выходит на ширину страницы (20 символов на 3 см). На альбомный же лист спокойно поместились бы все 120...Что мешает, например, графическим эмуляторам терминалов иметь ширину по умолчанию в те же 120 символов? Но нет, если открыть условный Git Bash или терминал XFCE, то они будут иметь размер 80х24, прям как VT100, прям как перфокарты IBM. Хотя в Windows Terminal, например, осмелились проигнорировать это сомнительное наследие, там размер аж 120х30.
AnimeSlave
01.12.2023 22:02-1Я такого не говорил и даже не подразумевал.
Простите за это. Возможно мне показалось
...а именно 80?
Я уже ответил. Просто читать удобнее. Бы было по другому, то давно бы сменили. Зачем менять то, что себя оправдывает в большинстве случаев? Если вы хотите свести перфокарту и экран, то это может быть лишь натяжкой, потому что перфокарты были и 12 строчные. И были телетайпы с большими размерами. 24 строки (25 в некоторых терминалах), судя по исторической справке из интернета, были приняты как стандарт из-за терминалов, у которых в основном были экраны с форматом 4:3. И в них при полной строке в 80 символов помещались удобно 24 строки, читаемого с экрана шрифта.
В нынешних реалиях это выглядит странно для некоторых экранов. Особенно для тех у кого экран с форматом 21:9. И разрешение вплоть до 8К. Но у всех ли такой формат и такой размер экрана? Все ли открывают на полный экран один файл в IDE? То есть нужна точка отсчёта для того, чтобы всем было комфортно вне зависимости от того, какой у них экран. И для этого делают что-то типа «legacy»-режим для всех. И лучше всего для этого подходит 80 строк. Кому не нравится - меняют размеры. Такая возможность есть и это замечательно. У меня терминал запоминает последнее закрытое состояние Оно практически всегда не равно 80 символам. Но код я пишу ограничиваясь 80 символами. И потому могут быть такие строки:
pub fn draw(self: Player) void { self.texture.drawPro( self.rect, raylib.Rectangle{ .x = self.position.x, .y = self.position.y, .width = self.rect.width, .height = self.rect.height, }, raylib.Vector2{ .x = 0.0, .y = 0.0 }, 0.0, raylib.Color.white, ); }А вот тоже самое, но в одну строку:
pub fn draw(self: Player) void { self.texture.drawPro(self.rect, raylib.Rectangle{.x = self.position.x, .y = self.position.y, .width = self.rect.width, .height = self.rect.height}, raylib.Vector2{ .x = 0.0, .y = 0.0 }, 0.0, raylib.Color.white); }Или чуть «чище» по Дядюшке Бобу:
pub fn draw(self: Player) void { const rect_bound = raylib.Rectangle{.x = self.position.x, .y = self.position.y, .width = self.rect.width, .height = self.rect.height}; const rect_anchor = raylib.Vector2{ .x = 0.0, .y = 0.0 }; self.texture.drawPro(self.rect, rect_bound, rect_anchor, 0.0, raylib.Color.white); }Мне лично удобнее читать первый вариант.
Хотя в Windows Terminal, например, осмелились проигнорировать это сомнительное наследие
Это microsoft, им виднее как лучше. [Сарказм]
PuerteMuerte
01.12.2023 22:02+1Оно практически всегда не равно 80 символам. Но код я пишу ограничиваясь 80 символами.
Ну а смысл? 80 символов - это размер экрана IBM PC 1981 года. Я вот только что проверил, на маленьком 17" экране, процентов сорок которого занято тулбарами, отображается 120 символов. Печать исходников на принтере? Тоже совсем не актуально. Сейчас совершенно незачем закладываться на этот размер.
Мне лично удобнее читать первый вариант.
Как отдельно взятый сниппет - наверное да, а когда ты листаешь длинный файл исходников, где каждый параметр каждой функции в отдельной строке, такое полотенце кода вообще нифига не эргономичным оказывается.
AnimeSlave
01.12.2023 22:02Про смысл я ответил уже. Про сниппет. Вы очевидно не читали портянки кода, где в одном файле 10-12 тысяч строк и очень много из них длинной свыше 120 символов. Я именно после того как почитал такой код стал пересматривать свою же привычку писать длинные однострочники. Это очень сильно усложняет чтение кода. Намного важнее быть ясным в коде, чем лаконичным
PuerteMuerte
01.12.2023 22:02+1. Вы очевидно не читали портянки кода, где в одном файле 10-12 тысяч строк и очень много из них длинной свыше 120 символов.
Мне кажется, вы просто не сталкивались с реальной разработкой, если такое пишете.
1:1
А теперь по существу. Я не говорю про то, что строка кода должна быть длинее, чем видимое окно редактора, и чем принятый в команде размер строки, хотя бы упомянутые мной 120 символов, это уже почти дефолт. Нет, не должна, но и писать каждый параметр с новой строки - это тоже перегиб в другую сторону. Навигация по такому длинному полотенцу просто замедляется.
iig
01.12.2023 22:02Что мешает, например, графическим эмуляторам терминалов иметь ширину по умолчанию в те же 120 символов?
Все в наших руках ;)
RH215
01.12.2023 22:02это почему-то Ctrl+R, хотя везде это Ctrl+H
Я Ctrl+R чаще вижу. Ctrl+H - это что-то майкрософтовское.
DirectoriX
01.12.2023 22:02Может быть и так. Основной системой что тогда, что сейчас у меня является Windows (хоть и разрабатываем под Linux, но делаем это удалённо, либо "локально" в WSL). Насколько помню, всякие Thunderbird, LibreOffice, Qt Creator, VS Code имеют одинаковые сочетания клавиш и в Win, и на Linux, и это именно
Ctrl+Hдля замены.
... хотя в Qt Creator может и вообще нет отдельного сочетания для замены, там вроде толькоCtrl+F? Эхх, давно уже им не пользовался...Как бы то ни было, в моём "везде" это всё равно
Ctrl+H, так что для меня CLion был непривычно-неприятной белой вороной. Конечно, были и другие причины, почему он мне не понравился (например, тогда, в 2019, он ещё довольно туго работал с Qt).
MAXH0
01.12.2023 22:02+3"Максимально просто" здесь надо читать "используя манипулятор мышь"?
iig
01.12.2023 22:02+10
Sadaell
01.12.2023 22:02Так это же
r _ C-u x $ C-d k h j lс той лишь разницей, что правую руку приходится двигать
iig
01.12.2023 22:02с той лишь разницей, что правую руку приходится двигать
Причем двигать по всей клавиатуре, и обе руки. Удобно ,ага.
Sadaell
01.12.2023 22:02Одно дело двигать отлично параллелящиеся и ловкие пальцы по тем же клавишам, что и при обычной печати, другое - полностью убирать руку с home row и потом искать пупырку
gev
01.12.2023 22:02-2Не просто мышь, а Magic Mouse =)
13werwolf13
01.12.2023 22:02+2это та которой нельзя пользоваться на зарядке? эта та у которой самая модерновая и самая неудобная альтернатива колёсику? эта та которая удобно лежит только в руке фрезировщика-неудачника лишившегося всех пальцев? эта которая весит меньше чем один грузик от нормальной мышки?
ооо дааа.. офигенный выбор..
NurGeo
01.12.2023 22:02Перемещаться по тексту и по файлам в vim очень, очень просто и удобно. Особенно если речь идёт про объявления и использования констант, классов, типов.
Стоимость просмотра объявления: нажать две клавиши, вернуться обратно: нажать две клавиши. Навигация и изучение кода становится приятным и комфортным.
Правда за это надо заплатить настройкой, обучением и привыканием.
Думаю появление говно кода не зависит от скорости набора и даже от используемого редактора)
iig
01.12.2023 22:02Перемещаться по тексту и по файлам в vim очень, очень просто и удобно. Особенно если речь идёт про объявления и использования констант, классов, типов.
Особенно удобно если константа обьявлена где-то за 3 include под 2 ifdef.
vanelm
01.12.2023 22:02+2У vim есть одно неоспоримое преимущество - он (почти) всегда есть. Я его использую каждый раз, когда надо поправить пару строк в конфиге. Если изменения более масштабные - мне не лень использовать mcedit. Ну а для отладки кода - VSCode альтернатив нету. И локально и удалённо и в контейнере и WSL. Обеспечит похожий, если не сказать одинаковый опыт использования (UX). Я прям фанат VSCode. По поводу безопасности. В репозитории компании версия VSCode отстаёт на несколько месяцев. Не знаю, что они там проверяют, но надеюсь, что оно того стоит - тянуть с выпуском. Поэтому на рабочем компьютере у меня 1.79, а на домашнем - 1.85.0-insider
Tellamonid
01.12.2023 22:02Воспользуюсь случаем, и спрошу у фаната VS Code.
какой темой вы пользуетесь? (я поставил себе base16 eighties, чтобы чёрный не выжигал глаза. Редактор выглядит лучше, но, например, окошки поиска/замены выглядят странно, что я даже не пойму, что там кнопки, а что нет)
как в VS Code заменить табы на пробелы? (я нашел через Ctrl-P, и потом >, как заменить ведущие табы на пробелы. А я хочу заменить все)
gev
01.12.2023 22:02Мне SynthWave '84 нравится
Hidden text
gev
01.12.2023 22:02как в VS Code заменить табы на пробелы?
Внизу, в строке состояния, справа:
Откроется меню:
Coppermine
01.12.2023 22:02+8Машина с конечным числом состояний
Бедный конечный автомат, как над тобой только не издеваются :)
sbw
01.12.2023 22:02+7Линуксоид я ненастоящий, поэтому первым делом ставлю far2l. А потом жму F4 и вперёд))
vitiok78
01.12.2023 22:02+4Проблема Vim для меня заключается именно в кастомизации.
Невозможно закончить ремонт, можно его только прекратить. То же самое и с Vim. Погрузившись в эту чёрную дыру, невозможно из неё выбраться. В результате ты постоянно недоволен конфигом, и постоянно хочешь что-то улучшить. Сама возможность улучшения заставляет тебя этим заниматься. А ведь надо ещё и работать, но мысль о том, что надо поставить вот ещё один маленький плагин, не отпускает и мешает работе.
С готовыми IDE всё просто: ты либо можешь что-то сделать, либо нет. Это странным образом смиряет твой гипертрофированный перфекционизм и жажду улучшения, оставляя тебя наедине с работой и без этих съедающих мозг мыслей о ещё одном маленьком плагине.
Компромиссным решением в этом случае является установка Vim плагина в IDE. Результатом этого является эффективная и спокойная работа.
PuerteMuerte
01.12.2023 22:02+3С готовыми IDE всё просто: ты либо можешь что-то сделать, либо нет. Это странным образом смиряет твой гипертрофированный перфекционизм и жажду улучшения, оставляя тебя наедине с работой и без этих съедающих мозг мыслей о ещё одном маленьком плагине.
VS Code на вас нет...
dzot_dev
01.12.2023 22:02+3НЕ ПОНИМАЮ как вы работаете в виме :)
Вот самая типовая задача – Ctrl+R (WebStorm, рефакторинг), написал новое название переменной, и вуаля, всё само отрефакорилось, включая вызовы, импорты, и всё-всё-всё что использует, например, метод экспортируемый из модуля.
Ну как это вы сделаете в текстовом редакторе без контекста? Как?
Добавляем Ctrl+M, перемещение сущностей между модулями, и теперь вы можете менять целые модули за считанный Ctrl+R + выбор пути. Как вы в vim сможете отрефакторить сразу 100+ модулей на уровне импортов, да еще и путь выбрать, да еще и сделать это сразу для N-экспортов модуля, а не всё по одному по очереди?
Да ладно с этим рефакторингом, пойдем к интеграции с ЯП.
Как в vim можно смотреть тип переменных в конкретных условиях и пути кода? Не интерфейс, а именно какой тип становится у переменной в зависимости от условий выполнения, от путей кода?
А как насчет графов? Посмотреть на связи модулей и оценить влияние изменений?
Может быть vim может открыть любой файл/интерфейс/класс/прочее в одну комбинацию клавиш + ввод? vim может искать по сотням тысяч индексированных файлов всего за секунды (во всем node_modules целиком)?
А это только общие операции..
Как вы там в vim конфликты в git решаете? Вот так? (https://www.youtube.com/watch?v=iPk4nOLj8w4&ab_channel=VimTricks)? GUI реально очень сырой. Сравните со штормом, то что на видео это прямо конкретно слабо и очень далеко от удобного инструмента.
Интеграция с тестами? Автозапуск тестов без отдельных написанных команд? Сжимаемые отчеты по которым можно нормально навигироваться, а перебирать портянку из вывода команды? а как насчет визуализации coverage прямо в исходнике и написания тестов при помощи отслеживания покрытия написанного кода?
Зачем вам отдельный vim когда основные типовые операции по редактированию файла есть в любой нормальной IDE, и большую часть рутинных операций вы можете как и через хоткеи сделать, так и мышкой где это быстрее?
Зачем вам вот этот редактор из терминала который оброс кучей всего, эдакий Франкенштейн из самопальных плагинов для решения давно типовых и решенных задач, когда есть IDE где есть и интеграции, и давно стабильные и доработанные GUI которые позволяют быстро решать задачи, и даже все основные хоткеи если надо.
Ну вот зачем?
Покажите мне нормальное видео где человек эффективно выполняет все рабочие задачи в vim?
Админы понятно, там вопросов нет, админить сервера по ssh это отдельная тема, пока чисто про разработку на локальной машине.
P.S. Пишите код где хотите, кому где удобно, у меня никаких вопросов или претензий к этому нет, вопросы чисто из интереса.)
AnimeSlave
01.12.2023 22:02+2У вас хорошие вопросы, но есть ошибка понимания. Для контекста. Вы сравниваете полноценную IDE, разрабатываемую под конкретную технологию и конкретный workflow, с текстовым редактором, который из-за гибкости настройки можно превратить в псевдо-IDE. Можно ли повторить в Vim такой же workflow, как в WebStorm? Возможно. Нужно ли? А это решает уже пользователь. Может что-то не хватает пользователю?
У Vim есть поддержка LSP, и при правильной настройке Vim может рефакторить по контексту, если это позволяет конкретный LSP-сервер. Я не знаток JS и потому не совсем понимаю о чём речь в некоторых местах.
Про тип переменных, тоже зависит от LSP-сервера, если он предоставляет такую информацию.
Приближённый поиск тоже есть отдельными плагинами. А открывать файл через командную строку можно. Но есть и другие способы, там много вариантов, может быть можно реализовать такой же как и в WebStorm.
По тестам я не знаток в Vim. Интеграция с какими-то реализациями есть, но есть ли то, что нужно вам, я не знаю.
Я лично пользуюсь NeoVim только потому, что от открытия файла до возможности его полноценно редактировать проходят миллисекунды. И открывается, в моём случае, не голый текстовой редактор, а минимальная болванка IDE с подсветкой синтаксиса, с возможность рефакторинга, запуска тестов, и даже дебага для некоторых ЯП. Это если такое позволяет конкретный проект. Но при этом я вполне нормально работаю в полноценных IDE. На работе, или там где по задаче для меня не хватает возможностей NeoVim.
Мне лично не хочет иногда тратить время на работу в полновесной IDE, когда отредактировать нужно всего одной строчку, или же провести банальный тест. То есть у каждого свои причины использовать тот или иной инструментарий. При этом есть IDE например такие как xCode и Android Studio, которые куски кала. Если вы с ними не работали, то вам повезло не увидеть всё «великолепие» мощнейших IDE от крупных IT-компаний, которые остаются безальтернативным вариантом нативной разработки под iOS и Android
13werwolf13
01.12.2023 22:02+1которые остаются безальтернативным вариантом нативной разработки под iOS и Android
я бы попросил, это apple настолько недоразвитые что вариантов разработки под их ОС просто нет, в случае ведроида таки не обязательно использовать их студию, а для того же vim/neovim есть плагины для работы с android sdk и ndk, да и в qt-creator из коробки есть возможность. и не только писать код (это можно и карандашом на бумажке независимо от ОС, ЯП и платформы), но и собирать, но и запускать эмулятор (к счастью там qemu под капотом так что всё просто работает) и гонять тесты.
gerod
01.12.2023 22:02я vim пользуюсь только когда по ssh подключаюсь в незнакомые сервера, так что о нем почти ничего не знаю. Прочитав ваш ответ на вопросы выше, задался вопросом - правильно ли я понял, что с помощью LSP серверов(они локально поднимаются или где то хостяться?), или может это плагины так называете, вы дополняете стандартный vim новыми функциями? По сути делаете из текстового редактора ide?
gev
01.12.2023 22:02Да, это такие сервера, которые реализуют стандартный протокол для разных языков. Что позволяет любой текстовый редактор, поддерживающий интеграцию с ними, наделить возможностями IDE
AnimeSlave
01.12.2023 22:02По сути делаете из текстового редактора ide?
Да. Но есть нюанс. Не полноценную, но достаточную для меня для работы над моими проектами. В такой IDE вполне можно писать, рефакторить, дебажить, тестировать код на C++ (этот язык лишь пример, так как я являюсь разработчиком на C++ больше степени). Можно и другие языки так же настраивать. И настройки почти не отличаются в большинстве случаев. Только настройки LSP-серверов будут отличаться практически всегда и с ними всегда долгая возня, если настраивать с нуля
может это плагины так называете, вы дополняете стандартный vim новыми функциями?
Всё верно. Обычные скрипты для конфигурации самого Vim'а
(они локально поднимаются или где то хостяться?)
Для простоты локально, но никто не запрещает размещать их в сети. Я по крайней мере ни видел примеров сетевого размещения, но возможность всё-таки есть.
vtb_k
01.12.2023 22:02-1давно стабильные и доработанные GUI которые позволяют быстро решать задачи, и даже все основные хоткеи если надо.
Не позволяют они нечего быстро сделать. Я вообще мышь не использую. Потому что дико бесит переставлять руку с клавиатуры. Я пришел в вим а потом в емакс, чтобы избавиться от медленной мыши. Уберите руки с мыши и вы нифига не сделаете в вашей иде. И это реально единственная причина
Aldrog
01.12.2023 22:02Вот самая типовая задача – Ctrl+R (WebStorm, рефакторинг), написал новое название переменной, и вуаля, всё само отрефакорилось, включая вызовы, импорты, и всё-всё-всё что использует, например, метод экспортируемый из модуля. Ну как это вы сделаете в текстовом редакторе без контекста? Как?
С курсором на символе grn<NewName><Enter>
Работает именно как вы описали. Естественно не из коробки, предварительно был установлен плагин с LSP и хоткеи прописаны в конфиге.
Alexey2005
01.12.2023 22:02+3Единственное, что меня печалит в vim - это невозможность нормального скроллинга при работе с длинными строками (несколько экранных строк, включён soft wrapping).
Я хочу, чтобы когда я довёл курсор до самой нижней строчки экрана и нажал "проскроллить вниз", текст поднялся ровно на одну и только одну экранную строчку, причём чтобы курсор встал именно на неё.
Этой фичей обладает абсолютно любой текстовый редактор, даже Notepad, но не vim. В vim такого поведения добиться абсолютно невозможно, и скроллинг текста по-настоящему мучителен: каждый раз приходится искать глазами курсор, который смещается вверх на рандомное количество строчек.
artemisia_borealis
01.12.2023 22:02+1Частично эту проблему решает относительно новая опция
smoothscrool(доступна только в Vim 9):set warp smoothscroolОднако и прокрутку придётся делать с помощью
Ctrl+EиCtrl+Y. И курсор там едет вместе с текстом. Не исключено, что это можно решить map'ингом, но мне лень этим заниматься ибо не очень актуально.Брам писал ещё в прошлом году, что она [эта опция] ещё совсем не perfect. Допилят ли теперь, непонятно.
johnfound
01.12.2023 22:02+3Ну не знаю. Я программировал на редакторах и IDE о которых большинство здесь присутствующих никогда не слышали в силе своей молодости – например Merlin.
Мне VIM категорически не нравится, потому что он разделяет навигацию по тексту от редактирования того же текста. А для меня эти процессы всегда были часть единого целого.
И от IDE я хочу именно чтобы чтение, навигация/поиск и редактирование/написание были объединены, а не разделены в разных режимах. Это является непростой задачей, потому что эти действия на самом деле очень разные. VIM пошли по легкому пути – если разные, давайте разделим. Но ошиблись, потому что цель редактора на самом деле это предоставить максимально единую среду редактирования. Потому что мы обдумываем, читаем и пишем текст одним мозгом и редактор должен предоставить максимально прозрачный интерфейс между нашими мыслями и редактируемым текстом.
Aldrog
01.12.2023 22:02+2Не хочу переубеждать, но не могу не поправить.
Командный режим в Vim служит и для навигации, и для редактирования. Отдельные режимы есть для вставки (как промежуточный этап некоторых команд редактирования) и выделения (в нём команды редактирования ведут себя немного иначе, применяясь к выделению и завершая его, навигация же продолжает работать как в командном режиме).
saboteur_kiev
01.12.2023 22:02+1Vim не таит в себе никакого волшебства. Он ориентирован на программистов.
Неа. Он ориентирован на продвинутых пользователей консоли.
Когда создавался Vi/Vim это был программист/сисадмин/QA в одном.P.S. Иногда создается впечатление, что программисты вообще не подозревают, что кроме них в IT еще полно самостоятельных полноценных направлений.
PuerteMuerte
01.12.2023 22:02Неа. Он ориентирован на продвинутых пользователей консоли.
Он ориентирован на любителей vim. Вы можете быть богом консоли, но предпочитать традиционные редакторы.
saboteur_kiev
01.12.2023 22:02Мое замечание относилось к ориентации на программистов, хотя vim явно на них не ориентирован изначально.
PuerteMuerte
01.12.2023 22:02хотя vim явно на них не ориентирован изначально.
Ну а кто ещё, кроме некоторых программистов/девопсов/админов, будет что-то писать в настолько не WYSIWYG-редакторе? Я уже писал свой тезис, хоть не бесспорный, но тем не менее, я его считаю верным. Популярность vim не в продуктивности такого подхода к набору текста, а в том, что к ней приделали хороший набор инструментов. Я более того скажу, парадигма vi/vim, она ни разу не уникальная, все редакторы 1970-х были похожими, и даже в MS DOS встроенный редактор был подобным. Они просто все вымерли в процессе эволюции, когда по-моему, в 1979-м вышел WordStar, который был не таким, а предлагал привычную всем нам парадигму редактирования текста. Тогда это было офигенной инновацией.
saboteur_kiev
01.12.2023 22:02а предлагал привычную всем нам парадигму редактирования текста.
Давайте не обобщать =) Мне вполне привычнен не WYSIWYG редактор. Точнее plain text для меня роднее, чем rich format, если говорить про код и конфиги.
И я отлично помню и golded и "слово и дело" и vc другие редакторы.
И как бы vi/vim совсем даже не похож на них.PuerteMuerte
01.12.2023 22:02очнее plain text для меня роднее, чем rich format, если говорить про код и конфиги.
Я же не про это :)
я отлично помню и golded и "слово и дело" и vc другие редакторы.
И не про это, это всё WYSIWYG-редакторы, вы там тоже получаете на принтере то, что видите на экране. Просто в какой-то период времени подросшие "стандарты качества" стали требовать для этого ещё и белый лист на экране рисовать, да с разбивкой на страницы, но то уже было потом.
Я про редакторы, у которых есть режим ввода текста, и есть командный режим. Простейший пример, упомянутый мной, но не названный выше edlin из MS DOS.
Borjomy
01.12.2023 22:02-2На дворе скоро 2024 год. А пользователи Linux пользуются убогой недоделанной поделкой тридцатилетней давности. Просто позорище. Да еще радуются.
Бесплатный труд никак не способствует уважению к чужому труду.
includedlibrary
01.12.2023 22:02+2\S Вот недолюди-то!
А на самом деле смешно смотреть на бурную реакцию людей, когда дело касается вкусовщины. Обсуждение vim vs emacs vs IDE vs etc. - чистой воды вкусовщина, я бы ещё понял, если бы такая бурная реакция была бы связана с техническим вопросом, а тут просто люди редакторы текста обсуждают :) В прошлый раз статья аж 400 комментариев под собой собрала, в которых люди друг другу доказывали, что использовать emacs/vim - плохо, или наоборот хорошо.
UPD: я и под виндой пару раз вим использовал, на маке так постоянно использую.
LM7777
01.12.2023 22:02+1Я наверное из тех кому важен результат.
У меня сложилось впечатление, что Vim это про путь. Точить/создавать свой клинок, до какого-то своего идеала.
Для меня выход из VisualStudio с R# уже "стресс". Хотя тоже тот ещё инструмент. VisualCode, насколько понял, лучше в поддержке различных технологий, скорости установки, множеством плагинов, комьюнити. Но по мне сильно отстаёт от того же VS + R# в работе (с теми технологиями под которые они заточены).
Итого (на вскидку):
Минимальный вход.
Установил и работаешь с минимумом настроек.
Инструмент не должен отвлекать.
Инструмент должен брать на себя как можно больше работы.vtb_k
01.12.2023 22:02-1Я наверное из тех кому важен результат.
У меня сложилось впечатление, что Vim это про путь. Точить/создавать свой клинок, до какого-то своего идеала.Какой именно результат?
Iron_Butterfly
01.12.2023 22:02vim-ом пользуюсь лет 25 уже и менять ни на что не собираюсь. Автор явно неправ, называя его редактором для программистов. Я бы сказал, в первую очередь он редактор для сисадминов.
GoodOldDude
01.12.2023 22:02А может, принять обе таблетки?
Ну вот спасибо, теперь не отпускает мысль о том, что было бы с Нео... Какой эффект это бы возымело в контексте самого фильма? :)
m_ax1m
01.12.2023 22:02В неовиме все lsp есть и легко подключать любые утилиты. Наверное и в vscode это есть, просто он точно будет медленнее переваривать например поиск по тысячам файлов с grep.
boraldomaster
01.12.2023 22:02Вероятно для hello world проектов с двумя тремя файлами текстового редактора достаточно, но если у вас сложный проект с зависимостями, библиотеками, системами сборки вроде Maven и Gradle, сложными фреймворками и т.д., просто невозможно представить эффективную работу без нормального IDE.
Vim был хорош в своё время, но как можно спорить, что сейчас, когда выбор IDE так велик, можно обойтись текстовым редактором для сложного проекта?
vtb_k
01.12.2023 22:02просто невозможно представить эффективную работу без нормального IDE.
Все проблемы здешних отрицателей вима/емакса можно точно передать вот этой фразой. А раз невозможно представить - значит этого не существует? Особенно смешно это слышать тому, кто как раз и переходил с "современных иде" в вим, а потом в емакс, чтобы повысить свою эффективность
AnimeSlave
01.12.2023 22:02+1просто невозможно представить эффективную работу без нормального IDE.
Здесь у вас ошибка понимания. Я как пользователь NeoVim плотно работал с рядом IDE, среди которых IntelliJ, Visual Studio, Android Studio, xCode, Eclipce CDT, Code::Blocks, CodeLite, NetBeans, Gnome Builder, QT Designer. И помимо них тыкал ещё и некоторые, в том числе и от JetBrain. На текущем месте работы я использую Visual Studio, Android Studio, xCode под разные платформы для одного проекта. И могу ответственно заявить, что эффективность работы конкретного специалиста зависит не от IDE, которой он пользуется, а от свода правил, которых придерживается этот специалист в проекте, над которым работает. Всё, что подразумевают некоторые пользователи под «эффективностью» в крупных IDE - это лишь видимость. И часто самообман. Несомненно, когда пользователь работает только над одной технологией в одном проекте под одну платформу, то IDE - это эффективный инструмент, который заточен под конкретную задачу, технологию, платформу. А вот если один проект разрабатывается с использованием разных технологий, под разные платформы, когда одного IDE просто функционально не хватает, то вся «эффективность» сразу испаряется. Особенно если необходимо переключаться на разные IDE для разных задач. Если вы не работали так, то вы даже не представляете себе какой это геморрой. И тем, кому приходится работать в таком наборе, что я указал (Visual Studio, Android Studio, xCode), я могу только посочувствовать.
Я могу накинуть огромную портянку типичных проблем большинства IDE, но это на долго и мне просто лень её писать. Но я вас уверяю вы очень сильно ошибаетесь по поводу эффективной работы в IDE
mazdayka
01.12.2023 22:02VSCode принадлежит Microsoft... Ну тогда используйте Codium. Тоже самое но без прибамбасов от Microsoft.
Zitz19
01.12.2023 22:02На мой взгляд всё банально сводится к тому, что наиболее удобный инструмент определяется нуждами проекта и средой, в которой ты работаешь.
Я занимаюсь разработкой компилятора в команде, где почти все используют gvim, для него ручками написали удобные плагины внутри команды, поддержали систему тегов и прочее. Дебаг осуществляется благодаря готовым скриптам и анализом логов с дебаг принтами. В такой ситуации когда подходишь помочь коллеге, работающему в Kate, пытаешься быстро перейти по тегам к определению макроса или функции, а у него данный функционал не работает - раздражает.
Аналогично когда подключаешься по ssh в терминале, удобен vim, а работая над большим проектом с необходимостью отладки я использую clion и подобные. Так что в каждом случае на мой взгляд надо уметь адаптироваться и выбрать подходящий инструмент
olivera507224
01.12.2023 22:02Явное преимущество Vim становится очевидным при подключении по SSH к удаленным серверам. В таких сценариях VS Code не слишком удобен, в то время как для ввода «vim» с клавиатуры и начала редактирования потребуется всего пара секунд.
Никогда не подключался по SSH к удалённому серверу через Вим, но очень часто делаю это из-под VSCode. Не совсем понял, чем способ
Ctl+Shift+P -> подключиться по ssh -> ввести имя пользователя и хост -> ввести кодовую фразу ключаменее удобен чем аналогичный, подозреваю, способ в Вим?AnimeSlave
01.12.2023 22:02Вы подключились по ssh, а дальше? Тут автор имеет ввиду, что в подавляющем большинстве случаев vim уже есть на linux, unix, bsd серверах. То есть подключившись по ssh через терминал можно сразу редактировать нужный файл, не выходя из терминала, не понимая GUI окружение. VSCode здесь уже не подойдёт, особенно если удалённый сервер без рабочего стола
olivera507224
01.12.2023 22:02Вы подключились по ssh, а дальше?
А дальше просто работаю в локальном окне VSCode, редактируя файлы на удалённом сервере и осуществляя отладку там же, если требуется. Никакой рабочий стол на удалённом сервере при этом не нужен. Просто и без усложнений.
NotMusk
01.12.2023 22:02Явное преимущество Vim становится очевидным при подключении по SSH к удаленным серверам. В таких сценариях VS Code не слишком удобен, в то время как для ввода «vim» с клавиатуры и начала редактирования потребуется всего пара секунд.
Вот честно, https://github.com/coder/code-server вам в помощь. После того, как я открыл для себя этот проект, все консольные редакторы для меня канули в лету. Просто делаете шаблон dev-stand с уже установленным кодсервером и разворачиваете под каждый проект сразу стенд, в котором можно сразу в браузере получить vs code.
MiyuHogosha
01.12.2023 22:02Кроме того, VSCode принадлежит Microsoft, но, являясь продуктом с открытым исходным кодом, потенциально уязвим для злоумышленников
??? А vim -закрытый код? И как лицензия кода кого-либо останавливала?
Ashot
Простите
vkni
Увы, автор пропустил отличный шанс скаламбурить «Why did I quit Vim».
belenot
Я наоборот всю статью ожидал шутки про выход из vim, и так горжусь автором за то, что он не вставил эту классику в текст). Хотя мог бы. Но тут все серьезно
saboteur_kiev
Because I can!
Because I've found correct hotkey!
Примерно так?