почему никто так не делает?

потому что незачем

Не могу представить себе нормальной среды разработки без поддержки многопоточности в скриптах. К тому же Emacs должен стать шустрее после перехода на CL.

GuileEmacs

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

Я когда-то пробовал. В смысле сделать Emacs на Common Lisp.

В общем, проблемы две:

1. Сделать редактор на CL по API совместимый с Emacs Lisp. Это долго.

2. В конвертере придётся указывать все переменные как special, так как в Emacs нет лексической области видимости.

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

https://common-lisp.net/project/climacs/

Именно поэтому в плане есть пункт #2 - вместо ручного написания всего API, мы пишем конвертер, и подгоняем имеющуюся реализацию под нужный формат для SBCL.

А почему не на Scheme?

в чём проблема этого метода, и почему никто так не делает?

1. Долго.

2. И так всё работает.

Оба пункта дискутируемы, чем и занимаются все емаксеры. А заводы, тем временем, стоят.

Там legacy elisp (org-mode etc.) исполняется?

P. S. Риторический вопрос

вместо ручного написания всего API, мы пишем конвертер

Из Си?

Я имею в виду http://www.gnu.org/software/emacs/manual/html_node/elisp/Frames.html , http://www.gnu.org/software/emacs/manual/html_node/elisp/Windows.html и подобное.

Там legacy elisp

Так получилось, что противники схемы оказались и противниками елиспа.

Конвертер такой: библиотека на C для elisp -> библиотека на C для SBCL

Я к CLOS неравнодушен.

А противники elisp и почитатели Scheme решили не возводить все в абсолют

библиотека на C для SBCL

Если ты сможешь SBCL встроить в Си (как это реализовано для Guile и Elisp), то тебе можно будет памятник ставить. Или ты имел в виду ECL, а не SBCL?

Yi

Чего ж сразу на Haskell не переписывать? Хотя зачем переписывать, Yi вполне себе самостоятельная разработка навеянная Emacs'ом.

Я, конечно, имел в виду вот это http://www.sbcl.org/1.0/manual/Foreign-Function-Interface.html.

в Emacs нет лексической области видимости.

В 24 уже есть, но почти весь существующий код написан с динамической, да.

просто интерпретатор elisp с огромной библиотекой на C

нет

den73 с другого компьютера

Может тебе будет интересно - https://bitbucket.org/budden/clcon

Мастеров спорта по тяжелой атлетике не так уж и много, для такой работы. Вот любителей обрезков ногтей поболее, и то.

Всё просто

почему никто так не делает?

1. emaks не нужен

2. lishp не нужен

Grammar Nazi негодует

имел в виду вот это http://www.sbcl.org/1.0/manual/Foreign-Function-Interface.html.

Ну тогда удачи в переписывании Emacs в виде библиотеки.

P.S. Если тебе это удастся, можешь заодно и Tk в виде библиотеки для Си переписать.

Не ты первый, не ты последний :)

а кому и зачем это нужно?

elisp - почти подмножество CL

да ну нет, я хоть и совсем немного писал и на том и на другом, разница довольно ощутимая, мне кажется

Лучше бы гуевину нормальную сделали. elisp можно и пережить.

Для текстового редактора важнее нормальный язык расширений чем GUI

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

А вот с гуевиной у емакса беда - 2015 год на дворе, а он не умеет вертикальную линию чертить на заданной ширине (например, 80 символов). Вернее есть расширение fci, но оно ломает все, что только можно, и типа исправить нельзя. Наглядность статус бара и списка с автодополнением проигрывает тому же atom-у вчистую.

Объясните пожалуйста, в чём проблема этого метода, и почему никто так не делает?

Пишется конвертер, преобразующих исходники библиотек на C для elisp в библиотеки для того же SBCL.

в этом. см. в списке рассылки Guile от Тома Лорда, там были оценки что elisp сильно завязан на особенности типа динамической области видимости, и в общем такой конвертор нетривиален.

ссылку на драму в переписке не помню, но для начала прочтиай вот это — полный PDF по ссылке.

конвертор нетривиален, тем не менее что-то было написано.

просто Emacs очень сильно завязан именно на особенности Elisp.

у XEmacs-ексеров была статья про замену движка другим, примерный план перехода — как раз про то, чтобы отвязать движок от «особенностей Elisp». cм. также

XEmacs хорош тем, что там относительно просто пишутся плагины на Си, а в GNU Emacs такое делают извращениями с libtool. см. подробности, причины почему так не делают — в основном, политические.

также см. GNU GuileEmacs

основной сложностью является требование, чтобы работали ВСЕ расширения на Elisp-е (например, org-mode и прочие). это накладывает требования к обратной совместимости, для поддержки Elisp-а (никому не улыбается переписывать все 3500+ пакетов-расширений на елиспе)

тут можно двигаться динамически расширяя плагинами на Си, переписывая всё самое нужное на сишечку. хотя для некоторых типа того же org-mode это будет весьма нетривиально.

подвижки по обеспечению совместимости с Elisp есть у GuileEmacs: 1) Elisp синтаксис 2) на схему переписать относительно просто

если от совместимости с Elisp отказаться, то тут есть множество «более лучших емаксов»:

* CL: Hemlock, Portable Hemlock, Deuce

* Dylan: Deuce

* Java, Scheme, ABCL + CL on Java: Jemacs

* MitScheme: EdWin

* Erlang: Ermacs (см. Elixir + какой-то клон лиспа на Erlang) — тут должно быть всё ОК с многопоточностью

* Ocaml Emacs (ссылку не помню)

* Oberon-2: Ewoks (модульный «емакс» на Oberon-2 из реализации Oxford Oberon-2 compiler, на Ocaml-е)

и самый, на мой взгляд прикольный:

EmACT от автора OpenLisp. OpenLisp — это самая полноценная реализация ISO ISLISP, не CommonLisp а другого стандарта. диалект более компактный, понятный, встраиваемый.

к сожалению, OpenLisp зело платный — доступны бинарники под все системы, с интерпретатором можно поиграться, но компилятор в LAP и далее — за бабки.

исходники EmACT написаны ОЧЕНЬ аккуратно, практически нормальное модульное программирование на ANSI C. что-то красивее видел только у Фабриса Белларда.

там в общем, вот эта часть из «плана перехода XEmacs» про отделение интерпретатора от движка уже почти наполовину сделана — API emact-openlisp гораздо проще, чем emacs-elisp.

полный список альтернативных емаксов, дискасс

ещё есть TeXmacs на Qt4 c Guile, но оно не совсем емакс, скорее гуйня с плагинами для CAS.

ограничения елиспа

почему елисп сосёт

в TeXmacs более-менее, нормальный GUI: например, есть векторный редактор картинок плагином. другое дело, что ядро GNU Emacs никто переделывать не будет (а такие штуки если сильно припечёт, можно делать либо через XEmbed либо как SVG : командуя Inkscape через D-BUS).

Zile > Zz if a proof of concept

синтаксическая раскраска в Zz + Emacs на Lua.

Deuce на Clojure

Я за японским клоном слежу, они упоротые, может таки смогут: https://github.com/cxxxr/lem

Emacs на Lua

От замены говна на мочу лучше не становится.