Проект GNU опубликовал (https://lists.gnu.org/archive/html/emacs-devel/2019-04/msg00...) релиз текстового редактора GNU Emacs 26.2 (http://www.gnu.org/software/emacs/). Вплоть до выпуска GNU Emacs 24.5 проект развивался под личным руководством Ричарда Столлмана, который передал (https://www.opennet.ru/opennews/art.shtml?num=43264) пост лидера проекта Джону Вигли (John Wiegley) осенью 2015 года.Из наиболее заметных улучшений (http://www.gnu.org/software/emacs/news/NEWS.26.2) можно отметить обеспечение совместимости со спецификацией Unicode 11, возможность сборки модулей Emacs вне дерева исходных текстов Emacs, появление в Dired (режим для работы с файлами и каталогами) команды 'Z' для сжатия всех файлов в каталоге, улучшение поддержки Mercurial в режиме VC.
При сборке в режиме '--with-xwidgets' теперь требуется наличие браузерного движка WebKit2. Изменён синтаксис shadow-файлов конфигурации ("~/.emacs.d/shadows" и "~/.emacs.d/shadow_todo").URL: https://lists.gnu.org/archive/html/emacs-devel/2019-04/msg00...
Новость: https://www.opennet.ru/opennews/art.shtml?num=50509
Ему-то вебкит зачем, интересно?..
Зачем операционной системе браузер? (Или, как альтернатива, можно пошутить про emacsd.)
Сложно сказать. Но меня последнее время не оставляет мысль: а что если вышвырнуть из emacs'а всё относящееся к X'ам и прочим gtk, вернутся к текстовому интерфейсу, но ncurses тоже выпилить, и подложить вместо него браузерный движок рендеринга. Фишка в том, что в теории это должно круто лечь на общую модель того, как emacs подходит к выводу: он не заботится о всяких там нубских ExposeEvent, и выводит не тогда, когда видеокарте удобно или когда оконный менагер решил, что неплохо было бы перерисовать окно, а тогда, когда emacs'у захочется. Сопряжение этого чуда с X'ами -- это такое костылестроение, которого не только лишь все, мало кто видел.Ну так вот, и если это сделать, то затем внезапно lisp'овому коду откроются широчайшие горизонты для того, чтобы рисовать любые элементы интерфейса, не вдаваясь при этом в во всякие там подробности и детали отрисовки. Не прибивая себя гвоздями к ограниченности какого-либо фреймворка, не связываясь с этим дурацким видением ООП из прошлого тысячелетия, легко и непринуждённо реализуя разные темы, переходя от elisp байткода к webassembly, выходя в онлайн и создавая EmacsCloud платформу, где я мог бы завести аккаунт, и работать в emacs'е со своими файлами из любого места с любого устройства... эххх... мечты-мечты...
Собственно я это к тому, что увидев про webkit2 я подумал, что мои мысли были услышаны, но... нет. xwidgets -- это про то, чтобы gtk-шные виджеты рисовать. Глупость короче, emacs как всегда лет на двадцать отстаёт от `date -d now`.
> широчайшие горизонты для того, чтобы рисовать любые элементы интерфейсаЧего конкретно вам не хватает-то?
> выходя в онлайн и создавая EmacsCloud платформу, где я мог бы завести аккаунт
RMS не одобряет эти ваши аккаунты. Слушайте дедушку, покудова жив.
> emacs как всегда лет на двадцать отстаёт от `date -d now`
Аллилуйя!
>> широчайшие горизонты для того, чтобы рисовать любые элементы интерфейса
> Чего конкретно вам не хватает-то?Мне хотелось бы такое красивое дерево сбоку от кода для навигации по нему, перемещение между файлами без границ. Текст файла не в виде простыни кода, а в виде отдельных топ-левел блоков, чтобы я их сворачивал разворачивал так, как мне хочется, и даже (о ужас) даже мышкой, если у меня половина рук занята чем-то посторонним. Это если навскидку.
>> выходя в онлайн и создавая EmacsCloud платформу, где я мог бы завести аккаунт
> RMS не одобряет эти ваши аккаунты. Слушайте дедушку, покудова жив.Он много чего не одобряет. А меня раздражают все эти преграды на пути программерской мысли.
А, ещё вместо кошмарного customize, открывающего буферы на каждый чих, что-нибудь нормальное. Хотя бы просто дерево-таблицу, где в левом столбце дерево категорий и индивидуальных настроек, а в остальных частях пояснения семантики опций и собственно поля для изменения их.И вместо временных буферов, которые открываются на автодополнение, что-нибудь всплывающее поверх.
Это из раздражающего. Можно ещё подумать на тему чего-нибудь в стиле выпадающего списка в минибуфере, чтобы предыдущие команды можно было бы использовать. Конфигурируемого тулбара, куда легко можно вытащить и повесить любой обработчик на elisp. Даже конфигурируемых тулбаров, как buffer local, так и глобальных, которые можно присобачить к любой границе окна/буфера, куда можно вешать элементы, чья отрисовка определяется моими скриптами и чьё взаимодействие с мышкой/клавиатурой определяется моими же скриптами. Скажем, мне хочется знать, сколько слов в строке с курсором -- я беру и добавляю на buffer-local тулбар элемент, и к нему скрипт отрисовки, который рисует его как <span style="border: 1px black">N</span> обновляя этот самый N после каждого движения нажатия клавиши и каждого перемещения курсора.
Ну да, и html и объекты DOM в синтаксисе s-expressions, чтобы бесшовная интеграция с лиспом:
`(span (:style (:border "1px" ,theme-foreground-color)) ,(word-count-in-current-line))
> И вместо временных буферов, которые открываются на автодополнение, что-нибудь всплывающее поверх.Что в принципе может более раздражать, чем "всплывающее поверх"?
>> И вместо временных буферов, которые открываются на автодополнение, что-нибудь всплывающее поверх.
> Что в принципе может более раздражать, чем "всплывающее поверх"?Возникающий ниоткуда буфер, который отъедает половину текущего буфера снизу, если курсор оказывался за краем буфера, то соответственно всё в буфере двигается так, чтобы после располовинивания, он остался бы в буфере и иногда после появления такого всплывающего буфера, сидишь, тупишь, пытаешься понять где на экране тот кусок кода, который вообще вызвал у меня желание лезть в минибуфер. Иногда при этом он уже и не на экране.
> Мне хотелось бы такое красивое дерево сбоку от кода для навигации по нему,ecb (layout left-analyse)
> И вместо временных буферов, которые открываются на автодополнение, что-нибудь всплывающее поверх.
company-mode (не помню бэкэнд, но с вспылающей менюшкой есть уже давно и как бы он сейчас не по умолчанию с ней шел)
https://company-mode.github.io/ (см. скрин)> Можно ещё подумать на тему чего-нибудь в стиле выпадающего
> списка в минибуфере, чтобы предыдущие команды можно было бы использовать.https://emacs-helm.github.io/helm/
https://emacs-helm.github.io/helm/images/helm-buffers-list.gifНо вообще, с мыслью из #3 о костыльности отрисовки в граф.моде согласен -- во многих местах шурупы, которыми прикручивали "современные" (т.е. еще конца прошлого века) возможности гуя через ГТК, торчат наружу в самых неожиданных местах.
> ecb (layout left-analyse)Что это? Про ecb написано, что это "An interface to the Eclipse IDE". Я думаю, что если я поставлю eclipse, то я не буду костылить и впихивать в него emacs. Или оно не требует установки eclipse?
> company-mode (не помню бэкэнд, но с вспылающей менюшкой есть уже давно и как бы он сейчас не по умолчанию с ней шел)
Да, круто. Спасибо.
> Но вообще, с мыслью из #3 о костыльности отрисовки в граф.моде согласен -- во многих местах шурупы, которыми прикручивали "современные" (т.е. еще конца прошлого века) возможности гуя через ГТК, торчат наружу в самых неожиданных местах.
Во, круто что это кто-то понимает. Тут публика слишком догматична, чтобы оценить идею отрисовки при помощи html/css. Некоторые тут считают даже (я видел в комментах), что css замедляет работу сайтов.
Но вообще, если несколько абстрагироваться от html/css в том виде, в котором они описаны на w3c, взять основную идею блочной разметки текста, то... Я сейчас подумываю о том, чтобы запилить эмулятор терминала, с esc-последовательностями изоморфными html. Чтобы можно было бы сделать, что-нибудь в стиле:
printf("\eu<Глянь\e>, это \ei<курсив\e>, а это \eb<жирный\e>\n")или
printf("\ediv{id: menu}<\e>");
printf("\estyle{#menu {width: 100%; position: fixed; left: 0px; top: 0px; background: grey;}}");
// и теперь menuitem
printf("\estyle{.menuitem {color: black; margin-left: 1em; margin-right: 1em;}}");
printf("\eadd_child($id, span{id: file; class: menuitem}<File>)");
printf("\eadd_cb($file, {onclick})");А затем:
if scanf("\e$file.onclick(%d, %d)", &x, &y) == 2 {
printf("File clicked with mouse coords: (%d, %d)", x, y);
}
Ну или типа того. Я не продумал ещё в деталях весь этот протокол общения между терминалом и приложением. Но фишка в том, что его можно сделать недвусмысленным, дать возможность добавлять/изменять/удалять элементы. Выкидывать в помойку элементы уползающие за край терминала (или может выкидывать их не сразу, или не все, и иметь некое хранилище для созданных но неотображаемых элементов, типа видеопамяти, где можно хранить кучу всякой всячины, рисуя при этом лишь какой-то кусок её). Что-то с css тоже надо сделать, чтобы их можно было бы прочищать. Было бы прикольно привязать хранилище тегов и правил css к процессу, чтобы когда процесс помер, можно было бы зачистить выборочно "видеопамять". Можно ascii представление заменить на бинарное -- это может сэкономить ресурсов, но прибъёт читабельность глазами. Что может быть и не важно, потому что даже в таком виде оно не очень удобно, и по-любому поверх надо наворачивать API для ввода/вывода этих esc-последовательностей. Но тогда со скриптовыми языками начнутся проблемы -- не все скриптовые языки умеют работать с бинарными данными, и некоторым придётся писать модули на C, чтобы получить доступ к этим возможностям терминала.ncurses не нужен при таком подходе. DOM может хранится на стороне терминала, и общение с ним обеспечивать посредством протокола -- это, правда, может замедлять в некоторых случаях, но если библиотечку для управления DOM терминала сделать именно библиотечкой, то ничто не помешает поверх неё написать client-side обёртку, чтобы проводить ввод/вывод через неё, и иметь идентичную копию DOM на стороне клиента. Костыль конечно, но альтернатива -- это shared memory, растущее количество связей между клиентом и сервером, проблемы синхронизации, и вообще увеличение сложности, от него просто напрашивается откупиться повышенным расходом оперативки.
Правда я тут подумал, что сложно будет отслеживать состояние DOM если есть несколько конкуретных процессов, которые параллельно выводят в терминал.
А если ещё дать возможность загружать в терминал модули на webassembly, для того, чтобы, например, выводить видео из ffmpeg буковками, но передавать кадры не as is, а в виде закодированного пожатого битового потока, и декодировать в буковки на стороне терминала... это вообще сделает ненужным Xorg, Wayland, gtk/qt/wxwidgets/... и всё остальное. И электрон в частности станет ненужным. И даже web станет ненужным, и даже небо, и даже Аллах.
Но применительно к emacs'у это просто фонтан, а не идея, потому что emacs может продолжать работать с графикой (с тем что он считает графикой) так, как он работал с ней исходно в 80-х годах через ncurses, только вместо ncurses будет тонкая прослойка API над printf. А при желании, можно загрузить в терминал vt100.wasm, и будет emacs работать с терминалом через ncurses.
>> ecb (layout left-analyse)
> Что это? Про ecb написано, что это "An interface to the Eclipse
> IDE". Я думаю, что если я поставлю eclipse, то я не буду костылить и впихивать в него emacs. Или оно не требует
> установки eclipse?Это не про клипсу, это про код браузер:
https://www.emacswiki.org/emacs/EmacsCodeBrowser
https://github.com/ecb-home/ecb
> Мне хотелось бы такое красивое дерево сбоку от кода для навигации по нему, перемещение между файлами без границ. Текст файла не в виде простыни кода, а в виде отдельных топ-левел блоков, чтобы я их сворачивал разворачивал так, как мне хочется, и даже (о ужас) даже мышкой, если у меня половина рук занята чем-то посторонним. Это если навскидку.ECB умеет это, емнип.
> Мне хотелось бы такое красивое дерево сбоку от кода для навигации по
> нему, перемещение между файлами без границ. Текст файла не в виде
> простыни кода, а в виде отдельных топ-левел блоков, чтобы я их
> сворачивал разворачивал так, как мне хочется, и даже (о ужас) даже
> мышкой, если у меня половина рук занята чем-то посторонним. Это если
> навскидку.Ну это вам какой-нибудь Jupyter Lab нужон, где модно-молодежно.
>>> выходя в онлайн и создавая EmacsCloud платформу, где я мог бы завести аккаунт
>> RMS не одобряет эти ваши аккаунты. Слушайте дедушку, покудова жив.
> Он много чего не одобряет.Печально, что мало орет в голос "я же вам говорил!", а пора-б.
>> Мне хотелось бы такое красивое дерево сбоку от кода для навигации по
>> нему, перемещение между файлами без границ. Текст файла не в виде
>> простыни кода, а в виде отдельных топ-левел блоков, чтобы я их
>> сворачивал разворачивал так, как мне хочется, и даже (о ужас) даже
>> мышкой, если у меня половина рук занята чем-то посторонним. Это если
>> навскидку.
> Ну это вам какой-нибудь Jupyter Lab нужон, где модно-молодежно.Да, я подумываю перелезть на VSCode. Привычки к кейбиндам можно переучить, а удобно программировать важнее чем держаться за какую-то там идею.
эта боль снимается всего лишь 2 плагинами: neotree и origami. А плагинов 100500 и каждый какую-то хотелку решает ;)
Нет, если дошло до степени "хачу как в VS Code" - то никак, хвала Аллаху.
> эта боль снимается всего лишь 2 плагинами: neotree и origami. А плагинов
> 100500 и каждый какую-то хотелку решает ;)Спасибо, я гляну.
> neotreeЗакладки уже завезли?
Глянул. А вот ты не знаешь способа, как сделать, чтобы исключить буфер из списка по которому C-x o движется? Я каждый раз ленюсь выяснить как это можно сделать, и именно этим у меня заканчивается использование всех этих аддонов, которые открывают дополнительные информационные/навигационные буфера. И я даже каждый раз забываю об этом.
"C-x o" движется не по буферам, а по окнам, растодаун.
> "C-x o" движется не по буферам, а по окнам, растодаун.Пофиг.
> дурацким видением ООП из прошлого тысячелетияСогласен, каждые 10 лет видение ооп надо менять.
>> дурацким видением ООП из прошлого тысячелетия
> Согласен, каждые 10 лет видение ооп надо менять.В том-то и дело, что его не надо было менять. ООП, исходно, это теоретическая концепция, вся суть которой сводится к тому, что надо программу разбить на куски и инкапсулировать всё внутри, организовав взаимодействие между кусками передачей сообщений (не указателей, каких-нибудь, а сообщений, которые можно реализовать как вызовы методов или функцией emit_event, или даже HTTP POST). Короче что-то типа сегодняшней идеи микросервисов. Или любое взаимодействие клиента и сервера может быть неплохим примером.
Потом приключилась Simula, которая эти идеи реализовывала, и ООП мышление запало на симуляцию и на то, что надо выделять идею объекта в предметной области, сопоставлять этой идее класс, и писать симуляторы. Фу такими быть. Написание симуляторов -- это маленькая часть программирования в целом. Но нет, надо было поставить эксперимент с запихиванием всего программирования в рамки именно такого симулирующего ООП, с тем чтобы посмотреть, что из этого выйдет. То есть эксперимент стоил того: благодаря ему мы сегодня убеждённо можем говорить о том, что не вышел каменный цветочек. Но тянуть сегодня ошмётки того ООП и таскаться с ними как с писаной торбой -- это... ну я не знаю как это называется.
>Короче что-то типа сегодняшней идеи микросервисов.Smalltalk?
>>Короче что-то типа сегодняшней идеи микросервисов.
> Smalltalk?Он был продолжением развития идей, перед тем, как C++ вбил последний гвоздь в здравомыслие.
Тот ООП, который Simula, и тот ООП, который Smalltalk - это две большие разницы, если задуматься.Тот, который Simula, прекрасно подходит для моделирования предметных сущностей. А тот, который Smalltalk, для, гм, всего остального. При этом они отлично совмещаются друг с другом (см. domain events в DDD).
Ordu> Но меня последнее время не оставляет мысль: а что если вышвырнуть из emacs'а всё относящееся к X'ам и прочим gtk, вернутся к текстовому интерфейсу, но ncurses тоже выпилить, и подложить вместо него браузерный движок рендеринга.Знаешь _что_ то твоему ТЗ наваяют нынешние програмизды?
Ога-ога - оно самое на електроне/атоме/ноде/бандлед_хроме :-о
> Ordu> Но меня последнее время не оставляет мысль: а что если вышвырнуть
> из emacs'а всё относящееся к X'ам и прочим gtk, вернутся к
> текстовому интерфейсу, но ncurses тоже выпилить, и подложить вместо него браузерный
> движок рендеринга.
> Знаешь _что_ то твоему ТЗ наваяют нынешние програмизды?
> Ога-ога - оно самое на електроне/атоме/ноде/бандлед_хроме :-оИ чё с того, как и что они называют?
Уже была такая идея, называлась xulrunner.В итоге её сейчас убили или убивают. Излишняя обобщённость пока не работает.
Ну и прибивать намертво к хрому...
> Emacs как всегда лет на двадцать отстаётЭто да.
https://github.com/emacs-mirror/emacs/commit/9344612d3cd1643...
Чуваааааак, выдыхааааай!
>> и выводит не тогда, когда видеокарте удобно или когда оконный менагер решил,
>> что неплохо было бы перерисовать окно, а тогда, когда emacs'у захочется.Он это заслужил :)
Для браузера.https://emacsnotes.wordpress.com/2018/08/18/why-a-minimal-br.../
https://www.gnu.org/software/emacs/manual/html_node/elisp/Xw...
> Ему-то вебкит зачем, интересно?..Очевидный ответ: народ играется с тем, что встраивает браузер непосредственно в Emacs. Уже в прошлой версии это было. Правда, кому оно нафиг нужно -- ума не приложу.
В смысле, когда-нибудь оно и может и пригодится, но пока Emacs однопоточный -- говорить тут не о чем: просто ребята играются.
>> Ему-то вебкит зачем, интересно?..
> Очевидный ответ: народ играется с тем, что встраивает...какие-то Gtk-виджеты в, вплоть до броузера, да. Главная игрушка.
https://www.emacswiki.org/emacs/EmacsXWidgets" Xwidgets is a concept similar to the Java AWT toolkit, but instead for Elisp. "
- вот прям всё объясняет1>браузер непосредственно в Emacs.
> Уже в прошлой версии это было. Правда, кому оно нафиг нужно
> -- ума не приложу.Ларс [говорит, что] ютуб смотрит. %)
https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01...
https://lists.gnu.org/archive/html/emacs-devel/2016-02/msg00...
Скачать emacs можно отсюда: https://emacs.dev
Never gonna give you up... 🎶
elementary Code
https://www.opennet.ru/opennews/art.shtml?num=47853
Всё так же тормозит?
> Вплоть до выпуска GNU Emacs 24.5 проект развивался под личным руководством Ричарда Столлмана, который передал пост лидера проекта Джону ВиглиЧто будет, когда Столлман уйдёт? Страшно представить. Кто станет защищать нашу свободу от корпорастов, ведь, сожрут мерзавцы с потрохами и не подавятся. А ведь не всякий из нас имеет такое мировоззрение и идеи, готов жертвовать собой и сможет жить, как Столлман! Этот мужественный человек делает всё для нас с вами, для всего мира, чтобы мы могли свободно и без СМС пользоваться ПО для учёбы, творчества и работы. Выражаю свою благодарность Столлману и всем тем людям, которые заняты в разработке и популяризации СПО в мире!
Они и так сожрале, олё!
Нет твоей свободы: ты уже давно раб, про которого знают все, кроме тебя. Privacy is dead. Твоими данными торгуют все. Каждый твой клик уже посчитан, проанализирован и взвешен. Ты — товар. Рввно как и вся твоя история взаимодействия с сетью. Прими это и начни уже двигаться в другую сторону.
> Прими это и начни уже двигаться в другую сторону.стесняюсь спросить, в какую? Кроликов разводить?
Лепить петухов на морозе из г-на не предлагайте - очень руки мерзнут.
> очень руки мерзнутТак ты из тёплого г-на лепи - ещё и согреешся.
Он вроде говорил, что не любит свежачком обмазываться... :)
