Comments 178
Почему я перестал использовать Vim...
Потому что я нашёл, как из него выйти!
Простите
tldr: очередной неофит сравнивает редактор с IDE и пользуется ms vs code. Гениальная свежая мысль, к которой пришел автор: используйте vim-mode в IDE
А сколько людей яростно доказывает, что vs code - не IDE, а редактор. И вот те на, достаточно было сравнить его с vim :)
Но, МС Коде же не ИДЕ, а редактор кода. (Мы все понимаем, что какие-то функции пересекаются.)
Я не называл это IDE
Кстати, а почему не IDE? У стоковой VS Code сразу после установки есть навигация по коду, автодополнение, рефакторинг, интеграция с гитом, средства запуска и отладки и т.д. Чего в ней ещё не хватает, чтобы это была IDE?
Если я вам дистрибьютив vim соберу со всем вышеуказанным, вы его тоже будете IDE называть? Мне правда интересно понять вашу логику.
Если я вам дистрибьютив vim соберу со всем вышеуказанным, вы его тоже будете IDE называть?
И будете поставлять это как один цельный продукт и сопровождать сами? Да, естественно. Если вы возьмете современные IDE, там тоже вас встретит не монолитный исполняемый файл со всем функционалом, а пустая, но расширяемая оболочка, и подключаемые к ней плагины/пакеты, которые реализуют весь сопутствующий функционал, будь-то отладка, автодополнение или интеграция с контролем версий. Чем плагины, которые обеспечивают функционал IDE в Visual Studio 2022, отличаются от плагинов, которые обеспечивают функционал IDE в VS Code, если и те, и другие разрабатываются одной и той же конторой, и идут в одном цельном бандле?
Вы получите что-то вроде IDE от ТурбоПаскаля 3.3. А потом они перешли на копирование Голого Деда (GoldEdit)
К слову, в VS Code vim-like плагины один ужаснее другого. То индентация при undo слетает, то еще что. В IDE-шках от IntteliJ значительно лучше с этим делом, но тоже не блеск.
alias vim="code -nw"
'Копирование/вставка - y/p'
выделение текста в Vim:
Отметить начало текста при помощи "v", "V" или CTRL-V.
Переместить курсор в конец визуального фрагмента. При этом текст от начала визуального выделения до конца включительно будет подсвечен.
Ввести команду-оператор. Команда выполняет действия над выделенной областью.
А если подключился на удалёнку, копируешь что-то на локальном компе и нужно вставить удалённый vim?
Изучить Вим и не изучить Емакс это как познать инь и не познать ян. Статья о Вим всегда неполна без упоминания Емакс и наоборот.
Просто те, кто упал в нору Vim, уже оценили глубину норы, а кто полез в Емакс еще в полёте!
Вы же в курсе, что кривая освоения Emacs - Странный аттрактор
Тем более, что он так же хорошо работает без гуя, имеет кучу плагинов и релизов типа spacemacs. Который как раз в nw на серваке отлично работает.
А что может emacs? Ну кроме как картинки показывать?
Почему последнее время на хабре все больше и больше статей про вим?
NeoVim активно форсят стримеры, типа Primeagen, вот их аудитория и поднимает статьи как стать кулхацкером, программирующим в терминале.
Vim это такая штука, которую ты можешь настроить под себя. И на почти на любой вопрос... "А можно ли ... ?" ответ будет да. Минус конечно в том что нужно потратить чуток времени для того что бы сделать его четко под себя (у меня .vimrc ~ 300 строк).
Это как c gdb он основа и для Qt и для Clion но и там и там они его прикрутили под себя. Ты тоже можешь взять gdb подключить нужные плагины и сделать конфетку которая будет работать прямо в vim.
PS тупо использовать vim и иcпользовать такой куцый набор команд как у автора... это как в gdb использовать только next, step.
Явное преимущество Vim становится очевидным при подключении по SSH к удаленным серверам. В таких сценариях VS Code не слишком удобен, в то время как для ввода «vim» с клавиатуры и начала редактирования потребуется всего пара секунд.
?
Не нужно решать потенциальные проблемы с обновлениями, дающими сбой или конфликтующими с расширениями. В таких ситуациях трудоёмкая отладка вам обеспечена.
??
Кроме того, VSCode принадлежит Microsoft, но, являясь продуктом с открытым исходным кодом, потенциально уязвим для злоумышленников.
???
Таким образом риск, связанный с использованием исключительно VS Code, будет неоправданным.
Кто не рискует, тот не пьёт шампанского!
Спасибо за бодрое начало утра нового дня )
А мне mcedit нравится...
В vim нет языковых модулей с подсветкой синтаксиса что ли? Тоже мне причина :) вот глобальный поиск и автозамена по проекту средствами баш ИМХО более серьезная и сложно выполнимая задача. Есть даже аналог gitlens.
вот глобальный поиск и автозамена по проекту средствами баш ИМХО более серьезная и сложно выполнимая задача
А какая разница, каким средствами вы будете делать глобальный поиск и автозамену по проекту?
В ide это нормально работает в рамках добавленной папки, оперируя концепцией папка=проект, а в виме нет понятия проект, ну во всяком случае мне не встречался метод это реализовать. Искать по проекту приходится постоянно, чуть реже делать поиск с заменой и я не знаю как это грамотно через вим реализовать,чтобы это не было сложно.
В виме это можно делать с помощью LSP. Но у меня так и не получилось его нормально настроить, пришлось перейти на emacs, в котором LSP работает нормально.
В Vim это на уровне самой операционной системы реализуется. Есть стандартная папка. Обычно папка пользователя. Vim её ставит основной при старте. Для того, чтобы изменить её нужно выполнить команду cd для которой передать путь до папки, где лежит проект. И тогда всё будет работать так же, как в VS Code. А чтобы это происходило автоматически при загрузке файла нужно настраивать Vim. И каждый пользователя это делает сам. И это уже боль в каком-то смысле из-за гибкости настройки Vim
Разница в эффективности и скорости.
вот глобальный поиск и автозамена по проекту средствами баш ИМХО более серьезная и сложно выполнимая задача
Я это на баше напишу быстрее, чем в ms vs code поиск отработает)
Удачи рефакторить глобальную переменную i на bash %)
Удачи вам с таким проектом, но отрефакторил бы я его так:
rm -rf ./*
а почему i а не counter, например?
Потому что i - 50 лет на рынке переменных!
50 лет на рынке итераторов. На самом деле еще больше.
вроде я и раньше его встречал..
В баш цикл for обычно используется не в С нотации, а в проходе по элементам итератором, а не индексом. Поэтому там i обычно не нужен, а для какого-нибудь счетчика удобнее пользоваться более длинными именами переменных =)
НЯП предлагалось по быстрому написать однострочник на bash для глобального переименования в проекте. Написать то можно, но результат скорее всего не понравится ;)
но результат скорее всего не понравится
И вы можете объяснить, почему?
Для однострочника на bash контекст - 1 строка. Вот оно и переименует в таком вот стиле https://ru.wikipedia.org/wiki/Википедия:Энциклонги
Можно конечно упороться как следует в регулярные выражения.
Кроме того, VSCode принадлежит Microsoft, но, являясь продуктом с открытым исходным кодом, потенциально уязвим для злоумышленников.
повеяло Балмером
По этой же причине и vim уязвим, выходит.
Переводчик немножко испугался переводить полностью
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.
Сейчас отхвачу минусов много, но как Человек, я хочу перемещаться по тексту максимально просто. Vim и подобные ему, такой очевидной возможности не дают. Но если вам важна скорость набора кода, то теперь мне понятно, из-за чего появляется говнокод.
А те, кто использует Vim/Emacs уже не люди?
Интересная аналогия. Может расскажете о нелюдях?
Я вам гарантирую, что я перемещаюсь по тексту максимально просто, используя Емакс
Сочувствую. У меня полноформатная клавиатура с блоком со стрелочками. Удобней ничего не придумали еще.
Сочувствую. У меня полноформатная клавиатура с блоком со стрелочками. Удобней ничего не придумали еще.
А чему тут сочувствовать? Каждый пользуется тем, что ему удобно. Мне не нравятся срелочки, я ими не пользуюсь, вам нравится, вы пользуетесь. В чём проблема?
Каждый раз удивляюсь, что люди пишут несколько сотен комментариев, доказывая друг другу, что vim/emacs - хрень, или наоборот, что vim/emacs - классный инструмент.
придумали-придумали: посмотрите про концепцию работы с клавиатурой "home row". Она не про скорость, она про эргономику движений для кистей рук для их здоровья спустя долгие годы и про помощь при слепой работе с клавиатурой. И vim наработал многое из этой концепции. Его ценность не в самой программе vim, а в эргономичном решении, которое можно включить практически в любой IDE или в других продвинутых редакторах вроде Emacs.
Выучив некоторые плагины и команды Vim, можно перемещаться максимально просто и быстро не только по тексту, но и по файлам в системе. Тут скорее для вас важен интуитивный подход. Vim в этом случае ломает привычную картину. Тоже самое делает тайловый оконный менеджер. У всего есть свои плюсы и минусы. Но считать, что Vim не даёт очевидной возможности не правильно. Vi появился за долго до современных операционных систем. Его концепция проверена годами. Есть люди, которые не хотят менять свои привычки. И только в этом проблема
Vi появился за долго до современных операционных систем. Его концепция проверена годами.
Как вам, нормально на проверенном годами ADM-3A работается в 2023?
Простите за резкость. Но при чём здесь ADM-3A? Решили блеснуть эрудицией? У вас с контекстом проблемы? Vim используется до сих пор, а ADM-3A нет. Значит Vim прошёл проверку временем, а ADM-3A нет. Почему Vim пользуется популярностью до сих пор вы знаете?
Простите за резкость. Но при чём здесь ADM-3A
Ну так и vi тут не причём, честно говоря. Vim популярен не столько за саму концепцию работы с текстом, сколько за то, что к ней прилагается крутой и гибко настраиваемый инструментарий.
Я отвечу так, вы ошибаетесь. Вся гибкость Vim это наросты, которые притаскивали в него из других мест. Когда-то не было DAP. Не было LSP. Не было приближённого поиска (fuzzy search). Много чего не было. Если бы оно было нужно, то это бы давно «изобрели» сами пользователи Vim, и оно бы стало частью Vim. Но этого нет, так как не всем нужны эти вещи. Vim используют не из-за этого, а именно из-за особенности работы с текстом, из-за его другой концепции. Концепции режимов. Опять же, есть другие редакторы со своими особенностями, и даже, в некоторых случаях, лучшими возможностями настройки (оставаясь обычным текстовым редактором), но при этом Vim не исчез, и даже не теряет популярность. Даже появляются его подражатели, типа Kakoune или Helix (есть и другие)
Vim, и тем более 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 символов (а потом "ну так исторически сложилось, значит прошло проверку временем, значит правильно")?
У вас очень странные претензии, будто бы вас пользователь Vim'а покусал и оставил след на всю жизнь.
Этот редактор подходит не всем. У него своя аудитория. У него свой workflow. Если вам он не подходит, то почему он не должен подходит всем? Выглядит, как эгоцентризм. И видно, что вы не пользовались им полноценно.
Я отвечу только на часть тезисов конкретно:
потому что всё равно надо дожидаться загрузки и готовности этого самого LSP.
Не нужно. Плагин, стартует сразу, при старте Vim, а LSP-сервер подгружается в фоне. Редактировать можно сразу. Но если нужны будут возможности LSP, то придётся подождать. И время зависит от конкретного LSP-сервера. Где-то это миллисекунды, где-то десятки секунд.
Сколько проектов в своих стандартах форматирования кода до сих пор требуют ширину 80 символов
Я один из тех, кто приветствует такой подход. И он объясняется банально. Проще читать код, строки которого помещаются сразу на экране. И еще очень удобно такой код распечатывать на бумаге, так как не требует форматирования, и не будет съезжания строк. Опять же, удобнее будет читать. То есть нет тут никакой конкретной привязки к прошлому. Просто для кого-то было удобно тогда, и для кого-то так же удобно сейчас
Если вам он не подходит, то почему он не должен подходит всем?
Я такого не говорил и даже не подразумевал. Более того, мне вообще без разницы, чем пользуетесь вы или кто-либо другой - старый 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.
Я такого не говорил и даже не подразумевал.
Простите за это. Возможно мне показалось
...а именно 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, им виднее как лучше. [Сарказм]
Оно практически всегда не равно 80 символам. Но код я пишу ограничиваясь 80 символами.
Ну а смысл? 80 символов - это размер экрана IBM PC 1981 года. Я вот только что проверил, на маленьком 17" экране, процентов сорок которого занято тулбарами, отображается 120 символов. Печать исходников на принтере? Тоже совсем не актуально. Сейчас совершенно незачем закладываться на этот размер.
Мне лично удобнее читать первый вариант.
Как отдельно взятый сниппет - наверное да, а когда ты листаешь длинный файл исходников, где каждый параметр каждой функции в отдельной строке, такое полотенце кода вообще нифига не эргономичным оказывается.
Про смысл я ответил уже. Про сниппет. Вы очевидно не читали портянки кода, где в одном файле 10-12 тысяч строк и очень много из них длинной свыше 120 символов. Я именно после того как почитал такой код стал пересматривать свою же привычку писать длинные однострочники. Это очень сильно усложняет чтение кода. Намного важнее быть ясным в коде, чем лаконичным
. Вы очевидно не читали портянки кода, где в одном файле 10-12 тысяч строк и очень много из них длинной свыше 120 символов.
Мне кажется, вы просто не сталкивались с реальной разработкой, если такое пишете.
1:1
А теперь по существу. Я не говорю про то, что строка кода должна быть длинее, чем видимое окно редактора, и чем принятый в команде размер строки, хотя бы упомянутые мной 120 символов, это уже почти дефолт. Нет, не должна, но и писать каждый параметр с новой строки - это тоже перегиб в другую сторону. Навигация по такому длинному полотенцу просто замедляется.
Что мешает, например, графическим эмуляторам терминалов иметь ширину по умолчанию в те же 120 символов?
Все в наших руках ;)
Если код влезает в 80 символов (та самая треть ширины экрана), то удобнее смотреть side-by-side diff (код занимает уже две трети), где ещё треть съедается номерами строк, маркерами (+-, coverage, profiler, linter), полосой прокрутки и прочими интерфейсными элементами инструмента для ревью кода.
это почему-то Ctrl+R, хотя везде это Ctrl+H
Я Ctrl+R чаще вижу. Ctrl+H - это что-то майкрософтовское.
Может быть и так. Основной системой что тогда, что сейчас у меня является Windows (хоть и разрабатываем под Linux, но делаем это удалённо, либо "локально" в WSL). Насколько помню, всякие Thunderbird, LibreOffice, Qt Creator, VS Code имеют одинаковые сочетания клавиш и в Win, и на Linux, и это именно Ctrl+H для замены.
... хотя в Qt Creator может и вообще нет отдельного сочетания для замены, там вроде только Ctrl+F ? Эхх, давно уже им не пользовался...
Как бы то ни было, в моём "везде" это всё равно Ctrl+H , так что для меня CLion был непривычно-неприятной белой вороной. Конечно, были и другие причины, почему он мне не понравился (например, тогда, в 2019, он ещё довольно туго работал с Qt).
CLion - дочерний проект знаменитой IDE IDEA (первая в истории IDE с полным анализом кода, рефакторингами и прочими теперь уже привычными фичами). А IDEA основана не на пустом месте, а на таком столпе, как Turbo Pascal, перетекший в Delphi. Непривычные дня вас клавиши - именно оттуда. Для многих программистов, начинавших работу в 90-е, именно они - родные и интуитивно понятные :) Кстати, в IDEA клавиша F5 для копирования класса и F6 для его перемещения - аллюзия к знаменитому Norton Commander.
В наши дни этот софт на родных для него компьютерах разве что в муромском Кибер-музее можно увидеть. А изучение истории вычислительной техники - важное дело для профессионального разработчика.
"Максимально просто" здесь надо читать "используя манипулятор мышь"?
Не просто мышь, а Magic Mouse =)
это та которой нельзя пользоваться на зарядке? эта та у которой самая модерновая и самая неудобная альтернатива колёсику? эта та которая удобно лежит только в руке фрезировщика-неудачника лишившегося всех пальцев? эта которая весит меньше чем один грузик от нормальной мышки?
ооо дааа.. офигенный выбор..
Перемещаться по тексту и по файлам в vim очень, очень просто и удобно. Особенно если речь идёт про объявления и использования констант, классов, типов.
Стоимость просмотра объявления: нажать две клавиши, вернуться обратно: нажать две клавиши. Навигация и изучение кода становится приятным и комфортным.
Правда за это надо заплатить настройкой, обучением и привыканием.
Думаю появление говно кода не зависит от скорости набора и даже от используемого редактора)
Перемещаться по тексту и по файлам в vim очень, очень просто и удобно. Особенно если речь идёт про объявления и использования констант, классов, типов.
Особенно удобно если константа обьявлена где-то за 3 include под 2 ifdef.
Что из этого clangd не понимает?
Где clangd и где vim..
За счет какого механизма они смогут договориться, какой из stdio.h нужно использовать и с какими дефайнами:
/usr/i686-w64-mingw32/include/stdio.h
/usr/lib/avr/include/stdio.h
/usr/i686-linux-gnu/include/stdio.h
етц
?
Конечно, эта задача должна иметь решение. Но в готовой IDE это просто работает, а vim нужно специально дрессировать..
Установить плагин и настроить хоткеи не такая большая проблема. К тому же это делается ровно один раз и потом работает одинаково для всех языков (для нового языка в общем случае достаточно одной команды для подключения соответствующего language server).
какой из stdio.h нужно использовать и с какими дефайнами
Из json, который генерирует CMake с опцией CMAKE_EXPORT_COMPILE_COMMANDS ON. По умолчанию этот файлик будет рекурсивно искаться в текущей директории, но можно поменять шаблон поиска (полезно для out of source билдов).
Если что, вот плагин, о котором я говорю.
Номер строки + shift g ?
У vim есть одно неоспоримое преимущество - он (почти) всегда есть. Я его использую каждый раз, когда надо поправить пару строк в конфиге. Если изменения более масштабные - мне не лень использовать mcedit. Ну а для отладки кода - VSCode альтернатив нету. И локально и удалённо и в контейнере и WSL. Обеспечит похожий, если не сказать одинаковый опыт использования (UX). Я прям фанат VSCode. По поводу безопасности. В репозитории компании версия VSCode отстаёт на несколько месяцев. Не знаю, что они там проверяют, но надеюсь, что оно того стоит - тянуть с выпуском. Поэтому на рабочем компьютере у меня 1.79, а на домашнем - 1.85.0-insider
Воспользуюсь случаем, и спрошу у фаната VS Code.
какой темой вы пользуетесь? (я поставил себе base16 eighties, чтобы чёрный не выжигал глаза. Редактор выглядит лучше, но, например, окошки поиска/замены выглядят странно, что я даже не пойму, что там кнопки, а что нет)
как в VS Code заменить табы на пробелы? (я нашел через Ctrl-P, и потом >, как заменить ведущие табы на пробелы. А я хочу заменить все)
Мне SynthWave '84 нравится
Hidden text
Машина с конечным числом состояний
Бедный конечный автомат, как над тобой только не издеваются :)
использую nano
Линуксоид я ненастоящий, поэтому первым делом ставлю far2l. А потом жму F4 и вперёд))
Проблема Vim для меня заключается именно в кастомизации.
Невозможно закончить ремонт, можно его только прекратить. То же самое и с Vim. Погрузившись в эту чёрную дыру, невозможно из неё выбраться. В результате ты постоянно недоволен конфигом, и постоянно хочешь что-то улучшить. Сама возможность улучшения заставляет тебя этим заниматься. А ведь надо ещё и работать, но мысль о том, что надо поставить вот ещё один маленький плагин, не отпускает и мешает работе.
С готовыми IDE всё просто: ты либо можешь что-то сделать, либо нет. Это странным образом смиряет твой гипертрофированный перфекционизм и жажду улучшения, оставляя тебя наедине с работой и без этих съедающих мозг мыслей о ещё одном маленьком плагине.
Компромиссным решением в этом случае является установка Vim плагина в IDE. Результатом этого является эффективная и спокойная работа.
НЕ ПОНИМАЮ как вы работаете в виме :)
Вот самая типовая задача – 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. Пишите код где хотите, кому где удобно, у меня никаких вопросов или претензий к этому нет, вопросы чисто из интереса.)
У вас хорошие вопросы, но есть ошибка понимания. Для контекста. Вы сравниваете полноценную 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
которые остаются безальтернативным вариантом нативной разработки под iOS и Android
я бы попросил, это apple настолько недоразвитые что вариантов разработки под их ОС просто нет, в случае ведроида таки не обязательно использовать их студию, а для того же vim/neovim есть плагины для работы с android sdk и ndk, да и в qt-creator из коробки есть возможность. и не только писать код (это можно и карандашом на бумажке независимо от ОС, ЯП и платформы), но и собирать, но и запускать эмулятор (к счастью там qemu под капотом так что всё просто работает) и гонять тесты.
я vim пользуюсь только когда по ssh подключаюсь в незнакомые сервера, так что о нем почти ничего не знаю. Прочитав ваш ответ на вопросы выше, задался вопросом - правильно ли я понял, что с помощью LSP серверов(они локально поднимаются или где то хостяться?), или может это плагины так называете, вы дополняете стандартный vim новыми функциями? По сути делаете из текстового редактора ide?
Да, это такие сервера, которые реализуют стандартный протокол для разных языков. Что позволяет любой текстовый редактор, поддерживающий интеграцию с ними, наделить возможностями IDE
По сути делаете из текстового редактора ide?
Да. Но есть нюанс. Не полноценную, но достаточную для меня для работы над моими проектами. В такой IDE вполне можно писать, рефакторить, дебажить, тестировать код на C++ (этот язык лишь пример, так как я являюсь разработчиком на C++ больше степени). Можно и другие языки так же настраивать. И настройки почти не отличаются в большинстве случаев. Только настройки LSP-серверов будут отличаться практически всегда и с ними всегда долгая возня, если настраивать с нуля
может это плагины так называете, вы дополняете стандартный vim новыми функциями?
Всё верно. Обычные скрипты для конфигурации самого Vim'а
(они локально поднимаются или где то хостяться?)
Для простоты локально, но никто не запрещает размещать их в сети. Я по крайней мере ни видел примеров сетевого размещения, но возможность всё-таки есть.
Вот самая типовая задача – Ctrl+R (WebStorm, рефакторинг), написал новое название переменной, и вуаля, всё само отрефакорилось, включая вызовы, импорты, и всё-всё-всё что использует, например, метод экспортируемый из модуля. Ну как это вы сделаете в текстовом редакторе без контекста? Как?
С курсором на символе grn<NewName><Enter>
Работает именно как вы описали. Естественно не из коробки, предварительно был установлен плагин с LSP и хоткеи прописаны в конфиге.
Единственное, что меня печалит в vim - это невозможность нормального скроллинга при работе с длинными строками (несколько экранных строк, включён soft wrapping).
Я хочу, чтобы когда я довёл курсор до самой нижней строчки экрана и нажал "проскроллить вниз", текст поднялся ровно на одну и только одну экранную строчку, причём чтобы курсор встал именно на неё.
Этой фичей обладает абсолютно любой текстовый редактор, даже Notepad, но не vim. В vim такого поведения добиться абсолютно невозможно, и скроллинг текста по-настоящему мучителен: каждый раз приходится искать глазами курсор, который смещается вверх на рандомное количество строчек.
Частично эту проблему решает относительно новая опция smoothscrool (доступна только в Vim 9)
:set warp smoothscrool
Однако и прокрутку придётся делать с помощью Ctrl+E и Ctrl+Y. И курсор там едет вместе с текстом. Не исключено, что это можно решить map'ингом, но мне лень этим заниматься ибо не очень актуально.
Брам писал ещё в прошлом году, что она [эта опция] ещё совсем не perfect. Допилят ли теперь, непонятно.
Ну не знаю. Я программировал на редакторах и IDE о которых большинство здесь присутствующих никогда не слышали в силе своей молодости – например Merlin.
Мне VIM категорически не нравится, потому что он разделяет навигацию по тексту от редактирования того же текста. А для меня эти процессы всегда были часть единого целого.
И от IDE я хочу именно чтобы чтение, навигация/поиск и редактирование/написание были объединены, а не разделены в разных режимах. Это является непростой задачей, потому что эти действия на самом деле очень разные. VIM пошли по легкому пути – если разные, давайте разделим. Но ошиблись, потому что цель редактора на самом деле это предоставить максимально единую среду редактирования. Потому что мы обдумываем, читаем и пишем текст одним мозгом и редактор должен предоставить максимально прозрачный интерфейс между нашими мыслями и редактируемым текстом.
Не хочу переубеждать, но не могу не поправить.
Командный режим в Vim служит и для навигации, и для редактирования. Отдельные режимы есть для вставки (как промежуточный этап некоторых команд редактирования) и выделения (в нём команды редактирования ведут себя немного иначе, применяясь к выделению и завершая его, навигация же продолжает работать как в командном режиме).
Vim не таит в себе никакого волшебства. Он ориентирован на программистов.
Неа. Он ориентирован на продвинутых пользователей консоли.
Когда создавался Vi/Vim это был программист/сисадмин/QA в одном.
P.S. Иногда создается впечатление, что программисты вообще не подозревают, что кроме них в IT еще полно самостоятельных полноценных направлений.
Неа. Он ориентирован на продвинутых пользователей консоли.
Он ориентирован на любителей vim. Вы можете быть богом консоли, но предпочитать традиционные редакторы.
Мое замечание относилось к ориентации на программистов, хотя vim явно на них не ориентирован изначально.
хотя vim явно на них не ориентирован изначально.
Ну а кто ещё, кроме некоторых программистов/девопсов/админов, будет что-то писать в настолько не WYSIWYG-редакторе? Я уже писал свой тезис, хоть не бесспорный, но тем не менее, я его считаю верным. Популярность vim не в продуктивности такого подхода к набору текста, а в том, что к ней приделали хороший набор инструментов. Я более того скажу, парадигма vi/vim, она ни разу не уникальная, все редакторы 1970-х были похожими, и даже в MS DOS встроенный редактор был подобным. Они просто все вымерли в процессе эволюции, когда по-моему, в 1979-м вышел WordStar, который был не таким, а предлагал привычную всем нам парадигму редактирования текста. Тогда это было офигенной инновацией.
а предлагал привычную всем нам парадигму редактирования текста.
Давайте не обобщать =) Мне вполне привычнен не WYSIWYG редактор. Точнее plain text для меня роднее, чем rich format, если говорить про код и конфиги.
И я отлично помню и golded и "слово и дело" и vc другие редакторы.
И как бы vi/vim совсем даже не похож на них.
очнее plain text для меня роднее, чем rich format, если говорить про код и конфиги.
Я же не про это :)
я отлично помню и golded и "слово и дело" и vc другие редакторы.
И не про это, это всё WYSIWYG-редакторы, вы там тоже получаете на принтере то, что видите на экране. Просто в какой-то период времени подросшие "стандарты качества" стали требовать для этого ещё и белый лист на экране рисовать, да с разбивкой на страницы, но то уже было потом.
Я про редакторы, у которых есть режим ввода текста, и есть командный режим. Простейший пример, упомянутый мной, но не названный выше edlin из MS DOS.
\S Вот недолюди-то!
А на самом деле смешно смотреть на бурную реакцию людей, когда дело касается вкусовщины. Обсуждение vim vs emacs vs IDE vs etc. - чистой воды вкусовщина, я бы ещё понял, если бы такая бурная реакция была бы связана с техническим вопросом, а тут просто люди редакторы текста обсуждают :) В прошлый раз статья аж 400 комментариев под собой собрала, в которых люди друг другу доказывали, что использовать emacs/vim - плохо, или наоборот хорошо.
UPD: я и под виндой пару раз вим использовал, на маке так постоянно использую.
Я наверное из тех кому важен результат.
У меня сложилось впечатление, что Vim это про путь. Точить/создавать свой клинок, до какого-то своего идеала.
Для меня выход из VisualStudio с R# уже "стресс". Хотя тоже тот ещё инструмент. VisualCode, насколько понял, лучше в поддержке различных технологий, скорости установки, множеством плагинов, комьюнити. Но по мне сильно отстаёт от того же VS + R# в работе (с теми технологиями под которые они заточены).
Итого (на вскидку):
Минимальный вход.
Установил и работаешь с минимумом настроек.
Инструмент не должен отвлекать.
Инструмент должен брать на себя как можно больше работы.
vim-ом пользуюсь лет 25 уже и менять ни на что не собираюсь. Автор явно неправ, называя его редактором для программистов. Я бы сказал, в первую очередь он редактор для сисадминов.
А может, принять обе таблетки?
Ну вот спасибо, теперь не отпускает мысль о том, что было бы с Нео... Какой эффект это бы возымело в контексте самого фильма? :)
В неовиме все lsp есть и легко подключать любые утилиты. Наверное и в vscode это есть, просто он точно будет медленнее переваривать например поиск по тысячам файлов с grep.
Вероятно для hello world проектов с двумя тремя файлами текстового редактора достаточно, но если у вас сложный проект с зависимостями, библиотеками, системами сборки вроде Maven и Gradle, сложными фреймворками и т.д., просто невозможно представить эффективную работу без нормального IDE.
Vim был хорош в своё время, но как можно спорить, что сейчас, когда выбор IDE так велик, можно обойтись текстовым редактором для сложного проекта?
Я не знаю, какая у Вас платформа (язык программирования, система сборки, фреймворки), но для своей (Java/Kotlin, Maven/Gradle, Spring Boot) могу накидать с десяток функций, которые в текстовом редакторе просто невозможно сделать эффективно. Вы, конечно можете научиться быстро набирать типовые скрипты, но это всё равно не будет быстрее, чем стандартная готовая функция внутри IDE, которая делает тоже самое сразу без набора скрипта одной комбинацией клавиш (или мышью).
Переименование класса / метода с заменой по всему проекту
Вынесение части кода в отдельный метод
Добавление параметра в метод с постановкой значения по умолчанию по всему проекту
Поменять параметры метода местами
"Провалиться" в реализацию метода из места, где этот метод используется через интерфейс
Подсветить ошибки в коде без запуска компилятора
Подключить к проекту систему сборки и иметь возможность использовать публичные библиотеки
Поиск класса среди всех подключённых библиотек по названию
Предложить варианты определения значения переменной по типу
Предложить класс / функцию по двум трём буквам названия (не обязательно идущих подряд)
Посмотреть всю иерархию класса
Запустить тесты (все тесты в проекте, все тесты в конкретном классе, один конкретный тест)
Дебаг: узнать значение переменной в нужном месте, выполнить вычисления в нужном месте
Spring: автоматически предложить возможные настройки в конфигурации, перейти из файла конфигурации в проперти класс, перейти к определению бина из места его использования
Вот, с ходу столько уже придумал. Всё это делается одной комбинацией клавиш или парой щелчков мышью. А как это делаете Вы?
Вы случайно не это используете?
https://github.com/emacs-lsp/lsp-java
Там прямо таки написано: "Emacs Java IDE". То есть у вас таки IDE, хоть и сильно обрезанная.
Ну ок, цитата из второй вашей ссылки:
"Client for Language Server Protocol (v3.14). lsp-mode aims to provide IDE-like experience"
То есть у вас таки IDE, а не голый консольный текстовый редактор.
Так статья о чём? Автор говорит о консольном текстовом редакторе. Я отметил в изначальном комментарии, что использовать такое в современной работе невозможно, нужно использовать IDE. Вы сами используете IDE, а не то, что описывается в статье. Не понимаю, с чем Вы конкретно не согласны.
Emacs, разумеется, не является IDE. Но Вы работаете не в голом Emacs, а в полноценной среде (Emacs + плагины). Вы удивитесь, но эта среда и есть IDE, на что намекают приведённые выше цитаты.
То, что определённые плагины загружаются на определённые файлы, является особенностью любой другой IDE.
Так что не понимаю, в чём предмет спора тут. Вы набираете руками команды в консоли или используете то, что предоставляет Ваша не-IDE?
просто невозможно представить эффективную работу без нормального 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
Думаю Вы согласны, что у Вас особый случай, что Вам приходится работать сразу в нескольких платформах одновременно. Вероятно, Вам действительно проще иметь текстовые редактор для всех платформ.
Для остальных, кто специализируется на одной, мой вывод остаётся верен.
Кроме того, позвольте уточнить, Вы под эти все платформы именно ведёте полноценную разработку или просто собираете/вкладываете?
Что касается портянки проблем. Опишите хотя бы парочку, интересно посмотреть, актуальны ли эти проблемы в моём случае.
У меня не особый случай. Это норма там, где разрабатывается «мультиплатформа» с использованием нативных (присущих только конкретной платформе технологий). Выглядит, как особый случай, но это не так. Это реалии такого подхода. С этим приходится мириться.
Вы под эти все платформы именно ведёте полноценную разработку или просто собираете/вкладываете?
И так, и так. Объясню подробнее. На текущем месте работы код у нас разделён на «ядро» и «модули». Ядро - полностью написано на C++ и не имеет никаких дополнительных вставок на других языках, модули - отдельные блоки кода написанные на других языках, относящиеся к конкретной технологии конкретной платформы, возможности которой используются, чтобы грузить код ядра. Для android код написан на java/kotlin, ios - objective-C, UWP - C# в перемешку с C++/CLI (это извращенский диалект C++ от Microsoft). И чаще всего изменения ядра не ведут к изменениям кода модуля. Поэтому разработка ядра может выполняться в любой IDE для языка C++. Для удобства многие коллеги используют Visual Studio. У меня такого принципиального выбора нет. Я могу и на xCode писать, если в текущий момент нахожусь за Mac. Но как только изменения ядра должны быть сопряжены с кодом модулей, то тут уже начинаются танцы. Потому что нужно использовать все IDE, каждую отдельную для определённой платформы для разработки конкретного кода. Для каждой IDE свои настройки проектов. Каждая IDE по своему кеширует код для «удобства» работы с ним. На каждой платформе нужно проверить код, а это в любом случае первично локальная сборка. На каждой IDE сборка с нуля. В этом случае IDE не создают удобства. Из-за монополизации конфигураций проектов, наоборот создаются трудности.
Опишите хотя бы парочку, интересно посмотреть, актуальны ли эти проблемы в моём случае.
Автосохранение ломает файл — В тех IDE, где есть автосохранение, файл может быть повреждён самой IDE на ровном месте. При этом сама IDE пользователю может показывать «правильный» файл, так как отображаемый в IDE файл — это копия из кеша, а не оригинал.
Кеш главнее оригинала — Сделанные изменения могут быть сохранены, но пока они не буду скешированы и проиндексированы встроенная в IDE система сборки будет собирать билды со старыми версиями файлов, а не с новыми. И если кеш «поломается», то сборка может вообще не запускаться, при том, что с оригинальными файлами может быть всё хорошо.
Управление зависимостями неподконтрольно пользователю — Рандомные ошибки возникающие при получении новых версий зависимостей, или когда необходимо откатиться на старые версии. Если зависимости тоже кешируются, то «веселье» удваивается.
Ошибки интеллектуального помощника — Рандомное отключение подсветки синтаксиса. Неправильное отображение производных классов для базового. Неправильное отображение списка вызовов методов для иерархии базового класса.
И это только малая часть того, что бывает. И если для бесплатного vim с плагинами, написанными энтузиастами, такое поведение можно ожидать (оно бывает, но заметно реже, чем в тех IDE, которых я работал). То для крупных платных проприетарных IDE это странно. И все описанные выше проблемы связаны с кешем. Без кеша современные крупные IDE не могут. Так как без него они будут нехило тормозить и виснуть при работе с кодом. Это уже проходили в начале нулевых. Потому использование кеша стало основным. И для некоторых IDE кеш важнее реального кода. Из-за чего появляются совершенно нелогичные ошибки, когда изменения сделаны, но в итоговый результат сборки они не попадают
Тут выяснилась интересная подробность.
В соседней ветке товарищ, который защищает Vim, сам работает в IDE.
Поэтому хотелось бы заранее понять, о чём мы говорим с Вами.
Вот тут есть такая статья про NeoVim
https://habr.com/ru/companies/avito/articles/682962/
Цитаты из этой статьи
В готовых конфигурациях уже есть всё необходимое, чтобы пользоваться NeoVim как обычной IDE.
Плагины: превращаем редактор кода в полноценную IDE
Так вот что у Вас: консольный редактор, как описано в комментируемой статье, или всё-таки полноценная IDE?
А как вы поняли из статьи, что автор не использовал плагины, дающие функциональность IDE? Для меня использование Vim как основного инструмента для разработки по умолчанию подразумевает наличие некоторого набора плагинов (каких конкретно зависит от предпочтений).
Хотя, конечно, бывает всякое, но я в статье не вижу ни подтверждений, ни опровержений использования плагинов.
Конфигурация для (Neo)Vim это скриптовой файл, который выполняется каждый запуск (Neo)Vim. Скриптовой язык для (Neo)Vim это VimScript или Lua. Всё что подразумевается под плагинами - это внешние скриптовые файлы, которые подключаются в основной скрипт. Есть готовые конфигурации для (Neo)Vim, сделанные энтузиастами, представляющие собой наборы скриптовых файлов, которые внешне могут выглядеть, как типичная IDE.
Особенность (Neo)Vim в том, что можно подгружать сторонний код скриптов не сразу при старте, а только тогда, когда вызывается какое-то событие. Это приводит к тому, что загрузка всех специфичных для типичной IDE функций происходит только тогда, когда запускает определенный файл. И потому, если загрузить обычный текстовой файл, то никаких дополнительных скриптов загружено не будет, а (Neo)Vim будет выглядеть, как обычный консольный текстовой редактор.
Про цитаты:
Да
Да, частично. Для полноценной IDE нехватает профайлера, и некоторых других специфичных функций, но и без них жить можно
То, что Вы описали, справедливо для любой другой IDE: в зависимости от типа файла работают те или иные плагины. Отличие лишь в наборе плагинов и возможно в порядке их загрузки. А принципиально в чём отличие?
Или Вы утверждаете, что то, в чём Вы работаете, это обычный консольный текстовый редактор, как описано в статье? Вы все команды в командной строке набираете или используете готовые short-cut-ы из того, что Вы не хотите называть IDE?
Чем вас не устраивает Nano ?
VSCode принадлежит Microsoft... Ну тогда используйте Codium. Тоже самое но без прибамбасов от Microsoft.
На мой взгляд всё банально сводится к тому, что наиболее удобный инструмент определяется нуждами проекта и средой, в которой ты работаешь.
Я занимаюсь разработкой компилятора в команде, где почти все используют gvim, для него ручками написали удобные плагины внутри команды, поддержали систему тегов и прочее. Дебаг осуществляется благодаря готовым скриптам и анализом логов с дебаг принтами. В такой ситуации когда подходишь помочь коллеге, работающему в Kate, пытаешься быстро перейти по тегам к определению макроса или функции, а у него данный функционал не работает - раздражает.
Аналогично когда подключаешься по ssh в терминале, удобен vim, а работая над большим проектом с необходимостью отладки я использую clion и подобные. Так что в каждом случае на мой взгляд надо уметь адаптироваться и выбрать подходящий инструмент
Явное преимущество Vim становится очевидным при подключении по SSH к удаленным серверам. В таких сценариях VS Code не слишком удобен, в то время как для ввода «vim» с клавиатуры и начала редактирования потребуется всего пара секунд.
Никогда не подключался по SSH к удалённому серверу через Вим, но очень часто делаю это из-под VSCode. Не совсем понял, чем способ Ctl+Shift+P -> подключиться по ssh -> ввести имя пользователя и хост -> ввести кодовую фразу ключа менее удобен чем аналогичный, подозреваю, способ в Вим?
Вы подключились по ssh, а дальше? Тут автор имеет ввиду, что в подавляющем большинстве случаев vim уже есть на linux, unix, bsd серверах. То есть подключившись по ssh через терминал можно сразу редактировать нужный файл, не выходя из терминала, не понимая GUI окружение. VSCode здесь уже не подойдёт, особенно если удалённый сервер без рабочего стола
Вы подключились по ssh, а дальше?
sshfs, или его эмуляция.
Вы подключились по ssh, а дальше?
А дальше просто работаю в локальном окне VSCode, редактируя файлы на удалённом сервере и осуществляя отладку там же, если требуется. Никакой рабочий стол на удалённом сервере при этом не нужен. Просто и без усложнений.
Явное преимущество Vim становится очевидным при подключении по SSH к удаленным серверам. В таких сценариях VS Code не слишком удобен, в то время как для ввода «vim» с клавиатуры и начала редактирования потребуется всего пара секунд.
Вот честно, https://github.com/coder/code-server вам в помощь. После того, как я открыл для себя этот проект, все консольные редакторы для меня канули в лету. Просто делаете шаблон dev-stand с уже установленным кодсервером и разворачиваете под каждый проект сразу стенд, в котором можно сразу в браузере получить vs code.
Кроме того, VSCode принадлежит Microsoft, но, являясь продуктом с открытым исходным кодом, потенциально уязвим для злоумышленников
??? А vim -закрытый код? И как лицензия кода кого-либо останавливала?
Почему я перестал использовать Vim