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)

VSCode и саблайм — для повседнева.
VIM — для редактирования одного (иногда двух) конфига на сервере.
Емакс — чтобы говорить о нём.

Exmor_RS ★★★
()
Последнее исправление: Exmor_RS (всего исправлений: 1)

Простите, как html канвас может быть производительным ui, если на него дофига разного контекста тратится? 2d примитивы всегда будут быстрее.

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

Простите, как html канвас может быть производительным ui, если на него дофига разного контекста тратится? 2d примитивы всегда будут быстрее.

Это ты про emacs или про vscode? Потому что с новым гуем emacs на gtk3 считай не сильно далеко от этого самого html canvas, потому что css там уже во все поля.

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

Да все равно сначала отрисовка, потом коррекция на css или что там у них... Лагает и мигает. Понятно, что прибитые гвоздями контролы ушли в прошлое, но бесит.

И что там отрисовывать на gpu? По идее, только один буфер да аппаратный аналог спрайтов для 2d. Не лучи же с туманом...

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

Про vscode.

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

Но ТС прав. У VSCode бардак с плагинами и отсутствие культуры разработки в них. Хуже того, часто возникает ситуация, когда ты ставишь бесплатный плагин, а через две-три версии он начинает сыпать рекламой и предлагать купить расширенную версию с большим количеством фич. Реально бесит.

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

Зачем 60 fps в редакторе кода? Там другие фичи на первом месте должны быть.

Я сейчас пытаюсь в свободное время eclipse che/theia освоить - потому что пользоваться vscode невозможно. Но надо много собирать и допиливать...

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

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

Чтобы у тебя прокрутка и отрисовка не лагали. Лаг при печати вообще очень бесит, не находишь?

Там другие фичи на первом месте должны быть.

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

Я сейчас пытаюсь в свободное время eclipse che/theia освоить - потому что пользоваться vscode невозможно.

Эта срань ещё жива? Я помню Eclipse только как базу для всяких специализированных IDE от хардварных вендоров, но это такие срань и жопа что лучше обходить стороной.

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

Там все офигенно: то, что на джаве, сильно развилось, но много платных годных плагинов; а ещё они взяли vscode и засунули его внутрь нормальной ide на js. Это и есть theia.

Ну и svt сильно быстрее того, что в IDEA.

Но в редакторах буфер всё ещё не используется, гигантский файл не открыть.

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

Там все офигенно: то, что на джаве, сильно развилось, но много платных годных плагинов; а ещё они взяли vscode и засунули его внутрь нормальной ide на js. Это и есть theia.

Это всё круто, но для разработки чего именно это будет лучше emacs или vscode?

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

Я хз, мне легче код на питоне и sql в проекте в эклипсе пилить, чем в vscode. А емакс я не осилил

С нативного емакса я убежал после пары лет. А вот Doom Emacs, да ещё и с Evil – это прямо офигенно. Можно сказать, Emacs – это лучший Vim чем сам Vim.

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

VIM — для редактирования одного (иногда двух) конфига на сервере.

Вам божественный tramp-mode дарован, а вы всё вот такой фигнёй страдать пытаетесь.

ugoday ★★★★★
()

Хотите переименовать текущий файл? Вам нужен плагин для этого! В Emacs это была бы просто небольшая функция - кинул в конфиг и всего делов.

Т.е. в Имаксе тоже нет и нужно писать расширение для этого.

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

Вот поэтому люди и пользуются IDE и VSCode: это «подправить» никогда не заканчивается.

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

кейс почти совпадает, +vim как редактор базы данных db2 гигами мерится правлю, знаю что не прав, но если можно то почему нет?

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

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

Вот поэтому люди и пользуются IDE и VSCode: это «подправить» никогда не заканчивается.

Как показывает практика, в IDE с функциональностью всё ещё хуже. Поэтому они и сосут, наверное.

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

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

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

но это такие срань и жопа что лучше обходить стороной.

Все из мира java попадает под это определение, но к сожалению не всегда есть альтернативы.

James_Holden ★★★★
()

Хотите переименовать текущий файл? Вам нужен плагин для этого!

Не понял… F2 на файле в експлорере и переименовывай. Не без мыши, конечно, но и без плагина.

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

Не понял… F2 на файле в експлорере и переименовывай. Не без мыши, конечно, но и без плагина.

Вот я редактирую файл и понимаю, что его нужно переименовать. Я не хочу открывать експлорере или что-то еще, искать файл там, я хочу просто:

M-x renfibu [RET] (rename-file-of-buffer). Все. Это можно сделать и в Emacs, и в VSCode, и в NeoVim. Вопрос удобства.

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

Хотите переименовать текущий файл? Вам нужен плагин для этого!

Для этого есть шорткат renameFile, просто по умолчанию он не работает когда текстовый редактор в фокусе (потому что F2 там используется для другого), но это все настраивается если что.

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

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

То ли дело копипаста говна с рандомных форумов и списков рассылки в init.el! Так держать!

на языке с нулевым порогом вхождения

Ну хер знает, я вот этот ваш JS не осилил.

Все из мира java попадает под это определение, но к сожалению не всегда есть альтернативы.

Поэтому Java надо выкинуть на мороз и закопать.

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

Ну хер знает, я вот этот ваш JS не осилил.

Видимо ты просто не хотел.

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

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

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

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

James_Holden ★★★★
()

Spring, Java, OutOfMemoryError, Restart… and Spring.

Не keyboard-centric. Некоторые вещи вообще без мыши не сделать, что раздражает.

Есть расширения для любителей 100500 сочетаний клавиш запоминать https://github.com/VSCodeVim/Vim

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

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

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

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

а не плевать ли на это?

на сотни мегабайтов жопаскрипта, который там нах не нужен? нет.

там и так после каждого твоего захода куча мусора появляется

счленали?

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

ну тот же вим своп файлы создает, а еще в .viminfo срет, многие утилиты создают всякие index.phpr и тп, локфайлы, километровые логи с десятками мегабайт в час

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

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

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

ну по факту любая твоя детятельность за рабочий день сгенерирует гигабайты мусора (вспомогательных и тп файлов), и единоразовое создание папочки .vscode-server с расширениями на фоне того что ты генерируешь (хаоса, флуктаций в электромагнитном поле, нарушающих целостность пространственно-временного континуума) - ничто

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

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

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

Там слабая типизация с кучей говна. Абсолютно днищенский язык, в котором прострелить себе колено проще чем в C. Что угодно лучше чем JavaScript. Даже днищепистон лучше чем JavaScript.

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

ну по факту любая твоя детятельность за рабочий день сгенерирует гигабайты мусора (вспомогательных и тп файлов)…

На локальной машине это нормально, на ssh хостах это непростительная дичь и создает проблемы. Там часто бывает счет места на отдельные гигабайты, так еще и любителей зайти по ssh через vscode бывает несколько.

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

Емакс — чтобы говорить о нём.

Подавился чаем.

sparkie ★★★★★
()

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

Так во всём софте. Раньше он был меньше и проще, а теперь больше и сложнее. Чем сложнее софт, тем больше надо знать, чтобы его дополнить.

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

Что угодно лучше чем JavaScript. Даже днищепистон лучше чем JavaScript.

у отступо-фобов уже повышается внутречерепное давление…

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

Есть расширения для любителей 100500 сочетаний клавиш запоминать https://github.com/VSCodeVim/Vim

Во-первых, я не люблю модальность, но, да, это вкусовщина. Во-вторых, я не хочу 100500 сочетаний клавиш запоминать, я хочу их сам придумывать и назначать им те задачи, которые решаю, т.е. мне нужен не готовый мага комбайн, а конструктор. В-третьих, тот факт, что кто-то добавил 100500 сочетаний клавиш не делает VS Code keyboard-centric. Там как была логика необходимости использования мыши для конфигурирования и работе с панелями, так и остается. Но я не спорю, кому-то VSCodeVim зайдет.

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

Так во всём софте. Раньше он был меньше и проще, а теперь больше и сложнее. Чем сложнее софт, тем больше надо знать, чтобы его дополнить.

Тут речь немного про другое. Представьте себе, что вы используете некий плагин в своей работе и на ходу дорабатываете собственно этот плагин. Делать это одновременно, скажем, для Eclipse представляется весьма затруднительным. Или мы занимаемся доработкой плагина, или пользуемся им. В Emacs же без проблем.

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

Именно потому что emacs и vi пришли из тех времен, когда аппаратных ресурсов было меньше, софт был проще, а некоторые вещи существовали в зачаточном состянии (GUI, мышка), и нердам были не особо нужны. А Eclipse уже современная система. Соответственно и разделение труда в сфере ИТ тогда было меньше, и человек мог одновременно и пилить редактор, и писать код своего приложения.

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

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

Exmor_RS ★★★
()
Последнее исправление: Exmor_RS (всего исправлений: 1)

Есть 3 типа программ..

1 тип — программа дана как есть, можно только нажимать кнопки гуя и всё.

2 тип — разработчики решают что они «знают» как лучше. Взаимодействие модулей в программе происходит по жёстко заданному интерфейсу. Если пользовательское расширение попадает в «русло», то всё нормально. Но если надо сделать что-то нестандартное — расширения получаются куцыми.
При этом разработчики «стабильного АПИ» постоянно его меняют, т.к. оно не позволяет реализовать какую-то задумку, но сама концепция не меняется. Старые расширения отваливаются, новые могут работать по-другому.

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

Большинство программ являются программами 1 типа. Потом идёт 2й тип.
Ну и к сожалению программ 3его типа очень мало.

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

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

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

3 тип — разработчики предусматривают расширяемость, предусматривают что пользователь может захотеть получать информацию о работе программы, переопределять поведение

Короче говоря, есть программы на лиспе и все остальные.

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

Eclipse уже современная система

Есть на его платформе довольно неплохие вещи. Но вообще визиторы стратегий абстрактных фабрик — это немного стимпанк уже.

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

Не, нету

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

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

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