Guile-Emacs

незапамятных времен мечтали все простые смертные - FFI, параллелизм....

Я простой смертный, эммм объясните зачем оно мне нужно и какие фишки Вы думаете появятся в Emacs с переходом на Guile. Вот тут недавно было про параллельное редактирование кода в Vim (вот по мне это НЕНУЖНО)

какие фишки Вы думаете появятся в Emacs с переходом на Guile.

сказано же - FFI и многопоточность. Нужно, в общем. Учитывая, что guile, в общем случае, не только scheme (в коробке elisp и lua) - становится совсем интересно

по замене Emacs Lisp в Emacs на Guile.

По замене _интерпретатора_ Emacs Lisp на Guile. Поскольку в Guile есть поддержка Elisp, то это замена шила на мыло.

Что позволит внести фичи о которых с незапамятных времен мечтали все простые смертные - FFI, параллелизм

Без пруфов?

ты не надейся, ты скачай и посмотри сам:

git://git.hcoop.net/git/bpt/emacs.git

lua

с этого момента поподробнее

Так давно уже вроде собирались. Guile научили исполнять Elisp уже примерно года два как.

Только не научили под виндой собираться

Планируется все имаксовские расширения переписать на схему или же просто встроить интерпретатор схемы который будет интерпретировать интерпретатор елиспа?

или же просто встроить интерпретатор схемы который будет интерпретировать интерпретатор елиспа?

кагбе уже

пардон, соврамши, с ecmascript попутал

Уже было 100500 попыток сделать Emacs на других диалектах лиспа (несколько попыток на Common Lisp, несколько попыток на Scheme, по меньшей мере, одна попытка на Clojure). Ни одна из них так и не вышла из зародышевого состояния.

Elisp не совместим на 100% ни с одним другим диалектом лиспа (иначе он бы уже не существовал). Поэтому код пришлось бы переписать, а это более миллиона строк в стандартной поставке емакса и еще много (наверное, больше) в плагинах. Кому это нужно?

Поэтому есть только два реалистичных варианта получения плюшек типа FFI и многопоточности:

• Допилить этот функционал в существующем Emacs-овом интерпретаторе
• Реализовать альтернативный интерпретатор

Вот тут недавно было про параллельное редактирование кода в Vim (вот по мне это НЕНУЖНО)

Не понимаю, как это относится к теме, но в Emacs тоже такое возможно (при помощи плагина).

Я простой смертный, эммм объясните зачем оно мне нужно и какие фишки Вы думаете появятся в Emacs с переходом на Guile.

FFI, многопоточность, доступ до кодовой базы, написанной на Guile... А еще многие считают Scheme гораздо более «правильным» диалектом лиспа, чем Elisp.

(при помощи плагина)

нинада никакого плагина — изкоробки есть

Elisp не совместим на 100% ни с одним другим диалектом лиспа (иначе он бы уже не существовал). Поэтому код пришлось бы переписать, а это более миллиона строк в стандартной поставке емакса и еще много (наверное, больше) в плагинах. Кому это нужно?

Блин. Нет слов.

Previous GSoCs focused on providing afull-fledged Emacs Lisp front-end to Guile’s compiler and VM. This project focuses on the missing piece: replacing the Emacs Lisp interpreter in Emacs by Guile.

Какое из этих слов непонятно?

Делают вещь хорошую, годную, нужную. Всяческих успехов им.

FFI-то при чём? Его по религиозным причинам не хотят в Емакс. Вон, в xemacs'е вполне себе FFI есть.

Уже было 100500 попыток сделать Emacs на других диалектах лиспа

Я понимаю, что речь только о смене интерпретатора, а Elisp останется. Вот только зачем это?

Реализовать альтернативный интерпретатор

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

многие считают Scheme гораздо более «правильным» диалектом лиспа, чем Elisp.

Правильный диалект без стандарта на regexp? Для редактора нафиг не нужен.

FFI-то при чём? Его по религиозным причинам не хотят в Емакс.

Почему, кстати? Впрочем, гораздо интереснее, почему не добавляют многопоточность.

Почему, кстати?

Штолльман справедливо опасается, что Емакс будет использоваться в грязных полупроприетарных решениях.

Впрочем, гораздо интереснее, почему не добавляют многопоточность.

Примерному потому же, почему АвтоВАЗ не выпускает 500-сильные пузотёрки с карбоново-алюминиевым корпусом: а) не осилят; б) целевая аудитория не поймёт; в) ездить негде.

Штолльман справедливо опасается, что Емакс будет использоваться в грязных полупроприетарных решениях.

резонно

Впрочем, гораздо интереснее, почему не добавляют многопоточность.

Примерному потому же, почему АвтоВАЗ не выпускает 500-сильные пузотёрки с карбоново-алюминиевым корпусом: а) не осилят; б) целевая аудитория не поймёт; в) ездить негде.

Тут не согласен. Некоторые задачи занимают долгое время. Логично для таких вещей использовать асинхронный доступ. И тут приходится городить костыли писать внешние сервисы асинхронного взаимодействия. Например, видел такое для взаимодействия с clang

Не нужно.

сервисы асинхронного взаимодействия

Хорошо, когда их можно написать (почта, внешние программы и т.д.). А вот когда запускаешь длинную операцию обработки текста и не можешь уйти в другую вкладку до её окончания — это грустно. Приходится для таких операций для каждой отдельный экземпляр емакса запускать.

Собственно, о чём я и говорю. Многопоточность emacs'у нужна.

А планы-то наполеоновские, неужели студент за лето столько сделает ?

варианта получения плюшек типа FFI и многопоточности

SXEmacs?

варианта получения плюшек типа FFI и многопоточности

SXEmacs?

Он поддерживает многопоточность?

Эээ... Вот этого не знаю.

Хм, анонимус говорит, что поддерживает

Нашел. https://github.com/hroptatyr/sxemacs/blob/master/src/semaphore.h

Правда не знаю, как там с elisp интерфейсом к этому делу.

Если так, все выше написанное - тупняк.

Успехов им.

Я почему-то был уверен, что Guile - лишь реализация Scheme.

Я почему-то был уверен, что Guile - лишь реализация Scheme.

Так оно и есть. Одно другому не противоречит. Guile - реализация Scheme, одобренная и поддерживаемая проектом GNU.

Ну так оказывается, что сейчас Guile поддерживает Emacs Lisp.

http://www.gnu.org/software/guile/manual/html_node/Emacs-Lisp.html

Ну так оказывается, что сейчас Guile поддерживает Emacs Lisp.

Да, все верно. Задача впихнуть ее в emacs вместо штатного интерпретатора Emacs Lisp.

сказано же - FFI и многопоточность. Нужно, в общем. Учитывая, что guile, в общем случае, не только scheme (в коробке elisp и lua) - становится совсем интересно

А вот мне кажется, что это очень вредно. Это самая настоящая дефрагментация сообщества Emacs Lisp, которое уже сложилось. Сейчас можно взять чей-то модуль, дописать, интегрировать, а как только начнут все писать на своих любимых язычках... Лучше не надо. Если дадут кому-то возможность писать под Emacs на lua или scheme, то они и начнут это делать, и тогда пропал Emacs - все станет совершенно несовместимым, скрутить модули станет проблемой, править модули на незнакомом кому-то языке станет проблемой. От этого только хуже станет.

В emacs.devel был разговор на эту тему. Были мнения, что лучше доработать Emacs Lisp. Я с этим согласен. Есть сложившаяся инфраструктура. Да, если будет работать Emacs Lisp, то она, возможно, и будет жить, но дальше начнется зоопарк.

а как только начнут все писать на своих любимых язычках...

если разнести по разным модулям - то нормально, у меня js с scheme связанные через guile вполне себе работали

Были мнения, что лучше доработать Emacs Lisp

баба яга Столлман против того же FFI, например

баба яга Столлман против того же FFI, например

Столлман против FFI только из-за вопросов лицензий библиотек. Он допускает применение FFI, но только если библиотека при линковке будет говорить Emacs, что она под GPL. Прямая речь:

http://thread.gmane.org/gmane.emacs.devel/124954

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

Но тут есть целый пласт для обсуждения вокруг FFI. Зачем в Emacs вообще нужен FFI? Это, к тому же, здоровенный фактор нестабильности! Начнется такая свистопляска, если начнут завязываться на нестабильные или меняющиеся API библиотек. В одном дистрибутиве одно, в другом другое. Одно не работает тут, другое не работет здесь. Какие-то библиотеки на Emacs Lisp будут работать только в Linux, а в Windows перестанут, так как там нет этих бибиотек. Я пока считаю, что в FFI в Emacs нет никакой необходимости и что он даже вреден. А вот многопоточность, наоборот, нужна.

А вот многопоточность, наоборот, нужна.

но над ней вроде как потихоньку работают, емнип

ППКС

Какие-то библиотеки на Emacs Lisp будут работать только в Linux, а в Windows перестанут, так как там нет этих бибиотек

Мысль интересная. Хотя я простой пользователь Emacs, но позволю и я высказать свое никому не нужное мнение. Мне кажется, что основные модули в Emacs действительно не разумно привязывать к внешним библиотекам. Ну а всякие побочные фишки и так уже сейчас сильно связаны с окружением в котором Emacs находится. К примеру, с emms идет специальная c-шная обертка над taglib которая дергает теги из файла. Недавно эту программу в git'e заменили на что-то невероятно perloвое, которое требует установить все перловые библиотеки вместе взятые. Emacs-win не видел достаточно большое количество времени но уверен, что просмотрщик картинок в win (реализованный через imagemagick) работает не очень хорошо. Так что то о чем ты сказал уже случилось.