Че там вкусного?

xref, поддержка модулей в форме загружаемых библиотек, поддержка Cairo, Xwidgets, map.el & seq.el.

асинхронность полноценную не завезли

В следующем релизе будет. Но я уже писал, там GIL.

про параллелизм молчу

Его не планируют. Тот же Эли боится, что это слишком сложно и всё сломается. Видимо, придестя по старинке - процессами. Благо в emacs ими удобно манипулировать.

Редактор в техническом плане отстал очень сильно от всяких саблаймов.

На меня сейчас наверняка накинутся, но я в определенный момент времени понял, что текстовый редактор для программиста вполне логично делать на браузерном движке (bleeding edge технологий для интерактивной работы с текстом и другой информацией). И atom тут смотрится очень хорошо. Но качество (и иногда количество) пакетов (возможно, пока) хромает и писать расширения на js меня совсем не прельщает. Поэтому я остаюсь на emacs.

поддержка Cairo, Xwidgets

Ну как всегда, все, кроме текстового редактора.

На кой мне Cairo, если само окно — не опенгл?

Его не планируют. Тот же Эли

Да Этот Эли вообще упоротый какой-то явно (reddit его доставляет). Правильно делают, что форкают.

браузерном движке

Правильно, даешь elisp интерпретатор на жабаскрипте. А то как-то слабо имакс стал тормозить.

Как перепишут — пишите. Анонсы форков без результата не имеют смысла

удачи, хули.

Правильно делают, что форкают.

сколько ныне живых форков gnu/emacs ?

заипали

Не лисп, вот ты и бесишься.

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

Коммон Лисп не Коммон Лисп, но на Guile переводить планировали, ЕМНИП.

Java

Очевидно же, что единственная современная платформа для емакса - это Java. Они созданы друг для друга.

https://www.emacswiki.org/emacs/GuileEmacs

Climacs вроде пилят потихоньку.

Было уже. Jemacs так и не допилили. Хотя в жабной инфраструктуре есть вещи, которые могли бы пригодиться, antlr4 например. Но я его и к gnu/emacs могу прикрутить.

Без совместимости с elisp он не нужен.

Тоже самое, что было в сраче между ffmpeg и libav.
Ещё пачечка подобных случаев, и можно будет с чистой совестью объявить закономерностью.

В следующем релизе будет.

Где читаешь roadmap?

И встроить его в openJDK, намертво.

На реддите мэйнтейнеры отписываются.

О, спасибо.

and to better integrate ELPA into the distribution process

Эль-гет бы туда ещё в стандартную поставку, будет счастье.

Кстати, это отличная идея, если Оракл даст на это денег. Меня задолбало то, что в JDK нет нормального проекта IDE для самих исходников JDK. И если даже его понадабавлять в какую-нибудь Идею или Эклипсу, они не знают о новых фичах и красят всё красным

Вся сущность тредов на ЛОРе с упоминанием Rust/Go/D/Swift:

Хипстеры? Хипстеры! Хипстерство! Хипстерята-хипстеряточки!

Ненужно!

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

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

Не очень понимаю, чем атом или саблайм лучше классических редакторов

динамичностью, интерактивностью. Например, отрендерить и показать на месте markdown, latex или веб-страницу. Или добавить кастомный элемент управления. Многое в емаксе делается, но костылями. Кроме того, в современных движках нормальная конкурентность что важно для всяких асинхронных плагинов. Лисп машина же на данный момент однопоточна. С введением новой конкурентности мало что изменится - параллельности не будет из-за GIL. Вернее, она и сейчас есть, но костылями.

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

Не обязательно. Там обычно есть плагин vim-like и собственные комбинации. Ну и, например, мултикурсоры первыми появились то ли в сублайме, то ли в атоме.

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

Тут согласен. И это действительно фундаментальная проблема. Жаль только, что таким переписыванием «в лоб» её не решить.

Пардон, а что имеется в виду? Что именно мигает?

имеется ввиду содержимое display.c

Даже грядущий в emacs 26 pixel-scroll-mode всё равно не достаточно плавный. А всё дело в том, что поддерживается очень много графических бэкэндев (устаревших, эзотерических и современных).

А все-таки, что мигает?

Я видел только, как мигают GTK’шные рюшечки. Но это должен быть баг в GTK 3.22 (что ли). Без них, с чистыми Иксами (вариант: с GTK 2, с Lucid’ом), что-то мигает?

Когда тема переключается и куча hook-ов отрабатывают одновременно, мигает всё

Зы. сипользую сборку с lucid.