LINUX.ORG.RU
ФорумTalks

Guile-Emacs

 , ,


0

5

Как указано здесь, в рамках своей программы «летние покодирашки» гугол поддержал проект по замене интерпретатора Emacs Lisp на Guile. Что позволит внести фичи о которых с незапамятных времен мечтали все простые смертные - FFI, параллелизм....

Искренне надеюсь, что автор сего проекта выполнит свое обещание.

★★★★

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

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

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

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

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

lazyklimm ★★★★★ ()

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

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

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

Без пруфов?

iVS ★★★★★ ()

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

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

x4DA ★★★★★ ()

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

yoghurt ★★★★★ ()

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

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

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

кагбе уже

lazyklimm ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

Kostafey ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

резонно

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

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

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

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

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

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

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

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

feofan ★★★★★ ()

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

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

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

SXEmacs?

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

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

SXEmacs?

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

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

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

Успехов им.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RCV ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.