LINUX.ORG.RU
ФорумTalks

Жизнь после Emacs

 , , , ,


2

3

Краткое содержание предыдущих серий: 12 лет на Emacs.

Нынешняя ситуация: использовал Emacs для работы со Scala (через lsp-сервер Metals). Проблема известная - подвисание UI. Большую часть lsp-ui я уже отключил, стало возможно как-то работать, но все же буквы появляются из-под клавиш весьма не спеша… Частично решается только апгрейдом железа.

Есть попытки как-то решить проблему - прикрутить Webrender использующий GPU, но пока в очень экспериментальном виде:

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

Сразу ремарка по поводу Neovim: насколько я понял, реактивный UI они сделали, но я не люблю режимы. Идея повесить все хоткеи на один режим и расширять редактор в Lua была, но насколько это будет натурально: использование Vim-а без режимов?

Light Table, насколько я понял, более-менее заброшен. Впрочем, с их подходом Data-driven configuration, они могли использовать для конфигурации условный FortranJS вместо ClojureScript (надеюсь, понятно почему :)).

Собственно к VSCode. В продолжении тем:

Вот, например, по первой ссылке автор испытывает только положительные чувства от смены Emacs на VSCode. У меня это такого дикого и безоговорочного энтузиазма не вызывает.

Да, конечно, проблемы рендеринга UI там нет как класса. V8 js engine сам по себе демонстрирует шикарную производительность, уже только он шустрее движка Elisp, UI в своем потоке, а главное он наконец-то рендерится GPU, а не CPU. Ок, замечательно, я переместился в будущее: из середины 70-х в наши дни.

Но проблема в том, что в нем нет… Emacs, нет REPL (и я сейчас не про этакую интерактивную командную строку говорю, а про то, что в Emacs все есть REPL - встаешь курсором (точкой) на любом куске кода, выполняешь его, получаешь результат и мгновенно меняешь поведение редактора). И нет s-выражений.

Взять конфигурацию. Вот я редактирую свою тему. Что-то поменял. В Emacs я просто исполняю файл с темой и все - все изменения мгновенно отображаются. Тут у нас что: https://stackoverflow.com/questions/44390765/vscode-how-to-reload-theme-after-editing-its-style Нужно перезагружать редактор? Да ладно? Вообще-то после Reload Window lsp-server тоже перезапускается, ага заново частично компилирует, индексирует.

Далее, хочу M-x function-name. Ну казалось бы, в VSCode такое точно есть. А вот и нет. Хочешь вызвать функцию - назначь ей или алиас или кейбиндинг: https://stackoverflow.com/questions/58382100/triggering-commands-by-their-command-id-or-a-custom-string-alias

Теперь что до файла конфига. Да, изменения в конфиге подхватываются на лету, но для случая симлинков (вот хочется мне конфигурацию в одном месте держать) это работает только если открыт симлинк, а не файл, а не на который он ссылается, а значит гитовый плагин не видит диффа. Ну ладно, допустим. А если у тебя открыто несколько… фреймов, хорошо, окон редактора, например для случая 2-х мониторов, то нужно в каждом открывать конфиг, типа «изменять» его и сохранять, чтобы изменения подхватились. Ну ладно, хоть что-то. Аналогично с темой.

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

К слову, пример плагина на ClojureScript внушает некоторый оптимизм на тему дальнейших возможностей расширений и кастомизаций «как в Emacs»: https://github.com/Saikyun/cljs-vscode-extension-hello-world Правда, насколько я понимаю, ClojureScript по-прежнему не может обойтись без Java, т.к. компиляция макросов происходит в JVM. Проект Lumo выглядит заброшенным. Альтернативы есть?

Вообще, я не сильно люблю статическое созерцание кода. Гораздо удобнее, когда код можно изменять на лету, вылепливая из него что-то как из пластилина и тут же получая результат. И речь не только о собственно конфигурации Emacs. На самом деле, в Emacs, я мог, например, в текстовом выхлопе какого-то генератора вертикально выделить столбик, скопировать его, поставить вверху и внизу скобочку, нажать C-x C-e и получить сумму:

(+ 23,32
-7,04
135,7
-15,22
8) => 144,76

Все. Никуда не выходя из Emacs. В VSCode что? Есть некий плагин eval. Судя по времени выполнения, он запускает nodejs всякий раз. Словом, к возможности тут же вычислить любой объект как код на Elisp привыкаешь очень сильно.

Смотрим на расширения. О культуре разработки, сложившейся в Emacs комьюнити я ужи писал на лоре, но на этот вопрос по прежнему не обращают внимания. Пакет Emacs для того попасть с MELPA проходит код ревью. В итоге, мы имеем докстринги к большинству функций, подробные readme. Да и даже без код ревью люди просто привыкли так писать, это уже стало хорошей традицией. Что в VSCode? Даже у некоторых более-менее популярных пакетов нет ни одного комментария, ни одной докстроки к функции в исходном коде. В менее популярныйх пакетах - спасибо, если есть readame, а от бывает и его нет.

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

P.P.S. Да, я понимаю, что весь мир не обязан быть Emacs-ом, но ведь люди уже переходили из Emacs и не вчера, наверняка эти проблемы уже как-то решились. Какие-то сушествуют решения, рекоммендации, комьюнити?

P.P.P.S Вот так и представляю себе группу психологической поддержки, тех кто ушел из Emacs. Захожу в комнату, там в форме круга расставлены стулья, на них сидят такие же бывшие емаксеры. Я говорю: «Привет, меня зовут Костя и я перестал пользоваться Emacs.» и все такие: «Привет, Костя». :))))))))

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

Да, конечно, на Идеях, Эклипсах и им подобных я много лет как пишу. Когда нужно «просто кодить», особенно, если рантайм как-то хитро завязан на IDE, чтобы аппу для вот этого веб-сервера со всеми конфигами можно было дебажить - там иной раз вариантов просто нет.

Вопрос не в этом. У меня триллион фичей для редактирования текста за несколько лет накопилось в Emacs. И это действительно удобно. Переносить это на IDEA будет еще сложнее. И что в итоге. Получается, существуют 2 изолированные среды: одна для работы, другая для фана. Они между собой мало пересекаются. А вот как их объединить?

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

Вот такие вот люди переходят с notepad’а на что-то не такое, как у всех, а потом ноют - им, видите ли, неудобно!

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

Вот такие вот люди переходят с notepad’а

В те времена когда я переходил с notepad’а, вариантов было не так много. Мой notepad (bred) перестал поддерживаться. А альтернатив было Geany/SciTE, Vim, да вот Emacs.

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

Зачем их объединять?

Для удобства редактирования текста (кода), удобства навигации и т.д. У меня реально есть в конфиге вещи, коротых в IDEA нет.

Kostafey ()

я снял свой старенький экзоскелет и взял вместо него каменный топор

Всё так.

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

Мой notepad (bred) перестал поддерживаться

Вот сперва таким людям поддержка(и, наверное, доработка) нужна - в идеальном инструменте-то, а потом, вместо божественной Visual Studio, начинают хватать всякое г… типа Vim да Emacs.

tiinn ★★★★ ()

а главное он наконец-то рендерится GPU

Ну, это заслуга не редактора, а хромиума)

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

Вот сперва таким людям поддержка(и, наверное, доработка) нужна - в идеальном инструменте-то, а потом, вместо божественной Visual Studio, начинают хватать всякое г… типа Vim да Emacs.

Что сперва? Emacs c 70-х годов существует. В 2007-2008, когда я на него переходил была Visual Studio по-моему 2005, она была заточена под C++,С# и вижуал барсик. А мне нужна была Java, периодически Python, а чуть позже Clojure. Редактирование Java кода в Eclipse/IBM Rational Developer на моем железе было похоже на просмотр диафильма. Тем более это не имело смысла для Python.

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

Нужен какой-то NeoEmacs.

Да, фактически это Remacs и Emacs-ng. Но там не слишком большое комьюнити разработчиков. Им бы, как-то на кикстартере что ли попробовать денег собрать.

Kostafey ()

Привет Костя! Использую mcedit, Vim и в последнее время иногда Geany и немного стыдился того, что не осилил Emacs. А тут вот оно как бывает.

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

Редактирование Java кода в Eclipse/IBM Rational Developer на моем железе было похоже на просмотр диафильма

Вот! Вот в этот момент всё было выбрано неправильно: и язык, и железо. И покатилась жизнь в Emacs…

Ладно, не принимайте близко к сердцу, я шучу. Понимаете, ваша боль - это всё равно что китаец сейчас объясняет прелесть иероглифов русскому: Иероглифы с 17 в. до н.э. существуют. Они более информативны, отсутствует проблема «это читается не так, как пишется» и пр…

Вы выросли в иной парадигме редактирования и программирования. Что делать, если 90% людей выросли в другой парадигме. Вам сейчас переучиваться - боль и страдания, а они вообще проблемы не видят. Как выше заметили, вам нужен NeoEmacs, а его не существует.

Я однажды где-то на форуме читал, там адепт какого-то редчайшего языка писал, что не видит ни смысла, ни преимуществ в C# и Java, ибо на том языке всё делается гораздо удобнее. Кроссплатформенно, СУБД-независимо и т.п. Проблема, что язык давно не поддерживается, во всём мире дай бог 1000 программистов на нём наберётся, всё в их конторе на этом языке написано - и вот как-то так.

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

Использую mcedit, Vim и в последнее время иногда Geany

Привет :). Vim пробовал примерно в то ж время (2007-2008). В конце-концов понял, что мне модальность несколько мешает. А значит, нужно все перевешивать на один режим, а значит нужен не Vim. Но по факту получилось, что Neovim ушел дальше.

Geany, SciTE, Notepad++ - все построены на основе Scintilla. В тот момент (2008) казалось, что SciTE действительно может развиваться дальше, и в итоге, обрасти системой расширений на Lua и JS, почти аналогично Vim и Emacs. По факту они потихоньку вытесняются VSCode, Atom и Sublime.

не осилил Emacs

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

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

это всё равно что китаец сейчас объясняет прелесть иероглифов русскому

Спасибо, да, все именно так :).

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

Переехал с емакса на неовим и горя не знаю.

Но при этом, у вас в процессе работы четко разделены командный режим и режим вставки? Насколько абсурдно сделать все в одном режиме?

Kostafey ()

Работая в Идее я часто копирую код в Emacs, редактирую его там и вставляю назад. В этих свистоперделках нет и не будет нормальных редакторов. Зато есть миллион никому ненужных функций. Ну или нужных, раз в год.

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

А так — https://github.com/neovim/neovim/wiki/Related-projects

Вот я на это и гляжу. А там столько всего, что и не знаешь за что хвататься :). При этом, часть abandoned, inactive и deprecated. Вроде как neovide выглядит хорошо и активно поддерживается.

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

Работая в Идее я часто копирую код в Emacs, редактирую его там и вставляю назад.

Аналогично :). Но все же, хочется однажды это в человеческий вид привести. И вот, казалось бы, появился lsp-server - это и есть то самое решение, но…

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

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

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

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

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

Понял, спасибо. Эмулятор терминала, судя по всему, мне тоже надо будет как-нибудь менять на что-то более современное. Пока пользуюсь urxvt.

Kostafey ()

Я пробовал IDEA, Eclipse, Visual Studio ещё кучу каких-то хреней. И всё же остаюсь на Emacs. Причём в емакс я пришёл с эклипса. Так что без вариантов, наверное. :(

turtle_bazon ★★★★★ ()

Я мучался с тем же и в итоге успокоился на:

  • выпилил из Emacs все LSP-фичи, оставив просто продвинутое редактирование с подсветкой и GIT
  • весь Emacs изначально настроен мной на Vim-bindings с helper-ом на базе leader и быстрыми маппингами на M-hjklyuio
  • в VS code включен vim-режим и те же самые биндинги повешены на leader-режимы и M-hjklyuio, там всё достаточно настраиваемо.
  • чего нет, с тем тупо примиряюсь и учу как оно принято в мире VS Code, попутно меняя маппинги на удобные мне по мнемонике.
  • Profit.

Переход бесшовный, в любой момент, ничего нигде у меня не горит и не отваливается. При этом 100500 удобств Emacs по-прежнему со мной в любой момент.

Допудобство: внезапно осознал что без боли правлю всякое на серверах и в манифестах через пустой неконфигурированный vim.

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

Если табы не нужны

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

Kostafey ()

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

Думаю, что если человек перешел с емакса, то ему и нужен был просто редактор, поэтому особых болей у него это не вызвало. Что касается тормозов, то они в VSCode есть, причем всегда. Какие-то микроподвисания при печати, раздумия при появлении попапов. Из обиходных редакторов и на вменяемых размерах файлов 10/10 за скорость морды я бы выдал только Sublime.

А профайлить в емаксе свои тормоза пробовал?

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

выпилил из Emacs все LSP-фичи, оставив просто продвинутое редактирование с подсветкой и GIT

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

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

А как без них-то?

tmux, например. Там даже управление удобнее можно сделать, но я все равно, почему-то, люблю гуевые табы:)

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

tmux, например.

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

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

При описанной мной настройке, когда мне это становится нужно я просто без боли всё делаю привычным образом сразу в VS Code. Кайф именно от бесшовности и отсутсвия необходимости постоянно что-то подпиливать в Emacs чтобы стало удобнее то, что в IDE есть изначально.

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

А профайлить в емаксе свои тормоза пробовал?

Нет, но они исчезают при отключении lsp. Стало быть проблема в нем, но без него Emacs теряет все преимущества IDE, оставаясь просто шикарным редактором. Думаю, если начать копать, там возможно добиться некоторого улучшения: что-то частично поотключать, где-то таймауты добавить, но все равно это не решает проблему того, что UI принципиально медленный.

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

Так это не UI, а коммуниция с LSP-сервером, скорее всего. В 27.1 вроде ее сильно улучшили за счет нативной поддержки json-парсинга. Также можешь попробовать собрать 28ю ветку с поддержкой native compilation - говорят еще дает хороший пинок в производительности.

У меня переход с дохлоинтеля на M1 разогнал запуск раза в 3, но какие-то бенчмарки специально я не делал.

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

eglot для lsp пробовал? Он у меня стабильнее и шустрее работал. Но там проблема, что его возможно придётся допиливать под сервер - у меня вот с clangd периодически отключается с ошибкой.

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

Так это не UI, а коммуниция с LSP-сервером, скорее всего.

Ну правильно. Сам сервер работает в отдельном потоке (и на том спасибо), а вот отправка сообщений туда и парсинг результатов происходит в том же потоке, что и UI.

В 27.1 вроде ее сильно улучшили за счет нативной поддержки json-парсинга.

Дак, да, на нем и сижу. Собственно, с Emacs 27.1 и стало возможно как-то более-менее нормально работать на Scala.

Также можешь попробовать собрать 28ю ветку с поддержкой native compilation - говорят еще дает хороший пинок в производительности.

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

У меня переход с дохлоинтеля на M1 разогнал запуск раза в 3, но какие-то бенчмарки специально я не делал.

Я правильно понимаю, для этого нужно макбук брать?

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

eglot для lsp пробовал

Пробовал когда-то. Что-то у меня там не взлетело… Не глубоко копал, если честно. Отпилить часть функционала lsp-ui оказалось проще. Опять же, надо понимать, что emacs-lsp - сам по себе уже в некоторой степени некоторая маргинальщина (ну чуть-чуть ближе к менстриму), будем честны, а уж eglot и подавно.

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

Я правильно понимаю, для этого нужно макбук брать?

Последние ноутбучные амудэ на single-thread такие же, если не лучшие, результаты вроде показывают.

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

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

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

Ну альтернатив LSP то сейчас в любом случае особо нет, MS умеет под себя подмять. CEDET сдох, tree-sitter заглох. А eglot просто пилит чувак под флагом FSF, без всяких arrow фреймворков, на нативном лиспе. Там проще код понять и допилить под себя. Возможно оно когда-то войдет в состав Emacs.

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