LINUX.ORG.RU
ФорумTalks

Emacs, VS Code, NeoVim, IntelliJ IDEA... and Emacs

 , , , ,


3

5

В названии, конечно, отсылка к фильму Spring, Summer, Fall, Winter… and Spring.

Обещал накатить вброс по Emacs, ибо как писали постом выше, народ заскучал. Речь идет о продолжении топика Жизнь после Emacs.

Вообще, суть моего мессенжа, пожалуй, точнее всего передает это короткое видео :).

Но если все же попытаться раскрыть суть чуть подробнее. Да, лучше Emacs пока никто ничего не придумал, хотя есть интересные попытки. Никакие элементы архаики, сохранившиеся в Emacs не могут преуменьшить те уникальные преимущества, которых больше нигде нет. Тут дело не в том, что в других редакторах/IDE они хуже или, скажем, они пока недоработанные. Их просто нет.

Итак, в продолжении темы предыдущей серии, я перешел на 1,5 года на VS Code.

Плюсы:

  1. Производительность UI, который рендерится на GPU.
  2. Производительность JavaScript (спасибо Electron/NodeJS/V8).
  3. Вменяемый API.

Минусы:

  1. Не keyboard-centric. Некоторые вещи вообще без мыши не сделать, что раздражает.
  2. Хотите переименовать текущий файл? Вам нужен плагин для этого! В Emacs это была бы просто небольшая функция - кинул в конфиг и всего делов. Тут же 8 плагинов, половина из них заброшена в 2015-м, другая половина помимо необходимой функции добавляет еще 100500 других. Доков нет, докстрингов нет, что кто-то другой будет открывать код плагина и в мыслях не было. Спасибо, если есть ридми, пусть и не обновляемая много лет, и уже не релевантная коду.
  3. Культура разработки. Вне официального кода от Microsoft ее нет (см. выше). Писать плагины на ClojureScript возможно, но не вполне натурально (как проба пера, например advanced-navigation-cljs). Да, есть еще joyride. API неплох, да, но многие вещи гвоздями прибиты и всего не настроишь.

Наверное, основной вопрос в плане конфигурации VS Code по сравнению с Emacs в том, что для Emacs можно было не особо переключаясь из контекста текущей деятельности быстренько перейти в .emacs, что-то там подправить и вернуться к основной задаче. В VS Code флоу совсем иной. Если ты вдруг понял, что тебе нужно что-то доконфигурировать, ты понимаешь, что либо на это нужно просто забить, либо мысленно сказать что-то вроде, «ну что ж, а теперь девочки и мальчики мы все бросаем и осваиваем/вспоминаем специальность «конфигуратор/плагинописатель» для VS Code», ибо быстренько что-то подхачить там не выйдет. Например, тебе дополнительно нужен инстанс среды для тестирования изменений плагина. Плагин дописывается, отлаживается и потом устанавливается в рабочую среду. Если же, ко всему прочему, это не твой плагин (что почти всегда), то нужно понимать, что вникать придется долго, ибо комментариев и докстрингов нет примерно никогда (за исключением собственно описания API от Microsoft).

При этом, всегда надеяться на то, что все будет «просто работать» нельзя. У меня например, после очередного обновления как-то отваливалась Calva (Clojure IDE) и edamagit (Magit for VSCode). Опять же, в Emacs у меня тоже были случаи, когда достаточно мейнстримовые плагины приходили с ошибками после очередного обновления. И в этой ситуации всегда можно быстренько это на лету починить, зарепортить багу или сразу прислать пулрек мейнтейнеру.

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

Плюсы:

  1. Производительность UI, для чего делаются отдельно UI клиенты. Я по итогу выбрал neovim-qt
  2. Производительность Lua. Чуть хуже, чем JavaScript, но сильно лучше EmacsLisp. Впрочем, про производительность UI на относительно больших файлах будет ниже оговорка.
  3. Fennel - Lisp, работающий на Lua прекрасен. Это дает в чем-то схожий флоу конфигурации, что и в Emacs, когда поведение меняется на лету (см. подробнее: conjure)
  4. Сопоставимая с Emacs экосистема. Например, Magit (для Emacs), Edamagit (для VSCode) и NeoGit (для NeoVim) работают почти одинаково.

Минусы:

  1. Модальность. Для кого-то это плюс, я ее не люблю. Я настраивал конфигурацию без модальности. Но тут периодически натыкаешься на ограничение возможностей Vim по тонкой настройке.
  2. Менее удобная работа с Fennel, чем то, что предоставляет Emacs для EmacsLisp. На самом деле, они, конечно, не сопоставимы. Т.е. NeoVim не может быть такой же удобной IDE для Fennel как Emacs для EmacsLisp, уже по причине невозможности такой же интроспекции.
  3. Довольно причудливый API, многие вещи прибиты гвоздями еще со времен царя-гороха. Например, для некоторой функциональности нет полноценных функций, которые можно было бы вызвать через API, есть только хоткеи, т.е. приходится эмулировать их нажатие для вызова этих функций. Ситуация прежде всего в NeoVim постепенно меняется к лучшему, но до API Emacs пропасть неизмеримых размеров.

Но вот то, что реально заставило меня отказаться от пути использовать NeoVim и планомерно конфигурировать его в соответствии со своими предпочтениями, это то, что на больших файлах он стал повисать прям конкретно на десятки секунд. В Neovim Qt это очень сильно сказывалось. В Neovide лучше, но там нет антиалиасинга. А хотелось бы. В консольной версии аналогично. Отключил все плагины - ситуация не сильно поменялась. И максимальным шоком стало то, что Emacs с этим файлом спокойно работал. Подвисал, да, но на доли секунд.

Про Lapce и Helix, наверное, пока говорить рано, они довольно экспериментальные еще.

В общем, лучше Emacs пока никто ничего не придумал, хотя есть интересные попытки.



Последнее исправление: Kostafey (всего исправлений: 2)

Ответ на: комментарий от Nervous

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

Какого именно лиспа-то? Потому что основа лиспа – лямбда-исчисление. Говорить, что в любой программе используется лямбда-исчисление – тавтология.

Алсо, в оригинале было «в любой нетривиальной компьютерной системе», а не программе. Но лисперы не знают разницы, они даже синтаксис изобрести-то не осилили.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Какого именно лиспа-то?

Ты ещё про версию фортрана спроси из первой притчи.

синтаксис изобрести-то не осилили

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

Так что не надо завидовать, язву заработаешь. Лучше переходи на светлую сторону %)

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Ответ на: комментарий от Nervous

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

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

Так что не надо завидовать, язву заработаешь. Лучше переходи на светлую сторону %)

Зачем? Я давно с лишпа свалил.

hateyoufeel ★★★★★
()
Ответ на: комментарий от Nervous

потом у тебя в проекте на лишпе помойка из десятка разных синтаксисов

На то есть тимлид и его верная бамбуковая палка.

Ахахахахахахах! Ты ещё скажи, что на лишпе сейчас кто-то кроме одиночек-задротов пишет.

hateyoufeel ★★★★★
()
Ответ на: комментарий от seiken

мышь как таковая есть стремление не учить мимокрокодилов

возможен ли полноценный интерфейс как сочетание repl и кликов - да - при наличии двух фокусов - когда текстовый ввод не снимает мышиный выбор - но для мимокрокодилов это СЛОЖНААА

по итогу

интерфейс окозался реальне между чемто-то

ибо до сих пор то что GUI в целом так и не стало полноценным графическим интерфейсом - ибо атавизмы «эмуляции графичности» унаследованны от предшествующих реализаций через пользовательские навыки «наведи и ткни»

qulinxao3 ★☆
()
Ответ на: комментарий от hateyoufeel

А, понял про что речь, не сразу нашел Ответы для темы «Почему Go это плохо....»

Логика автора понятна, мол все, кроме CL не лисп. Наверное я чего-то не понимаю, т.к. как раз писал на всем вышеперечисленном (Emacs Lisp, Clojure, Racket), кроме CL (если не считать конфигурирование StumpWM). Как доберусь до CL, можно будет обсудить.

Kostafey
() автор топика

А еще помните было такое Климакс или как-то так. В некотором роде ё-макс на коммон лиспе – народ бился. Не знаю как там дела сейчас. Были еще неплохая штука на мотиве Nedit или что-такое. К сожалению с силу разных проблем с лицензией и отсутствии поддержки UTF-8 дело тускло смотрится сейчас.

kristall ★★
()

Не знаю как возможность переименовать файл через клавишосочетание может перекрыть более качественные плагины для VSCode, и просто потрясающую производительность по сравнению с Emacs.

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

И то, VSCode лишь продвинутый редактор, с IDE ничего из перечисленного не сравнится.

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от Shadow

Зачем 60 fps в редакторе кода?

Редакторы с 60 fps ненужны, должна быть поддержка 270гц как на моем мониторе, я специально такой купил что бы плавно прокручивать текст.

MOPKOBKA ★★★★
()
Ответ на: комментарий от seiken

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

MOPKOBKA ★★★★
()

К вопросу о «планомерно конфигурировать его в соответствии со своими предпочтениями»: neovim позволяет использовать комбинации клавиш типа Ctrl+Shift+J? (Vim не видит разницы между Ctrl+Shift+J, Ctrl+J, и, кажется, не видит разницы между Ctrl+J и Enter.)

debugger ★★★★★
()
Последнее исправление: debugger (всего исправлений: 1)
Ответ на: комментарий от Kostafey

я хочу просто: M-x renfibu [RET] (rename-file-of-buffer). Все.

Осталось сущая малость: запомнить эту команду. И еще около тысячи на все случаи жизни. Вот тогда можно начинать пользоваться редактором.

Xintrea ★★★★★
()
Ответ на: комментарий от MOPKOBKA

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

Адепты vi не способны это понять. Они воспринимают режимность vi как манну небесную, а когнитивную нагрузку на слежение за контекстом режима - легкой постоянной тренировкой мозга в паре с запоминанием команд.

Я таким редактором пользовался еще на Радио-86РК/Микроше, у которых было 32Кб оперативки. И прекрасно понимал почему редактор, у которого размер байткода 2Кб, работает именно так. Вот, пожалуйста, документация:

Комплект программ «Редактор и Ассемблер» для ПЭВМ «Микроша»

Можно обратить внимание как раз на два режима, как и в vi: Режим набора и Режим редактирования. Плюс клавиатурные команды которые надо запомнить, никакого тебе меню или F-строки. Да, команд немного, я их все знал наизусть. Правда забывал, если на пару месяцев к бабушке уезжал, потом приходилось заново вспоминать. Очень человекоориентированно.

Поэтому когда начал работать с DOS и его редакторами в Norton, DosNavigator, а потом и в MultiEdit, я просто наслаждался от того, насколько в них все ориентированно на пользователя. Вот тебе менюшечка, вот тебе F-строка, вот тебе подсказки по горячим клавишам, вот тебе выделение блока, а если хочешь - вот вертикальное, вот тебе встроенный хелп, который (о, чудо!) понятно как вызвать.

А потом, когда начал линухом заниматься, и сразу наткнулся на vi, первой мыслью было: да они совсем кукухой поехали? Нафига это днище еще как-то развивать, допиливать? Понятно, что изначальная структура была продиктована жесткими ограничениями на обычную память и текстовую видеопамять. Да, были времена. Но теперь-то у пользователя DOS минимум 640Кб, а на серверах с Linux мегабайты ОЗУ. Нахрена тратить время на vi копролит мамонта? Сила привычки? Потому что так диды завещали?

Где вменяемый консольный текстовый редактор под *NIX/Linux? Почему тридцать лет назад в DOS смогли, а в юниксах до сих пор пишут дичайшую дичь?

Xintrea ★★★★★
()
Ответ на: комментарий от Xintrea

Осталось сущая малость: запомнить эту команду. И еще около тысячи на все случаи жизни. Вот тогда можно начинать пользоваться редактором.

Да нет, в том-то и дело, что запоминать нужно только самые часто используемые клавиатурные сочетания. А более редко используемые вызываются через команды. Т.е. нужно просто вводить то, что необходимо сделать. В даном случае, rename file of current buffer, далее система подсказок и автодополнений поможет.

Kostafey
() автор топика
Ответ на: комментарий от MOPKOBKA

Добавлю.

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

А есть твоя функция rename-file в 5 строк из Emacs.

Но если ты переименуешь файл через IDE, то она найдет все использования этого файла, заменит пути, заменит namespace если в языке он формируется через файловую систему, вызовет git mv, итд.

Вызвать функцию может быть удобнее, но времени в Emacs потратишь больше, с ручной заменой всех упоминаний файла по старому пути.

Хорошо иметь лучшее из обоих миров, но в Emacs за полвека не сделали то что есть в современной IDE, сомнительно что сделают позже.

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от Shadow

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

Еще в браузере нормальный движок для рисования фигур и текста, а у Gtk и Qt по умолчанию всякий тормоз идет, в Gtk4 вообще не смогли сделать что то работающее, у меня через приложение все плывет.

MOPKOBKA ★★★★
()
Ответ на: комментарий от Kostafey

нужно просто вводить то, что необходимо сделать. В даном случае, rename file of current buffer

А почему не switch file name for actual working buffer? Почему ты думаешь, что каждому придут на ум именно твои слова?

Xintrea ★★★★★
()
Ответ на: комментарий от MOPKOBKA

нормальный движок для рисования фигур и текста

pango или skia

Shadow ★★★★★
()
Ответ на: комментарий от Xintrea

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

В крайнем случае, загуглить и узнать имя команды, если пользуешься ей первый раз (или крайне редко, не каждый год). Потом скопировать просто название этой команды и вставить в M-x. Но это всяко удобнее (мне), чем продираться через цепочки всплывающих подменю из панели управления. Типа, откройте меню (скришот), редактирование (скришот), параметры (скришот), прочее (скришот), дополнительные настройки (скришот)…, и т.д. и т.п.

Kostafey
() автор топика
Ответ на: комментарий от MOPKOBKA

Но если ты переименуешь файл через IDE, то она найдет все использования этого файла, заменит пути, заменит namespace если в языке он формируется через файловую систему, вызовет git mv, итд.

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

Kostafey
() автор топика
Ответ на: комментарий от Kostafey

Как вариант - добавить алиас

Зашибись решение. Вместо команд надо запоминать алиас. Это, конечно же, гораздо проще!

Xintrea ★★★★★
()
Ответ на: комментарий от Kostafey

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

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от Shadow

1. консольный emacs
2. joe
обоим куча лет.

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

И бедный пользователь должен в графическом DE делать так, а в emacs/joe - эдак. Очень удобно

Xintrea ★★★★★
()
Ответ на: комментарий от MOPKOBKA

более качественные плагины для VSCode

Не всегда. Иной раз для Emacs плагин лучше. Более того, то, о чем я говорил, если что-то в плагине сломается, есть уверенность, что сможешь починить сам, про плагин для VSCode у меня нет уверенности, что я смогу это починить за время, когда это имеет смысл.

Причем, это непридуманная история. Такое реально случалось. Приходишь такой утром на работу с крынкой горячего кофе. Нажимаешь обновить плагины в Emacs, получаешь неконсистентную систему. Пока допиваешь кофе - находишь багу в ELisp, самым топорным способом его фиксишь, добавляешь issue на github плагина. Кофе допито, среда разработки в порядке.

Приходишь такой утром на работу с крынкой горячего кофе. Нажимаешь обновить плагины в VSCode, получаешь неконсистентную систему. Открываешь код плагина… Грустишь. Постишь багрепорт. Закрываешь VSCode. Открываешь Emacs.

и просто потрясающую производительность по сравнению с Emacs.

Да, с этим никто не спорит. Но это приемлемый trade-off.

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

Автодополнение через LSP ничем не уступает. Отладкой я редко пользуюсь.

И то, VSCode лишь продвинутый редактор, с IDE ничего из перечисленного не сравнится.

Но при этом IDE как редакторам до Emacs далеко.

Kostafey
() автор топика
Ответ на: комментарий от Kostafey

Приходишь такой утром на работу с крынкой горячего кофе. Нажимаешь обновить плагины в VSCode, получаешь неконсистентную систему.

Install another version и устанавливаешь любую предыдущую версию, которая когда-либо выходила.

MoldAndLimeHoney
()
Ответ на: комментарий от MoldAndLimeHoney

Install another version и устанавливаешь любую предыдущую версию, которая когда-либо выходила.

Ну естественно, де-факто, я так и сделал :). Но если так рассказывать, история будет не такая красивая. Да, просто откатился на прошлую версию. Но при этом понял, что надо бы возвращаться в Emacs.

Kostafey
() автор топика
Ответ на: комментарий от MoldAndLimeHoney

Почему? Например, Calva пилят более-менее активно 1-2 человека (причем, скорее 1). Если он в какой-то мемент не сможет ее поддерживать, что дальше? Кто сможет в это влезть?

Kostafey
() автор топика
Последнее исправление: Kostafey (всего исправлений: 1)
Ответ на: комментарий от Kostafey

Откуда я знаю, если проект кому-то нужен, наверное кто-то подхватит.

Вопрос-то был не в этом. Вопрос был в том что делать, если плагин VSCode вдруг сломается. И в VSCode этот вопрос решен идеально – берешь и откатываешься на предыдущую версию.

Как откатить плагин в Имаксе? То, что ты быстро нашел ошибку – это, конечно, хорошо. Но так может быть не всегда, и на это можно потратить целый день. Задача-то у тебя не плагины исправлять, а делать что-то полезное.

MoldAndLimeHoney
()
Последнее исправление: MoldAndLimeHoney (всего исправлений: 1)
Ответ на: комментарий от MoldAndLimeHoney

Как откатить плагин в Имаксе?

Способов несколько. Например, установить версию из MELPA Stable, если ранее использовалась из MELPA. Или просто выкачать гитом состояние на нужный коммит. Благо добавить плагин руками в Emacs проще простого. В VSCode для это используется специально обученная магия и руками такое сделать сложнее.

Kostafey
() автор топика
Ответ на: комментарий от Kostafey

Главная проблема эклипса - плагины на java. На старой классической джаве, где объявлений классов больше, чем алгоритмического кода.

Shadow ★★★★★
()
Ответ на: комментарий от Kostafey

Причем, это непридуманная история. Такое реально случалось.

Откатись на старую версию?

Автодополнение через LSP ничем не уступает. Отладкой я редко пользуюсь.

LSP убогий протокол, и самые приемлемые LSP-серверы требуют допила клиента обычно.

Но при этом IDE как редакторам до Emacs далеко.

Да вроде наоборот, в emacs уже есть мультикурсор хотя бы?

MOPKOBKA ★★★★
()
Ответ на: комментарий от MoldAndLimeHoney

Зачем это делать руками, если изначально сделано по-человечески?

Тут даже дело не столько в привычке использования Emacs, но еще и здравый смысл подказывает, что коль скоро плагин написан на скриптовом языке, нужно скопировать его код в специально обученную папочку и написать в некотором файлике «загрузи мне из этой папки плагин». Разве нет?

Kostafey
() автор топика
Последнее исправление: Kostafey (всего исправлений: 1)
Ответ на: комментарий от MoldAndLimeHoney

Как откатить плагин в Имаксе?

С помощью пакетного менеджера же. Если пакетами управляет straight, который просто клонирует репозитории пакетов локально и загружает кот оттуда —вообще элементарно, просто идёшь в нужный локальный репо (можно сделать закладку) и переключаешься на нужный коммит/ветку любым удобным способом (конечно, магит, что за глупые вопросы).

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)