Комментарии 245
Бесплатная версия Idea вроде поддерживает Rust. Может быть, не очень хорошо, но поддержка точно есть. В idea может не быть плюшек типа отладки, в отличие от clion, но в целом подсветка синтаксиса и запуск .cargo проекта работают.
И в чем альтернативы превосходят оный?
Это видимо как с вегетарианством и веганством.
Пожалейте сову, ей больно на этом глобусе.
Все таки смена руководства и адаптация под современные реалии это не хухры мухры.
Ну давайте, расскажите про связь. Микрософт переманит всех на VS Code а потом его закроет? Серьёзно? :)))
Внимание вопрос(озираясь по сторонам) Кому??
кто принимает пулл реквесты в опенсорсные проекты Майкрософт?А вы какой ответ ожидаете на этот вопрос? Гитхабом умеете пользоваться? Вся история там. Или вам ФИО и паспортные данные нужны?
Будут ли приняты пулл реквесты противоречащие политике и стратегии компании? Будут ли пользователи ресурса Github, принадлежащего Майкрософт, ограничены в возражениях по поводу отклонения пулл реквестов?Контакты найдёте самостоятельно? Вот уж чего, а мест для дискуссий там достаточно. Там и объясните, что имеете в виду под «политикой и стратегией»
Extinguish сменилось на GatekeepingЗа 13 часов с момента ответа сменилось? :)
А где-то есть форумы или паблики, где вот такими теориями обмазываются, длинные списски ссылок на душещипательные статьи, (которые никто не читает) составляют?
По поводу вашего комментария. Логически возможно два варианта:
1. VSCode нас устраивает, мы им пользуемся. Нет проблем.
2. VSCode нас не устраивает. Например, не принимаются пулл реквесты, противоречащие политике компании (как вы пишете). В этом случае независимые разработчики создают и развивают своё ответвление. Пользователь может выбирать, чем ему пользоваться. Зачем вам «критическая масса пользователей»? Чем хотите, тем и пользуйтесь.
Про «полировку продукта». Исходный код VSCode частично открыт, значит у разработчиков ответвления всегда есть доступ к «отполированной» версии от MS.
VS Code не изолированный продукт. К примеру, он использует для синтактического анализа LSP (language server protocol), созданный Microsoft как раз для VS Code. Затем LSP стал открытым стандартом, продолжая оставаться под контролем MS, и вот тут уже MS во всей красе показала свою типичную тактику по отношению к открытым стандартам. LSP допускает широкую трактовку во многих местах, так что де-факто стандартом становится референсное поведение vscode, также "неудобные" жалобы на критические недостатки протокола порой просто-напросто игнорируются. В итоге у MS под контролем один из лидеров рынка программируемых редакторов, задающий стандарты, а бессмысленность форкания LSP или VS Code думаю объяснять не стоит.
Было дело, тоже по этой причине раньше не пользовался. Но теперь уже нормально выглядят, кстати.
Так их же можно поменять
Я даже было дело создавал issue, но видимо эта проблема волновала слишком малое кол-во людей, и поэтому проще забить.
А можете развернуть логическую цепочку между профайлингом и ограничением возможности индивидуума?
Ну, запуская браузер, все (ну или почти все) знают, что их там можно отследить и запрофилировать. Для кого-то это важно, для кого-то не очень. Кто-то понял насколько это важно, только после поездки в Израиль.
Но, плохо то, что уже и когда вроде только на своей машине работаешь, никуда в инет не лезешь, тебя все равно следят и профилируют. И это куда страшнее потому что намного незаметнее.
Как они решили, я не знаю, но где-то дополнительную инфу они нарылиТак а откуда тогда утверждение про инстаграм, если на самом деле не знаете?
Моё дело — предупредить.Меня? Спасибо :)
Не знаю, что такое BDS, но смешно звучит. То есть, человек весь такой из себя активист, постоянно топит за что-то (или против) в постах и комментариях. А на границе, значит, такой весь белый и пушистый. И уверен, что никто о нём ничего не знает. В 2020 году.
У знакомого было два отказа в визе когда он хотел поехать на конференцию. (Видимо решили, что хочет сбежать от семьи и детей). На третий раз дали.
По моим личным наблюдениям — еще важен возраст, молодежи в районе 18-20 дают визы хорошо даже в чистый паспорт.
Это много где учитывается. Как кредитная история.
del
Скриншот от Che выглядит подозрительно похоже на обычный VS Code. Это тема такая или скриншоты перепутаны? Гугл выдаёт немного другой внешний вид, больше похожий на классический Eclipse:
Тот что в статье, возможно, от веб-версии VS Code
Upd. Точно, скриншот взят от Theia, которая в статье вообще не указана
https://theia-ide.org/
Не обратил внимание, что это перевод.
Для полноты картины: в комментариях к оригиналу автор поясняет, почему он рассказал именно про Che:
Theia is a platform for building an IDE.
Che, which is included in this article, is an IDE.
Both are Eclipse projects, but I felt Che was better suited as an alternative, because it's an IDE ready for use.
Theia — платформа для создания IDE
Che, включённый в статью, — сама IDE
Оба являются проектами Eclipse, и мне показалось, что Che больше подходит на роль альтернативы, потому что это уже готовая к использованию IDE
А просто отключить телеметрию в настрйках почему не вариант, раз вокруг неё вся статья держится?
Слишком просто. О чем тогда статью писать?
Потому что телеметрия в следующем апдейте может и включится. Не было такое, что ли? И еще, чтобы выключить телеметрию, придется запустить продукт и он сразу позвонит домой. То есть, телеметрия хоть раз, да сработает. Понятно, что и это можно обойти. Но все эти танцы характерные для концепции opt-out бесят очень сильно. Вот, пусть начнут работать через opt-in, тогда и задумаюсь насчет включать-не включать телеметрию.
Кстати, у меня тоже проект IDE с свободным кодом. И иногда очень хочется узнать кто, где и как использует мой продукт. Но нельзя-я-я. Вот и не делаю.
Господа, откройте ваши любимые телефончики, пройдитесь по приложениям и посмотрите, какие галочки там установлены по умолчанию, причем без всякого на то предупреждения.
«Вы ничего не понимаете это совсем другое» (с)
А гугл и эппл — корпорации добра, не то, что M$. Излучают только опенсорс и радугу.
Раз меня цитируете, то мой любимый телефончик — Nokia C2; Галочки проверил. Вроде правильно все.
И вообще, я не одобряю opt-out, считая его обманом. Всегда пытаюсь не использовать услуги и продукты которые пользуются такими трюками. Иногда не могу. Потому что я тоже человек и мне тоже могут обмануть. А opt-out очень часто операция тайная. Формально, где-то там в глубине настройках, на вкладке "форматирование диска" может и есть галочка "отказаться". Но несмотря на это, я считаю такие методы обманными.
Использую msvs и sublime. Под линуксом вместо msvs — qt creator.
Так vscode вполне умеет с установленным Microsoft C/C++ Extension.
Честно говоря, отладка в VS Code, особенно Qt-приложений, не всегда удобна, по крайней мере так было года полтора назад. То, что тот же Qt Creator отображает в Locals/Watch в удобном виде (типа различных коллекций), в VS Code предстаёт в чистом и незамутнённом, со всеми голыми указателями на служебные объекты и прочие QObject. И это всё не считая того, что Step Into/Over дико тормозили.
В качестве основного редактора использовал VS Code, но для отладки использовал исключительно Qt Creator, экономил кучу нервов. Возможно, за полтора года что-то изменилось и на данный момент отлаживаться стало удобнее.
Посредством плагинов все, очевидно.
До обращения по имени оно конечно не скатится, но что плохого в таргетированной рекламе?
не приватной, но достаточной для идентификации… слепок настроек любого браузера, насколько мне известно, уникален, как отпечаток пальца…
да и если вы используете что-то от Google, chrome или андроид, то это уже пока приватность, сбор данных идёт во всех их продуктах… и по отдельности эти данные не особо приватные, но собрав их в кучу и зная, что они принадлежат одному человеку, об этом человеке можно узнать больше, чем он сам знает.
плюс, уже сейчас некоторые банки прям в банк-клиенте для покупок в продовольственных магазинах научились отображать содержимое чека, а значит эта информация тоже передаётся… и по ней тоже можно многое вычислить, соединив с историями поездок на такси, с оплатами проезда в транспорте, списком wifi сетей, замеченных вашим смартфоном и так далее… бояться надо не утекающей информации, ибо она утекала всегда… а развития технологий, позволяющих эту информацию обрабатывать и превращать в близкие к фактам сведения. если лет 20 назад это стоило больших усилий хороших детективов, и случалось только при крайней необходимости, то сейчас это происходит чуть ли не автоматически, просто потому что есть такие возможности..
это какой-то фарс, ей-богу
Это не фарс. Это способ проявить сопричастность at no cost. Аналогично выставлению лайков «для поддержки жертв землетрясения». Вроде бы что-то «полезное» сделал, но вместе с тем не испытал для себя особых неудобств. От конкретной IDE отказаться — невелика потеря, особенно если вы и так уже привыкли к чему-то другому. Ну и что, что VS Code может быть в чем-то удобнее, разница по сути пустяковая.
А вот поддерживать цифровую гигиену, способную перевесить цифровую защиту «неуловимого Джо» (которой мы все забесплатно и по умолчанию пользуемся) — без тотального отказа от благ и возможностей современного мира весьма сложно и неудобно, поэтому разумеется этого никто не будет делать. И даже размышлять всерьез об этом не будет, потому что ну зачем рушить удобную картину мира самому себе?
Другое дело, что не все эту информацию собирают, а даже если собирают — то не все раскладывают её надлежащим образом. Но это вопросы не возможности, а технической реализации.
Чтобы эту возможность не допускать — вам уже по умолчанию нужно будет проделать массу действий по «анонимизации» вашего браузера и вас.
Часть команды работает на VS Code, часть на QtCreator. Стэк не очень распространённый: C — под микроконтроллеры, С++ — под QNX и Windows и Python. В QtCreator до недавнего времени не очень ладилось с Python. Поэтому стали смотреть в сторону. CLion несколько разочаровал. Хоть и не заявлена поддержка qcc, но обламаться потому что в IDE наглухо вшиты ключи компиляции под gcc, которые не поддерживаются в qcc было обидно. Неужели нельзя было это в конфигурацию вынести?
Скорее всего его нет в альтернативном репозитории расширений. Можно либо собрать из исходников и установить файлом, либо прописать репозиторий от Microsoft: https://github.com/VSCodium/vscodium/blob/master/DOCS.md#extensions-marketplace
Это когда курсор можно в любое место экрана поставить и писать с этого места. Как в редакторе Far’а, например, или в (была такая IDE от Borland) C++ Builder’е. Обычно же после конца строки «мир заканчивается» и, например, курсор скачет по горизонтали, когда его стрелками по строкам гоняешь и он перескакивает с более длинной строки на более короткую. Некоторые находят это неудобным.
Ну терминологию напридумывали… "virtual space"!!! А я всегда считал, что все редакторы должны так работать, а там где не так — это из за каких то ограничениях. Ну не сумели правильно сделать потому что гонялись за меньшим размером или производительностью. Или язык/фреймворк не позволяет или руки растут не от туда… :D
Перешел на него недавно. После (neo)vim и emacs многого не хватает: нормальных сплитов — безо всяких там editor groups, табов как в vim или в eyebrowse в emacs, быстрого простого переключения между проектами и, конечно, magit. Ну и падает VS Code регулярно, почему-то.
Объективные причины есть: скорость, размер потребляемой памяти, расширяемость (плагинов для vim на одном только гитхабе сколько). Насчёт дробления окна я не знаю, но насколько помню в VS Code этого нет. Да и по сравнению скорости запуска и плавности работы VS Code сильно уступает vim.
Дробление окна == split screen? Всё есть.
Честно пробовал использовать обвешанный плагинами neovim для разработки на стеке Python/C++ и таки не поверите, под нагрузкой он тоже начинает тормозить.
VS Code представляет собой оптимальный компромисс между визуальными плюшками типа тем, боковых панелек и прочих автодополнений, и возможностью делать всё через консоль/команды. Да, в целом тормознее чем vim, но в отличие от vim, гораздо удобнее для кастомизации. Всё под рукой, не надо по полчаса вспоминать хоткеи/команды или искать их по конфигам. Если какой-то плагин не нужен в данном воркспейсе — отключаешь его для данного воркспейса. Красота.
Я давно уже не использовал VSCode, поэтому не буду оспаривать ваши слова.
Вообще vim крайне удобен, ибо простые действия позволяет сделать в пару кликов например:
- dd — удаление текущей строки
- d$ — очистка текущей строки
- Ngg — переход в строку N
- % — переход к парной скобке
- fC — перейти к символу C
Вы скажите: "Долго и много запоминать" — но по опыту перехода с Sublime Text на vim я вам скажу, что уже через пару недель, эти пара хоткеев будут как дважды два.
Так же в vim для навигации используется раскладка hjkl, к которой по началу так же тяжело привыкнуть, но когда вы привыкнете, проблем возникать не будет.
Да, в целом тормознее чем vim, но в отличие от vim, гораздо удобнее для кастомизации. Всё под рукой, не надо по полчаса вспоминать хоткеи/команды или искать их по конфигам.
Но расширения для VSCode пишутся на TypeScript, следовательно для написания расширения необходимо его знать. Для создания плагина в vim нужно знать VimScript. Ситуация с расширяемостью одинакова.
Если какой-то плагин не нужен в данном воркспейсе — отключаешь его для данного воркспейса. Красота.
Разве в vim так нельзя?
простые действия позволяет сделать в пару кликов
А посложнее?) Как из него выйти?
Вот например, моё любимое: копировать в / вставить из системного буфера
VS Code: Ctrl+C / Ctrl+V
vim: "*y / "*p — если не пользоваться этими сочетаниями постоянно, вылетает из головы на раз. Да, можно ремапить, но при использовании через SSH на чужой машине оригинальную комбинацию можно и не вспомнить. К слову, VS Code через SSH тоже умеет работать, хотя сценарии использования у них совершенно разные.
Как найти команду, которая ты даже не знаешь как называется и есть ли она вообще
VS Code: F1 > вбиваешь что-то примерное > автодополнение подскажет
vim: гугл + Stack Overflow + RTFM
Как найти настройку, которую ты даже не знаешь как называется и есть ли она вообще:
VS Code: settings.json > вбиваешь что-то примерное > автодополнение подскажет
vim: гугл + Stack Overflow + RTFM
Установка плагинов
VS Code: Зашёл на панельку с плагинами, вбил в поиск, выбрал подходящий или с наибольшим количеством скачиваний, установил.
vim: Нууу, сначала надо поставить менеджер плагинов. Допустим, выбрали Vundle. Сначала нам понадобится вставить set rtp+=~/.vim/bundle/Vundle.vim \n call vundle#begin() ... call vundle#end() в .vimrc, а как вставить из буфера в vim мы уже забыли. Дальше поиск по интернетам; плагинов к vim слишком много и не сразу очевидно, какой из них живее. Допустим нашли, RTFM, убедились что это вроде бы то что нужно. Выкачали в .vim/bundle, конечно же вручную, вписали в .vimrc Plugin 'best/plugin, перезапустили vim, обнаружили, что мы где-то опечатались, из-за этого сломался .vimrc и если не повезёт, не работает половина сконфигурированного функционала...
Отключение плагина для текущего проекта
VS Code: вкладка с плагинами > правой кнопкой мышки > Disable in workspace
vim: лезть в .vimrc и добавлять строчку, исключающую плагин для соответствующей директории
https://stackoverflow.com/questions/601412/how-to-turn-off-a-plugin-in-vim-temporarily
А как потом посмотреть какие из плагинов включены:
VS Code: на вкладке плагинов они "серенькие".
vim: а вот ищи или думай, это у тебя плагин сломался, или ты сам его отключил, или он и не должен был запускаться для текущего файла.
Допустим, я поставил себе новый плагин и ещё в нём не разобрался
VS Code: пойду на панельку плагинов, найду нужный, на вкладке Feature Contribution единообразно прописано всё, что плагин делает
vim: гугл + Stack Overflow + RTFM, или копайся в исходниках
Если подходящего плагина нет
Ситуация с расширяемостью одинакова.
Вот только поддержка Typescript в современном мире гораздо лучше, чем у Vimscript. То же автодополнение из коробки, которое даёт лёгкую и удобную навигацию по API. Хотя действительно, это не просто скриптик запилить, сначала надо будет поставить Node.js + npm, освоить базовые команды для них, yeoman для создания плагина из темплейта и фирменная утилита vsce для упаковки плагина в пакет и размещения в каталоге
Ещё по мелочи достоинства VS Code: вместо единого ~/.vimrc три уровня конфигурационных файлов (пользовательские настройки/workspace (что-то типа солюшена у MSBuild)/workspace folder), отдельные файлы с хоткеями, с глобальными тасками, с локальными тасками, с конфигурациями запуска/отладки. Отдельные панельки с отладочным выводом для каждого плагина. Возможность настройки одних и тех же хоткеев на разные команды в зависимости от контекста (доступен ли ввод с клавиатуры или файл открыт readonly, открыт ли виджет поиска или diff editor...). Ну и чрезвычайно удобный встроенный плагин для работы с git, из-за которого я и подсел на VS Code уже почти три года назад.
Ну на самом деле всё круто и гибко и один раз настраивается. // trollface
Перефразируя анекдот про питон, vim такой гибкий, что выскальзывает из рук!
Я сам подсел на vim, когда надо было работать со встраиваемым ПО, и продолжаю его использовать для редактирования мелких конфигов и отдельных файлов, которые лежат фиг пойми где и до которых удобнее добраться через консоль. Настроил себе когда-то ряд плагинов и комбинаций клавиш, теперь везде за собой таскаю и боюсь что-то менять.
Если работать постоянно над одним и тем же проектом — тоже ещё можно жить, действительно можно всё настроить чтоб круто и гибко, и привычно. Но когда у тебя несколько разных проектов, все разных размеров и на разных языках от Typescript и Python до Java/Android и C#/Unity, проще взять что-нибудь поудобнее.
Как линукс в нулевых, или тот же инвайт на хабре.
Задаешь прямой вопрос — а ЗАЧЕМ привыкать
Эффективность?
Привыкнув, можно добиться большей эффективности.
Допустим у нас есть файл test.c, в строке 264, нужно pars("(+ 2 3)") заменить на pars(expr). в vim это можно сделать если ввести:
264ggwlcf" — выглядит страшно, но это легко разобрать:
264gg— перейди в строку 264- w — перейти к концу слова
- l — перейти левее
- cf" — удалить всё до следующей
"
(а потом собственно ввести: expr)
В VSCode сначала надо найти 264 строку (может там есть возможность сразу перейти, не знаю) потом выделить, и переписать. Да, неподготовленному человеку будет проще VSCode, но цель оправдывает средства.
F1,test.c,Enter— это если надо предварительно файл открытьF1,:264,Enter— переход к строкеCtrl + F,",Esc— переход к ближайшей кавычкеCtrl + DelилиCtrl+Shift+Rightдо желаемого эффекта, после чего можно вводитьexpr.
l — перейти левееМожет, правее?
Ну что Вы, vim и nano некошерно сравнивать. Если проводить какие-то параллели, скорее между vim и less, у которых / включает поиск, а q символизирует выход.
eumorozov
В vim'овских хоткеях есть своя логика, это да, но касательно
большинство сочетаний клавиш IDE — не мнемонические
есть некоторый минимальный "стандарт" комбинаций типа Ctrl+стрелки как перемещение между словами, Ctrl+F, Ctrl+Del/Backspace, который поддерживается не то что в большинстве редакторов, но и в большинстве приложений вообще.
То, что эти комбинации вынуждают переносить руки и позволяют не переключать режимы, я считаю скорее плюсом, потому что от нахождения в одном и том же положении руки устают больше, но это уже на вкус и цвет.
Допустим у нас есть файл test.c, в строке 264, нужно pars("(+ 2 3)") заменить на pars(expr). в vim это можно сделать если ввести:
У вас это типичная задача при разработке? Пойти куда-то по номеру строки и поменять A на B?
Нормальная задача. Вот прямо сейчас, при попытке сборки:
MyApp.cs(1425,76): error CS1061: 'Document' does not contain a definition for 'DocuumentInfo'
Omnisharp вовремя не подсветил, проклятый MSBuild пишет путь относительно проекта, а не от того места, где VS Code открыт, поэтому нельзя просто перейти по Ctrl + Left Mouse.
Собственно да, есть места, где VS Code проигрывает той же Visual Studio.
Впрочем, это не совсем верно — сборка идёт непрерывно на заднем плане, и скорость подсвечивания ошибок в VS Code примерно равна скорости появления «чего-то красненького» в консоли, где сборка идёт.
Поделитесь секретом?
У меня проект (в глобальном смысле) в основном на C#, включает в себя кучу солюшенов и проектов (в смысле .csproj) с нетривиальными конфигурациями, между ними приходится постоянно переключаться и иногда подсветка и статический анализ не успевают перестроиться, соответственно иногда чтобы отловить ошибки проще запустить таску сборки.
(Да, я посмотрел, что у Вас в хабах C# или .NET не значатся, вопрос в большей мере риторический.)
Поделитесь секретом?
Да нет тут секрета. Понятно, что большие проекты и сложные конфигурации будут неторопливо шевелиться (благо делается-то всё то же самое, что и при обычной сборке, только in-memory).
Но не следует забывать, что скорость набора кода для скорости программирования имеет крайне небольшую важность.
Кстати, типичная рабочая задача — посмотреть git diff файла.
В VS Code (хоткеи могут не совпадать со значениями по умолчанию):
С предыдущей версией: Ctrl + Shift + G
С произвольной веткой: Ctrl + Shift + F1, выбрать ветку из списка, Enter
А в vim скорее всего надо будет делать вызов команды, которой ещё нужно передать путь до файла, и вспоминать как ветка называлась.
Для этого есть Fugitive.
vim: гугл + Stack Overflow + RTFM
:help %комманда%
vim: гугл + Stack Overflow + RTFM
:help %настройка%
Выкачали в .vim/bundle, конечно же вручную
Вы Vundle тогда зачем ставили? И помимо Vundle есть более простые в использовании менеждеры плагинов, например vim-plug.
vim: а вот ищи или думай, это у тебя плагин сломался, или ты сам его отключил, или он и не должен был запускаться для текущего файла.
:script — получить список запущенных плагинов.
vim: гугл + Stack Overflow + RTFM, или копайся в исходниках
А посмотреть описание плагина, не?
Ну и чрезвычайно удобный встроенный плагин для работы с git, из-за которого я и подсел на VS Code уже почти три года назад.
В vim хоть и не встроенный, но такие плагины есть.
Вы Vundle тогда зачем ставили?
Потому что я в них тогда вообще не разбирался и ставил то, что предлагали в туториале
:help %комманда% / %setting%А если я не помню как команда/настройка/плагин называется?
Например (предположив, что все необходимые плагины установлены, но моторные навыки ещё не выработаны), как в vim поставить закладку в одном файле, выбрать другой файл в дереве проекта, включить анализаторы Omnisharp, найти варнинг и применить фикс от Roslynator? (Не уверен, что для последнего есть поддержка в виде vim плагина, но по крайней мере у него есть CLI.) Четыре Три разных плагина со своими мануалами, которые надо изучить. И вместо этого удобная панелька Show All Commands и settings.json, и всё это с отличным автодополнением.
:scriptСпасибо, этого не знал.
CudaText тянет на альтернативу?
А как же старый-добрый NotePad++?
Раз речь зашла об редакторах кода, может кто знает решение: мне переодически нужно открывать другие бранчи чтобы что-то быстро в них посмотреть. Иногда просто чтобы проконсультировать об участке кода, а иногда буквально чтобы посмотреть как это было сделано в какой-то ревизии. Есть ли какой-то способ быстро открыть другую ветку гита с возможностью по ней навигироваться, но при этом иметь текущую так же открытой, а то git stash удобно, но ограниченно, а два раза клонировать репозиторий как-то не совсем удобно.
UPD: https://www.gitpod.io/features/#parallel похоже упомянутая тут https://theia-ide.org/ так умеет...
Расширение GitLens для VS Code так умеет, правда на больших репозиториях делает это очень медленно. Если сравнивать конкретный файл с другой веткой, это гораздо быстрее и можно завязать на хоткей.
К слову о "два раза клонировать" — в git есть возможность держать несколько рабочих копий для одного репозитория. Клонирования не происходит, по сути просто чекаут в другую папку, которую потом не жалко удалить.
https://git-scm.com/docs/git-worktree
Пример:
$ git worktree add -b emergency-fix ../temp master
$ pushd ../temp
# ... hack hack hack ...
$ git commit -a -m 'emergency fix for boss'
$ popd
$ git worktree remove ../temp
Webstorm
На мой вкус, когда регулярно нужно работать с проектами живущих в разных средах и разных ЯП — у vscode нет конкуренции.
Это у них получается за счет мощной системы плагинов и очень качественного терминала.
Бесспорно, под каждый ЯП есть более мощные и крутые частные решения типа qt crearor, inteliJ, и тд.
Но если нужно универсальное решение, то vs code — кажется пока лидер, как универсальный редактор кода, с кучей плагинов под нужные ЯП и окружения
Зачем изобретать велосипеды и текстовые редактоы, когда vim/emacs бессрочно бесплатные и вообще свободные проекты?
Потому что в существующих решениях люди видят фатальные недостатки. Например, они написаны не ими)
Например, они написаны не ими)
Ну это не самый хороший для примера недостаток. Меня от vim/emacs, например, отталкивает необходимость посвятить существенное количество своей «оперативной» памяти запоминанию минимального набора действий для них. В то время как всё, что я помню о VS Code — это примерно два самых нужных мне хоткея. Об остальном я имею только смутные представления о том, где это следует искать/смотреть.
Ну это не самый хороший для примера недостаток.
К сожалению, nih-синдром распостранённое явление.
И если уж речь идёт о VS Code, то почему он появился если уже был Atom?)
В то время как всё, что я помню о VS Code — это примерно два самых нужных мне хоткея.
Ну вы преуменьшаете. Как мне кажется, вы как минимум используете ctrl+c/v/x/z/a, tab, shift+tab, ctrl+shift+p, end, home, shift+стрелки. Это ведь тоже хоткеи)
И для использования какого-нибудь spacemacs вам вряд ли потребуется существенно больше помнить.
С другой стороны, если вы захотите повысить свою эффективность, emacs/vim в отличии от vscode предоставят вам гораздо большие возможности.
И вовсе не обязательно запоминать все. Сборки типа spacemacs предоставляют краткую информацию по биндам. Она появляется при нажатии esc. Т.е. всё что вам нужно это смутное представление, что какая-то возможность существует, а дальше уже найдёте.
И как написано на их сайте:
Key bindings are organized using mnemonic prefixes like b for buffer, p for project, s for search, h for help etc…
P.S. Сам я использую vs code)
Давно уже хочу перейти на spacevim/spacemacs, но решил что прежде нужно научиться слепой печати с dvorak раскладкой. И вот с этим проблема, всё никак не получается.
Ну вы преуменьшаете. Как мне кажется, вы как минимум используете ctrl+c/v/x/z/a, tab, shift+tab, ctrl+shift+p, end, home, shift+стрелки. Это ведь тоже хоткеи)
Это неспецифичные для IDE хоткеи.
И вовсе не обязательно запоминать все. Сборки типа spacemacs предоставляют краткую информацию по биндам. Она появляется при нажатии esc. Т.е. всё что вам нужно это смутное представление, что какая-то возможность существует, а дальше уже найдёте.
А вот вы — так и точно преуменьшаете. Потому что еще придётся разобраться с режимами работы, переключениями между ними, и тому подобной побочкой, без чего лыжи не едут вообще никуда. В VS Code я вместо этого потыкаю мышой в абсолютно стандартном оконном интерфейсе.
И если «кратко» разобраться с чем-то не удалось, то документацию VS Code писали люди, а документацию vim/emacs (и space- вариантов) — я не уверен, кто её писал, но явно не люди. Пока я склоняюсь к версии «восьмипалые рептилоиды с двойным мозгом».
Ну и в конечном счете, даже если в итоге через всё это продраться, то на выходе с VS Code я имею под рукой простенькую, но IDE, а с vim/emacs я имею под рукой текстовый редактор, к которому IDE-фичи надо приделывать отдельно.
Это неспецифичные для IDE хоткеи.
Как и некоторые хоткеи emacs/vim не являются специфичными только для них. Хотя безусловно перечисленные мной хоткеи используются почти во всех приложениях под windows и захватывают/захватили другие платформы.
Потому что еще придётся разобраться с режимами работы, переключениями между ними, и тому подобной побочкой, без чего лыжи не едут вообще никуда.
Ну режимы это не недостаток, а фича. И разобраться надо всего один раз. Учитывая что вы скорей всего разработчик, я рекомендую попробовать вникнуть. Даже если не будете использовать, то для расширения кругозора полезно. Возможно некоторые идеи подхватите и добавите реализующие их расширения для vs code.
Но Atom открытый и был открытым. Тормоза можно было исправить.
Как мне кажется, основной причиной создания vs code было то, что atom в те времена не принадлежал microsoft. И вообще эта ситуация очень похожа на EEЕ. Я сейчас почитал википедию, так ситуация с vs code весьма явно попадает под первые два пункта тактики. Ну и под третий тоже в некотором смысле.
Embrace: создание и продвижение на рынок своей реализации некой ранее существовавшей технологии, основанной на открытых стандартах, достижение хотя бы значимого, если не ведущего, положения на рынке;
Что и произошло, разве нет?
Atom был открытым текстовым редактором на «веб технологиях» с минималистичным, современным, лёгким в освоении интерфейсом и интеграцией git из коробки. Цитата из перевода первого поста с atom.io:
Наша цель — бескомпромиссное сочетание удобства и настраиваемости: редактор, с которым может разобраться и школьник, только начавший изучать программирование, но в то же время и инструмент, который не будет ограничивать опытного хакера.
Т.е. он был первым в своей нише. Ну по крайней мере, я ничего другого не знаю.
И vs code точно такую же цель достигает, причём используя похожие «веб технологии», а именно atom shell, который нынче развился и называется Electron.
Почитайте комментарии к первой новости о vscode. Люди сразу же сравнили его с Atom'ом, потому что похожи по своей сути.
Extend: добавление к технологии своих проприетарных расширений, реализующих нужные пользователям возможности
Точный список я не нашёл, но вот так по памяти: отладка, интелисенс, что-то для C#.
Extinguish: после накопления какой-то критической массы проприетарных расширений идёт полный отказ от оригинальной открытой технологии, замена её на проприетарную с сохранением при этом внешнего вида технологии для пользователей. Так как на этом этапе продукт уже является лидером рынка, открытая технология умирает из-за отставания от проприетарной
А вот это только частично. Продукт можно сказать что лидер рынка. Однако закрытия кода пока что не будет. Нынче Microsoft якобы «love Linux» и вообще за опенсорс. Слабо верится.
Начнем с того, что Atom это не технология, а конечный продукт.
Первая часть моего предыдущего поста как раз-таки была об описании «технологии» или скорее ниши среди текстовых редакторов, которую atom занял первым. А потом пришли microsoft, взяли ядро(atom shell), идеи и запили похожий продукт. Не то чтобы они нарушили законы, но их методы мне не нравятся.
Их решение конечно лучше, и люди выбрали в итоге его. Но с тех пор конкуренции по сути пришёл конец и microsoft перестал концептуально развивать редактор.
Только сейчас я понял, что github codespaces может быть эдакой 3й стадией — Extinguish. Vs code конечно остаётся открытым, но microsoft будет переманивать людей на облачную версию. Которая уже вполне закрыта. Она будет обрастать уникальным функционалом, или vs code постепенно начнёт тормозить, или вообще прекратит развитие. Может быть всё вместе, тут простор для действий большой.
Далее, EEE возможна только на технологиях, не принадлежащих компании, в то время как Atom был тупо куплен вместе с GitHub.
Вы бы посмотрели на дату выхода Atom, vs code и дату покупки github'a. Разница в несколько лет минимум.
А вот, то, что Atom умрёт, это понятно, но не потому что Майки его закроют, а просто потому, что он нафик никому не нужен.
Он уже отчасти мёртв. И был до покупки гитхаба, потому что vs code отобрал нишу.
Поставьте, для начала, vim-плагин для Vs Code.
Да не, не настолько уж и жалкой. Чего именно вам не хватает?
ripgrep в vs code уже и так интегрирован. fzf — для переключения между буферами? А чем вас стандартный ctrl+p не устраивает? В этом плане VS Code, кстати, как раз неплох.
В плане скорости, кстати, уже более-менее, по моему субъективному ощущению. Годик назад курсор заметно лагал, а теперь нет. Ну или я тормознее стал за год :)))) Кстати, что интересно, ускорение Vim-плагина даже заявлено в roadmap.
Есть ещё и плагин Neo Vim, который интегрирует настоящий neovim, но он, по ощущению, ещё сыроват (или я не осилил его настроить).
А если ради быстрого редактирования одного файла, то, конечно, да, тогда даже из терминала смысла нет выходить :D
Давно уже хочу перейти на spacevim/spacemacs, но решил что прежде нужно научиться слепой печати с dvorak раскладкой
Из моего опыта, более продуктивно сделать наоборот: перейти на vim-режимы, и получить слепой набор в подарок. Я когда-то именно так и сделал (правда отмечу, у меня qwerty). vim режимы вынуждают использовать основную часть клавы просто для передвижения по коду, и поскольку ты не можешь постоянно поглядывать вниз при навигации, ты постепенно просто запоминаешь локации клавиш. Причём, включая клавиши с цифрами, т.к. они полезны для быстрых манипуляций сразу множеством строк (или иных текстовых объектов). Единственное, я рекомендую включить hybrid line-numbers, чтобы понимать сколько строк вам надо скопировать или удалить. upd: уточню, в Emacs-derivatives для этого надо выставить (setq-default display-line-numbers 'visual) в конфиге.
Хоткеи и, в целом, гибкость — это как раз не минус, а большой плюс вима и емакса. Но то, что за Vs Code и многими расширениями стоит много людей и ресурсов — это заметно, и тут ни вим, ни емакс не поспевают.
UPD: разработчиков в смысле разрабатывающих что-либо для самого редактора.
https://github.com/vim/vim
Contributors: 2, из которых первый — создатель, а второй законтрибутил один коммит на 10 строк
https://github.com/neovim/neovim
Contributors: 553, из которых человек 8 регулярно активных
https://github.com/microsoft/vscode
Contributors: 1198, из которых человек 20 занимаются им в качестве основной работы, во главе с небезызвестным https://github.com/egamma, из той самой "банды четырёх"
Ну и контрибуторы не всегда означает разработчиков. Там вполне могут быть люди правившие readme или комментарии)
github.com/search?o=desc&q=topic%3Avscode
4,468 repository results
github.com/search?q=topic%3Avim
7,592 repository results
Почти в 2 раза. И учтите, что vim существовал задолго до появления гитхаба и что есть другие площадки по типу гитхаба.
В общем, не очень удачная методика сравнения. Но, думаю, показывает что под vim создают больше.
Кстати, звёзд у neovim больше чем у vs code. Может быть и используют его больше?
разработчиков в смысле разрабатывающих что-либо для самого редактора.
Я неправильно Вас понял. Про контрибьюторов согласен, поэтому отдельно указал количество тех, кто судя по статистике вносит активный вклад.
Но опять же, надо учитывать, что то что в виме реализовывается с помощью плагинов, в VS Code идёт уже встроенным, для примера:
- Менеджер плагинов:
https://github.com/VundleVim/Vundle.vim - Дерево файлов:
https://github.com/preservim/nerdtree - Темы:
https://github.com/vim-airline/vim-airline
И каждая из этих фич имеет миллион реализаций. А то, что не встроено ни там ни сям, но крайне востребовано, имеет свои плагины:
https://github.com/OmniSharp/omnisharp-vim
https://github.com/OmniSharp/omnisharp-vscode
Я не "топлю" однозначно за VS Code и против vim, оба являются отличнейшими редакторами, просто из VS Code гораздо проще сделать универсальную IDE, чем из vim, поэтому она и обрела такую популярность.
И каждая из этих фич имеет миллион реализаций.
И плюс и минус. Иногда хочется чтобы просто работало без дополнительных усилий. А иногда хочется настроить под себя. Как мне кажется, vim в последнем случае выигрывает. Как и vs code в первом.
поэтому она и обрела такую популярность.
Я думаю, не из-за этого. А из-за примитивного мышкотыкательного интерфейса в котором легко разберётся большая часть людей, современного дизайна, ну и рекламы конечно.
UPD: Всё же интересно, какой из редакторов использует больше людей.
А иногда хочется настроить под себя. Как мне кажется, vim в последнем случае выигрывает.
Не пробовал ещё писать плагинов к VS Code и TypeScript видел только понаслышке, но к VimScript возвращаться не хочется :))) Если настроить под себя, то, тогда уж, emacs.
Я знаю штук 30 редакторов для программистов. И думаю — не написать ли мне еще один…
спросить у знающих (эти инструменты) людей: что действительно повысит, или может повысить комфортность разработки в плане создания/корректировки/разбора (и т.д.)
Скажите, а ваши проекты — они все настолько маленькие, что вы обходитесь без отладчика?
Следующий момент — автодополнение кода и шаблоны ввода. Причем первое, это не просто способ меньше набирать, но и меньше гуглить. Если вы не помните наизусть название и параметры какого-либо метода, но знаете, что что-то такое должно быть у библиотечного класса, просто начинаете набирать и смотреть.
Пока побеждает лень. Но я готов прислушаться к разумному совету, подходящему для моих условий. Это Windows, отсутствие передачи данных моей разработки на сторону, чтобы глаза «не ломало» — всякие экранные возможности отображения текста, минимум мышиной возни. Ну и чтобы в итоге удобно было. Что посоветуете?
Да, я действительно обхожусь без специального отладчика. Но отладку я всё же делаю в 99% случаев с помощью вывода отладочных сообщений на экран или в файл журнала.
Это не отладчик. Если ваши проекты немного вырастут, вам потребуется настоящий отладчик, просто потому, что без него багу можно искать часами.
Странная подборка, про некоторые альтернативы первый раз слышу, при этом забыли старичков (Vim, Emacs, не говоря уже про их новые вариации типа Neovim, Spacemacs, Kakoune) и более известные альтернативы (Notepad++).
Про себя: использую Emacs с тыщей плагинов и модальным редактированием как в Vim (evil-mode), но это меньшее зло, идеального редактора не существует. Очень большие надежды возлагаю на xi-editor, быстрый модульный редактор на Rust, и по мере сил участвую в его разработке, но он перманентно в недоделанном состоянии, а в создании экосистемы плагинов для него ещё конь не валялся, годы пройдут, пока она вырастет до уровня конкурентов.
P. S. Да, мне известно про существование Vim-плагинов — которые хоть и работают, да не так.
Очень большие надежды возлагаю на xi-editor, быстрый модульный редактор на Rust, и по мере сил участвую в его разработке,
Можете сказать чего хорошего в нём?
Я ещё года полтора назад услышал про xi, но так и не понял почему некоторые его восхваляют(ну помимо фанатов rust'a). Особого смысла от разделения на бэк и фронт для текстового редактора я не вижу, а остальные фичи не кажутся значимым и частично реализованы в современных сборках vim и emacs.
Вообще, заметил за любителями rust склонность переписывать всё что угодно на rust. Иногда получается что-то достойное, но зачастую выходит по функционалу 80% от оригинала. Причём в ридми помимо прочих фич этого «крутого» проекта обязательно указывается бонусом то, что он написан на «безопасном и быстром» расте.
P.S. Глянул ридми различных фронтендов, что-то не заметно прогресса за год.
Можете сказать чего хорошего в нём?
Для меня:
Возможность писать фронтенд и плагины на любом языке. Это отдельные приложения, сервер общается с ними на JSON-RPC, асинхронно. По сравнению с Vimscript и Emacs Lisp — просто небо и земля (хотя, справедливости ради, в Emacs есть API для динамической загрузки плагинов на C).
Быстродействие и снижение затрат по памяти — священная корова проекта. В документации прямым текстом требуется от разработчиков "любая базовая операция редактирования должна выполняться не больше 16ms". Куча оптимизированных структур данных (инкрементальные обновления кэша строк д. клиентов, оптимизированное хранение строк), всюду асинхронность.
Высокая модульность, отдельно сервер, отдельно клиент, отдельно language server, предпринимаются попытки выделить структурные компоненты редактора в отдельный SDK, на котором можно писать xi-подобные редакторы.
(Только для разработчиков IDE): редактор в начальной стадии разработки, можно попытаться реализовать мечту об идеальном редакторе. Проект известный, можно почесать эго и вписать своё имя в историю.
(Только для Rust разработчиков): Идеален для вкатывания в rust разработчику уровня сеньёра с опытом в других языках — многокомпонентный сложный продукт, даёт универсальные знания (обработка юникода, кэшей строк, асинхронное взаимодействие компонентов), куча как архитектурных задач так и деталей реализации. Отличная строчка в резюме.
Rust и Cargo со всеми их преимуществами.
Я ещё года полтора назад услышал про xi, но так и не понял почему некоторые его восхваляют(ну помимо фанатов rust'a). Особого смысла от разделения на бэк и фронт для текстового редактора я не вижу, а остальные фичи не кажутся значимым и частично реализованы в современных сборках vim и emacs.
Это так, редактор выстрелит только если реализует какие-то киллер-фичи для разработчиков которые будут в нём кодить, а для не разработчиков редакторов. Пока я слышал восторги только от вторых (которые на данный момент и являются основной аудиторией xi), из пользовательских фич пока демонстрировать нечего.
Вообще, заметил за любителями rust склонность переписывать всё что угодно на rust. Иногда получается что-то достойное, но зачастую выходит по функционалу 80% от оригинала. Причём в ридми помимо прочих фич этого «крутого» проекта обязательно указывается бонусом то, что он написан на «безопасном и быстром» расте.
Хех, есть такое, Xi ещё ладно, это разработка с нуля, а вот тут Emacs переписывают на расте. А ещё на расте (не на шелле) написан rustup, инструмент разворачивания и управления toolchain'ами раста. Да, чтобы изменить его поведение, надо его перекомпилировать, что очень весело делать, если он не отработал до конца и rustc ещё нет в системе.)) За себя скажу, что мне подход "Rust всюду" не нравится, я при всей своей симпатии к Rust не применяю его без нужды. В любом случае, эта проблема к Xi не относится, я бы контрибутил в него даже если бы он был скажем на C/C++ а не на Rust, его фишка в архитектуре и структурах данных, а не в языке.
P.S. Глянул ридми различных фронтендов, что-то не заметно прогресса за год.
Это известная проблема, сервер (xi-core) страдает от нехватки внимания ключевых разработчиков, тк лидер проекта и ещё 1 ключевой разработчик сейчас заняты на платной основе другими проектами на Rust — runebender и druid. А разработка клиентов тормозится багами сервера и тем фактом что я уже упомянул — догнать известные редакторы/IDE по функциям это задача на годы.
официальная сборка от Microsoft настраивается с учетом специфических функций, включая (...) телеметрию
… которая элементарно и штатно отключается:
code.visualstudio.com/docs/supporting/faq#_how-to-disable-telemetry-reporting
code.visualstudio.com/docs/getstarted/telemetry
Но у некоторых при произнесении слова «проприетарный» включается режим экзистенциального ужаса и они бегут без оглядки, вместо того, чтобы просто совершить одно-два несложных действия, решающих то, что им кажется проблемой.
P.S. Использую Codelite и GCC под MSYS2 для homebrew проектиков. Вроде хватает.
Лучше ли оно Codelite? Думаю — да, инструментов побогаче. В настройке — заметно сложнее. Если Codelite заметно черпает вдохновение из Visual C++, то тут все другое. Буду ли ставить VSCodium — не уверен.
Не хочу Visual Studio Code: 7 open source альтернатив