File -> Open же.

Какой смысл?

Чтобы

а) иметь возможность показать код или конфиги другому, прежде чем выкатишь их в продакшен. Или хотя бы самому над ними помедитировать.

б) иметь возможность работать с более чем одним конфигом за раз.

в) гарантировать, что не затрёшь случайно то, что там одновременно наваял твой коллега. Или, опять же, ты сам в другой терминальной сессии, о которой ты забыл.

г) иметь возможность часть работы сделать оффлайн.

д) иметь возможность прогнать тесты перед деплоем и выявить явные косяки

е) …

ё) ПРОФИТ!!!

б) и я уж не говорю о том, что можно использовать любой удобный тебе редактор, а также многочисленные текстовые тулзы.

Чтобы жизнь мёдом не казалась?

Как раз наоборот. Правильное использование инструментов и аккуратная их настройка очень сильно облегчают жизнь.

Ты даже не представляешь, какую дикую ахинею ты сейчас несёшь. Ты смотришь на процесс со своей колокольни, которая никакого отношения к моему процессу разработки не имеет. Мне совершенно необходимо иметь возможность редактировать конфиги на том кластере, на котором работает моя модель, потому что набор конфигов для каждого из 100500 экпериментов - индивидуальный. Это большая разница с тем процессом, когда ты можешь написать конфиг один раз, задеплоить, и гонять 100500 экспериментов. Гит тут вообще не в кассу. Гит служит для контроля версий а не для того чтоб синхронизировать конфиги. Я уже молчу про кучу рабочих скриптов для анализа результатов, которые ни в какой гит никогда не идут, поскольку там не нужны.

Сообщество Raspberry Pi в целом очень плохо разбирается в линуксах. Достаточно попытаться погуглить какую-нибудь проблему, и вопросы, и главное ответы будут очень бестолковыми.

Это на самом деле интересно, потому что как раз люди, которые увлечены всякими железками, они как пользователи очень позитивные, готовы чинить, если сломалось, ломать если не починилось и т.п. И потенциально линуксоиды по духу.

Но у них там неоткуда учится нормальному администрированию и правильному использованию, одни нубы кругом.

Это большая разница с тем процессом, когда ты можешь написать конфиг один раз, задеплоить, и гонять 100500 экспериментов.

У нас на работе деплой происходит по пятьдесят раз на день. Не вижу, в чём проблема.

Гит служит для контроля версий

Ага. ДО того, как они идут в продакшен, а не после.

Я уже молчу про кучу рабочих скриптов для анализа результатов, которые ни в какой гит никогда не идут, поскольку там не нужны.

Почему, собственно? Как миниму, если ты их сохранишь, то в дальнейшем сможешь поймать допущенную ошибку.

Вообще, ты, по-моему, считаешь, что коммит в гит — это что-то такое большое и тяжёлое, и должно использоваться только при крайней необходимости. Это не так.

Потому что у них-то пол хакатона уходит на то чтобы монитор с клавиатурой найти и подключить.

Ох блин… Просто блин. Еще одно разочарование в этой планете…

У нас на работе деплой происходит по пятьдесят раз на день.

Ты опять смотришь со своей колокольни на чужой монастырь. Так не надо делать. Твои методы в моей работе абсолютно не применимы. Комитить все мои конфиги и скрипты для каждого эксперимента не имеет никакого смысла, т.к. это сделает любую репу - адским бардаком. У них версий нет, контролировать в гите нечего. Комитятся только «generic» конфиги, или скритпы, которые их генерируют. Редактируется всё на одном и том же кластере. Так работают все центры в нашей области, смирись с этим.

ДО того, как они идут в продакшен

У нас нет такого понятия «продакшен». Оно к нашей работе не применимо.

Ты уже пойми, что процесс разработки приложения для андроида сильно отличается от процесса разработки научной модели. Это тема пережёвана миллион раз в разных кругах, можешь статьи нагуглить сам.

Комитить все мои конфиги и скрипты для каждого эксперимента не имеет никакого смысла, т.к. это сделает любую репу - адским бардаком.

Лучше бардак в репе, чем бардак в кластере.

Так работают все центры в нашей области, смирись с этим.

Мне смиряться не с чем, я в вашей области не работаю. А вот ты явно смирился, и это плохо.

У нас нет такого понятия «продакшен».

У вас есть такое понятие. Это то, что на кластере. И вы постоянно лазаете туда со своими ад-хоками. И это плохо.

процесс разработки приложения для андроида сильно отличается от процесса разработки научной модели

Я не знаю, как разрабатывают приложения для андроида. Но знаю, что любая разработка выигрывает от того, что ты позволяешь автоматике беспокоиться о том, что она может сделать.

Мне смиряться не с чем, я в вашей области не работаю.

А экспертное мнение имеешь, ага. В нашу область таких как ты не берут, не волнуйся.

У нас нет такого понятия «продакшен».

У вас есть такое понятие. Это то, что на кластере.

Ахахаха! Вот ты просто понятия не имеешь, что у нас есть на кластерах (именно на кластерах), а лезешь с совершенно идиотскими умозаключениями.

Я очень рад, что твои методы работают для тебя, но можно ты не будешь меня учить, как мне делать мою работу? Спасибо.

В нашу область таких как ты не берут, не волнуйся.

<====

– Разрешите обратиться? – я вынул руки из карманов.

– Обращайтесь. – процедил капитан.

– Вот это… – я никак не мог найти подходящие слова. – Голыми руками на щебенке… Это такая особая тренировка для десанта?

Капитан подумал и ответил:

– Идите отсюда.

– У них же кровь течет из пальцев, товарищ капитан!

– Молодой человек! – сказал капитан. – Не мешайте заниматься! Кру-гом!

ББМ дружно сплюнула под ноги, даже не думая выполнять команду.

Тогда отвернулся капитан. И сказал своим лысым:

– А вы не обращайте внимания. Из этих… – он ткнул пальцем за спину, – никогда не получатся десантники!

Как бригада принялась ржать – двадцать лет прошло, а помню.

====>

Вот ты просто понятия не имеешь, что у нас есть на кластерах

Сужу по тому, что ты сам рассказываешь.

именно на кластерах

Это что, по-твоему, достижение?

И тут Остапа понесло. Если тебе сказать больше нечего, то незачем засирать ветку, я считаю.

По теме. Емакс себя изжил.

О! Ещё один хоронильщик.

очеловечиване Emacs

Старо, но подкину на вентилятор:

How to Use Emacs

First, you need to ``remember'' where emacs is, using the `rm' (remember) command:

        rm -f `which emacs`

Next, you need to tell the system that you want to use emacs in ``visual'' mode:

        alias emacs=vi

Now, you're all set to use emacs! To edit a file, just type

        emacs filename

I hope this information has been useful.

Вот почему я использую кнопку «игнор» для граждан, которые слишком много флеймят. Это совсем не потому, что я вас ненавижу, мои болтливые друзья. Это потому, что сначала ты читаешь портянки бреда, потом отвечаешь на него, а потом приходит модер и всё трёт. Какая трата времени!

Там же выбором у них было. Хочешь, графический, хочешь, консольный. Я, например, консольный юзаю и мне пофиг на графический. Но многим сложно.

Да в топике непонятно о чём речь идёт. Об UI для emacs? Их есть несколько, для разных платформ. Меня допустим классический гнушный более чем устраивает. Кого не устраивает классический, пилят свои. Всё идёт так, как завещал великий Столман. И это прекрасно.

Ну я вот в конце нулевых искал замену для редактора Bred. Выбрал Emacs в том числе по приведенным вами аргументам. А сейчас другая история - пытался найти среди современных редакторов хоть что-то подобное в плане возможностей и гибкой настройки. Этого больше нет нигде. Даже Vim по удобству настройки немного не дотягивает. Так что альтернатив просто нет. Но, да, нужно больше молодежи в это дело привлекать.

Уже завезли альтернативу?

vscode Весь необходимый функционал добивается плагинами. Настраивать ничего не надо, всё работает из коробки. Remote режим в нем на голову выше чем emacs tramp.

VSCode пробовал. Все что и как я хочу плагинами не добавляется. В то-то и дело, что мне нужно настроивать. А вот процесс настройки гораздо менее удобен. Кроме того, Emacs - это не только множество добротно сделанных плагинов. Это еще и определенная культура разработки. Плагины перед добавлением в MELPA проходят code-review. Но даже дело не только и столько в ревью. Дело именно в культуре и традициях. Откройте и почитайте код плагинов для Emacs. Все четко структуритовано, везде докстринги, комментарии и т.д. В сторонних плагинах VSCode этого нет, там, зачистую, просто хаос, хоть внешне это как-то и работает. ИМХО, именно по культуре кода VSCode потребуется еще несколько десятилетий, чтобы достичь уровня Emacs.

Ну и что, мне всё равно какая там «культура разработки», если оно работает плохо. А по факту работает плохо.

Как видишь завезли. Раз у емакса 3% пользователей, пусть и в выборке скорее всего по большей части среди веб разработчиков.

Просто ты из консерваторов и тебе самому в этом надо признаться. То ли в силу возраста, то ли в силу еще чего-то тебе тяжело дается новое.

Вим легче настраивается, удобнее в работе и легковеснее. Только не надо тут про оргмод вспоминать, которым пользуются 3% от 3%.

мне всё равно какая там «культура разработки»

Одна из причин по которым емаксом можно удобно пользоваться не заучивая десятки горячих клавиш - это последовательность, в названиях имен переменных, функций и команд, в выборе комбинаций клавиш и т.п.

Такая последовательность - это основа хорошего UX. Выучил одну команду - знаешь их все.

И в системах собранных из плагинов она как раз достигается за счет культуры разработки.

Так что нет, пользователям совсем не всё равно, что там за культура.

Настраивать ничего не надо, всё работает из коробки

Я уже в этой теме привёл пример самого обычного сплита который vscode абсолютно неюзабельный. Базовая возможность редактора как бы и такие вот проблемы. И настроить там хотелось бы хоткеи и работает оно не вполне так как хочется. Может плагины какие-то есть по управлению сплит окнами? Или что, «ненужно»?

Ты вроде бы один из самых адекватных емаксеров на портале, поэтому отвечу.

Да я понимаю, что тебе такой функционал нужен и никто тебя не агитирует покидать имакс, если лично тебе удобно, но как тебе в этой же теме уже отвечали, для 99% задач одного сплита с головой хватает и легче бафферы переключить, нежели по окнам или сплитам прыгать (и по-моему там же сайчас больше сплитов и взаимодействия с ними завезли). Я даже сейчас не вспомню когда я сплитил последний раз хотя бы три окна в виме (не считая второстипенных переключающихся по хоткею типа встроенных терминалов или файл-менеджеров). И ты вот к этой фиче прицепился и вторишь уже по 10 раз, что вот в емаксе ОНО-то есть - значит говно ваш вскод. Но опускаешь любые другие преимущства, которые у него перед тем же имаксом (только из-за того что ты о них даже не знаешь).

Тот же лсп в имаксе на уровень хуже, чем в вскод, в виме хотя бы coc.nvim завезли.

99% задач одного сплита с головой хватает

Я даже сейчас не вспомню когда я сплитил последний раз хотя бы три окна в виме

А я тебе отвечу, что ты этого не делаешь, потому что в твоих инструментах это тупо неудобно. И далее как в известной басне про лису.

к этой фиче прицепился

Что ж делать, если приходится повторять по 10 раз? Казалось бы одного раза достаточно, нет опять лепят свои сказки про то что в vscode «ничего настраивать не надо и т.д.» Ну, мне лень каждый раз новый контрпример приводить, пусть сначала с этим разберутся.

опускаешь любые другие преимущства, которые у него перед тем же имаксом

Для меня лично никаких существенных преимуществ у vscode просто нет. Они есть, например, в java ide при разработке на java в виде интеграции ide и среды выполнения со всеми вытекающими удобствами. Но не в vscode и даже не в webstorm.

только из-за того что ты о них даже не знаешь

Знаю, но они не перевешивают неудобств.

значит говно ваш вскод

Нет, не значит. Это значит, что люди которые говорят что vscode это модно, молодёжно и т.д, а emacs устарел, кое-чего недопонимают. Настолько недопонимают, что даже не чувствуют, что в их инструменте есть существенные проблемы, которые ограничивают его использование (до степени отвержения опытными пользователями). Недопонимают, даже когда их 10 раз натыкают носом.

Тот же лсп в имаксе на уровень хуже, чем в вскод

На этот счёт я не могу судить, ибо не пользовался vscode достаточно долго и поэтому сложно сказать насколько там lsp лучше работает чем у клиентов под emacs. В целом, для emacs есть поддержка lsp, но мне по итогам трехмесячного тест-драйва не особо понравилось. В частности для пыха родной ac-php лучше. Js слишком «текучий» язык, никакое автодополнение нормально не справляется. В голанге вообще своя атмосфера с изкоробочной автодополнялкой. Для Си есть rtags. Ну и т.д.

На этот счёт я не могу судить, ибо не пользовался vscode достаточно долго и поэтому сложно сказать насколько там lsp лучше работает чем у клиентов под emacs.

Тоже не могу сказать, но в последний раз может год назад когда нужен был пистон для небольшого проекта, я попробовал его и под VSCode. Медленно и выдает какую-то чепуху, так что я просто расчехлил JIdea. Вообще, не замечал чтобы vscode где особо сиял, кроме как на веб-стеке. Ну это и не удивительно для браузерного движка. Никто по аналогии не удивляется тому, что emacs с лиспами легко справляется.

Предложений много, только кто их будет реализовывать и поддерживать? Даже банальные видосы писать про работу с модами или гифки делать.

Что-то живет в emacs среде что то появляется и исчезает.

У меня вот проблема что я не могу переписать то что мне нужно, меня отсылают к чтению кода ,начинаю читать все эти 100500 мелких функций, у которых иногда не видно откуда они вызываются и всё ступор.

Когда нибудь я разберусь даже гайд хороший по ELisp нашел с примерами а не офф дока ,которая хромает на примеры Гайд

И кстати там очень многие доки хромают… но это в принципе в опенсорсе так. Да и поговорить о Emacs редко с кем получается.

Ну и что, мне всё равно какая там «культура разработки», если оно работает плохо. А по факту работает плохо.

Что именно-то плохо работает? Единственное в чем действительно Emacs не дотягивает, так это до Java IDE уровня Intellij Idea.

Как видишь завезли. Раз у емакса 3% пользователей…

Количество пользователей - вообще не критерий. Да, порог входа чуть повыше, но в итоге возможностей гораздо больше. Собственно, топик LOR-а в пример. Коль у Windows больше ползователей, то все, значит Linux хуже что ли? Нет, такая логика не работает.

Просто ты из консерваторов и тебе самому в этом надо признаться.

Точно нет. Много альтернатив смотрел, притом и мейнстримовых и куда более экзотических, некоторые даже основательно покопал.

Вим легче настраивается, удобнее в работе и легковеснее.

С Вима и начинал. Некоторое время пытался честно привыкнуть к модальности. Не привык - занялся глубокой перенастройкой переделал все под один режим. Получился комбайн, ломающий принятые в редакторе вещи. То есть, я бы сказал, нечто более близкое к Емаксу, чем у Виму, но с вимовским, менее удобным языком конфигурации. В итоге и перешел на Emacs :).

Тот же лсп в имаксе на уровень хуже, чем в вскод, в виме хотя бы coc.nvim завезли.

Писал на Scala через lsp в Emacs и VSCode. После хорошей такой кастомной настройки Emacs (да, надо сказать, без этого не обошлось), Emacs не уступал VSCode совем.

А вот что касается прочих аспектов разработки, не связанных с lsp в VSCode, то там настраивать и настраивать, писать плагины и разбираться годами, чтобы было как Emacs или хотя бы не хуже.

Что именно-то плохо работает?

Например, tramp работает отвратительно.

Да в общем-то никаких проблем с этим не испытывал. Впрочем, прямо много и серьезно ничего не писал через tramp, только редкие небольшие редактирования конфигов.

А вот что касается прочих аспектов разработки, не связанных с lsp в VSCode, то там настраивать и настраивать,

Поподробнее, что-то в твоих постах будет нежели такая вода (чем-то лучше, что-то там не натсраивается, мне удобнее)?

С Вима и начинал. Некоторое время пытался честно привыкнуть к модальности. Не привык - занялся глубокой перенастройкой переделал все под один режим

Хотя я передумал, можешь не отвечать.

Разговор с имаксерами в любой теме.

• У редактора Х нет вот этой фичи, которой пользуются 1,5 человека в мире - как можно без этого? Отстой.
• Ну зато у редактора Х есть y, и z реализовано лучше чем у имакс.
• Ну я y не пользуюсь, а z меня и так устраивает, так что не убедил. Имакс форева, все остальное - пыль.

Поподробнее, что-то в твоих постах будет нежели такая вода (чем-то лучше, что-то там не натсраивается, мне удобнее)?

Написано про Atom, но с VSCode во многом аналогичная ситуация: Emacs vs Atom по производительности (комментарий).

переделал все под один режим

Хотя я передумал

Because I can. Да и вообще, дело было в 2007-м ;).

У редактора Х нет вот этой фичи, которой пользуются 1,5 человека в мире - как можно без этого? Отстой. Ну зато у редактора Х есть y, и z реализовано лучше чем у имакс. Ну я y не пользуюсь, а z меня и так устраивает, так что не убедил. Имакс форева, все остальное - пыль.

Если эта фича - это удобная возможность самостоятельно реализовать и настроить под себя y, z, а также a, b, c, d, e, f, g, h, k и так далее, то, да, эта «единственная» фича действительно более важна, чем уже хорошо реализованные и y, z в другом редакторе.

Какая аналогичная ситуация. Почти все что ты перечислил уже и в атоме есть (если опустить твою демагогию про 3-7-1232134%-самнезнаюсколько от того что есть), не говоря про вскод.

Да уже в любом современном редакторе можно реализовать почти что что угодно (ограниченные только архитектурой) на языке, который применяется для его плагинизации. только вот кто это реализовывать в имаксе будет, ты или еще 200 человек им пользующиеся? А дальше кто поддерживать будет? Так что тут ты никого не удивишь. Очевидно же, чем больше база пользователей, тем больше вокруг продукта различных дополнений созданных юзерами и это не только редакторов кода касается.

Может быть. Я с 2016 года больше ни Atom, ни VSCode не смотрел. Но и необходимости нет.

Ну да учитывая, что vscode из беты вышел в 2016. Не смотри и дальше. Просто непонятно тогда, зачем ты со своим экспертным мнением рассуждаешь, что есть и чего нет в других редакторах? Пользуйся на здоровье своим имаксом, ничего зазорного в этом нет.

Да уже в любом современном редакторе можно реализовать почти что что угодно

Можно. Просто в Emacs это удобно. Но популярность новомодных средств разработки приходит и уходит, а Emacs остается. Для меня оказался весьма наглядным пример jEdit. Некогда его популярность стремительно росла, было (и все еще есть) активное комьюнити, которое поддерживало, разрабатывало плагины (для этого использовалась Java). Я тогда погрузился в это дело с большим интересом. А потом автор проекта потерял к нему интерес и несколько лет спустя я видел его скриншоты с кодом другого проекта сделанные в Emacs :). Много ли сейчас людей используют jEdit и вообще знают о нем?

Ну да учитывая, что vscode из беты вышел в 2016. Не смотри и дальше.

В моем понимании это вообще-то не так давно было. В то время как в Emacs нужная мне функцональность существует уже десятилетиями :). Есть у меня некоторое подозрение, что когда я в очередной раз, лет через 10, вылезу из машины времени у землян будет популярен какой-нибудь очередной новомодный редактор xyz и они вновь будут кричать, да ты что, ты смотрел xyz целых две недели назад, да за это время уже все поменялось. Вообще все, это теперь совершенно новый редактор, его не узнать, а уж с той версией, что была в прошлом месяце сравнивать - так это вообще не понимать о чем идет речь! ;)))

мимо проходил

тред не читал.
почему я пользуюсь nano, и чем меня отпугивает vi и emacs:
1) нет явного бросающегося в глаза обозначения, что сейчас активен не режим ввода текста, а режим команд. по хорошему должна быть возможность ЧТОБ БЫЛА КРАСНАЯ ПОМЕТКА, что сейчас режим ввода текста не активирован.
2) более сложные комбинации клавишь, чем в нано. по хорошему в редакторе должен быть выбор режима ввода: либо нано, либо ви, либо емакс, с возможностью переназначения комбинаций
возможно, разработчикам текстовых редакторов стоит задуматься.

А какие у вас проблемы с emacs и docker?

Как видишь завезли. Раз у емакса 3% пользователей

Это в два раза больше чем у линукса или в три?

Как нормально прокинуть LSP-сервер из докера, например.

Например, tramp работает отвратительно.

Например, регулярно пользуюсь трампом. Ни единого разрыва.