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.» и все такие: «Привет, Костя». :))))))))

★

Последнее исправление: Kostafey (всего исправлений: 2)
Ответ на: комментарий от 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 ★
() автор топика
Ответ на: комментарий от Vovka-Korovka

Neovim-qt. Самый адекватный.

Спасибо, попробую.

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

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

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

Если конкретно kitty/alacritty.

Я правильно понимаю, что это дефолтный Neovim, не требующий дополнительного UI?

Kostafey ★
() автор топика
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от Kostafey

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

terminal multiplexer ака screen или tmux?

habamax ★★★
()
Ответ на: комментарий от 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 ★★★★★
()
Вы не можете добавлять комментарии в эту тему: топик перемещен в архив.