Чем не устроил эль?
Зачем это всё нужно, когда есть емакс?

Отвечу за автора

Зачем это всё нужно, когда есть емакс?

Текущая цель - простая и легковесная IDE для обучения (альтернатива SLIME), устанавливаемая «за один щелчок».

Хотя я соглашусь с вами, можно было бы просто установщик Emacs с нужным набором конфигов сделать.

А в чем необходимость написания этого проекта, при наличие SLIME?

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

Эль не устроил многим. Например, работать с tk через хронически недопиленную обёртку - это нетехнологично. tcl/tk достаочно хорош, чтобы работать с ним без обёрток. Я за месяц на чистом tcl/tk сделал больше, чем в ABLE было сделано за три года.

Ну ладно, ещё раз скажу, раз вам всем это так интересно. В EMACS не устраивает ещё и лицензия. У меня есть вторая цель, которую я пока отменил - IDE для встраивания лиспа в приложения. Например, есть программа 1С предприятие, в ней есть своя IDE. Для простого программиста от сохи освоение емакса может стать нестерпимой болью. Например, в нём латинские сочетания клавиш. При переключении в кириллицу они перестают работать. Также мне не нравится логика работы с минибуфферами, я в них постоянно блуждаю, хотя уже давно работаю в EMACS. Отсутствует универсальная команда «отменить» - Ctrl-G не всегда помогает. И т.п.

Поскольку встраиваемая IDE никого не заинтересовала, я снял её со списка целей. Но на самом деле она просто встала в очередь.

Приемлемый (и не единственный) пример IDE для новичков - это Comodo. Окна в табах, переключаемые по Ctrl-Tab, меню с подчёркнутыми буквами, видимые букмарки по Ctrl-F2 (стандарт микрософта), список функций/классов в файле рядом с текстом, список недавних файлов в меню «File», поиск через диалоговое окно с галочками или инкрементный, вызываемый клавиатурой. Как хотите, но вы _мне_ никогда не докажете, что здесь EMACS лучше. Есть традиция построения IDE, EMACS ей не следует, а 1С-предприятие - следует. Я погорел на этом и понёс ущерб, когда не смог наладить поддержку своего промышленного приложения. На лоре тоже моя вакансия долго висела, но никто из местных знатоков емакса ко мне на работу не пришёл. Так что продвигайте EMACS кому-нибудь ещё, но я хочу с ним расстаться, и чем скорее, тем лучше.

А серверную часть я использую как раз ту же, что и SLIME, именно поэтому удалось создать столь многое так быстро. ABLE не пользуется SLIME, а лепит какие-то свои безумные костыли вместо этого. Место ему на помойке.

Использую emacs, но готов легко расстаться в пользу чего-то другого, если там будут slime, paredit и evil-mode. Первое, как я понял, у тебя уже есть. Готов глянуть твою поделку если будут любые два. Готов пользовать вместо emacs если будут все три.

Ещё *неплохо* было бы приделать рефакторинг для CL кода.

Например, есть программа 1С предприятие, в ней есть своя IDE. Для простого программиста от сохи

Как-то не сопоставляется это с CL.

И да, процесс установки выглядит не сильно проще нетребовательной настройки емакса.

А, да. Если покажешь свою поделку с двумя пунктами - с меня ебилд. :)

Я погорел на этом и понёс ущерб, когда не смог наладить поддержку своего промышленного приложения. На лоре тоже моя вакансия долго висела, но никто из местных знатоков емакса ко мне на работу не пришёл.

Ты искал знатоков емакса на работу? :) Т.е. не специалиста в предметной области, а того кто умеет в емакс?

Так что продвигайте EMACS кому-нибудь ещё, но я хочу с ним расстаться, и чем скорее, тем лучше.

Тебе надо было иде накатать для обычных людей и ты реализовал «промышленное решение» на базе текстового редактора с большим прошлым.

А мог бы взять например eclipse platform или netbeans platform.

если там будут slime, paredit и evil-mode

paredit или его аналог будет (на том стоим). slime есть (пока кое-что недоделано, но это дело техники). С evil-mode пока ничего не буду обещать. Сама идея прекрасна и я даже о такой мечтаю, но временные ресурсы ограничены. Но тебе вроде и двух пунктов хватит. Твой голос за paredit учтён.

Рефакторинг для CL кода вряд ли сам буду делать с нуля. Но в целом он нужен, конечно. Есть ли какие-нибудь инструменты по рефакторингу, которые я мог бы подключить?

Почему bitbucket?

PS это не троллинг, на самом деле интересно.

И да, процесс установки выглядит не сильно проще нетребовательной настройки емакса.

Как раз единственная цель «релиза» - упростить процесс установки.

вангую из-за меркуриала.

Почему bitbucket?

Исторически сложилось, что я раньше начал пользоваться меркуриалом и он меня вполне устраивает. У гита были какие-то проблемы под офтопиком. Был эпический пост про унылось битбукета, что ведро хуже котика. С этим даже соглашусь. Но это не повод для переезда :)

Тебе надо было иде накатать для обычных людей и ты реализовал >«промышленное решение»

Там было не совсем так, но по причинам конфиденциальности не могу всё рассказать. Я искал специалиста по СУБД прежде всего, готового учить лисп. Емакс был отягощающим обстоятельством. Возможно, не он решил, но он свою роль сыграл.

А, да. Если покажешь свою поделку с двумя пунктами - с меня ебилд.

Спасибо! Мне бы лучше обычный configure/make/make install бы заиметь.

Есть такая смежная тема. Я не умею делать инсталляторы под линукс. Обычно там нужно как-то рулить зависимостями. tcl/tk устанавливается менеджером пакетов. И вообще я так понимаю, что бинарные дистрибутивы под unix-подобными системами - это проблема из-за совместимости.

А вот что делать под офтопик я более-менее понимаю. Будут ли желающие опробовать поделку под офтопиком или я не в тот форум пишу?

Не потенциальный пользователь, но как по мне, то автоотступы весьма важны. Особенно, для новичков, которые код форматировать не умеют.

Ну и табы удобны.

На github есть hg? Оффтоп, но git - убог. Пользуюсь им изредка чтобы скачать репозитории, так там (в git-е) даже чудовищно примитивные действия в строгом соответствии с рекомендациями и man-ами иногда не приводят к правильному результату. Разумеется что после этого Mercurial - в высшей степени разумная человеческая DVCS без гемора.

В общем понял, за автоотступы все проголосовали. Буду делать автоотступы - paredit (это по сути одно и то же). Там же и раскраска, т.к. это всё полагается на парсер. Ну и плюс к тому, парсер - это последнее место, которое можно обозначить словом «риск». Табы - если успею. Подожду ещё других мнений и тему можно закрывать.

Касабельно git - некритично. Если это будет критично для получения поддержки - можно поддерживать клон в git и обмениваться кодом, или вообще не него перейти. Пока ни одного пулл реквеста от принципиальных битбукетоненавистников не поступало. Шлите пулл реквесты :)

Я искал специалиста по СУБД

готового учить лисп

emacs действительно не виноват :)

Я не умею делать инсталляторы под линукс.

Ок, с меня ebuild, PKGBUILD, .deb и патчи, если с чем-то из этого возникнут проблемы.

Есть ли какие-нибудь инструменты по рефакторингу, которые я мог бы подключить?

Есть. Язык Common Lisp. :) Подробности на bitbucket напишу.

Там же и раскраска, т.к. это всё полагается на парсер.

Это войдёт в тройку худших идей в моей жизни, но может собрать clcon с ECL и воспользоваться его парсером?

ECL - GPL, не пойдёт.

У меня есть свой парсер лиспа с потугами на переносимость и умеющий вместо чтения символов возвращать некие структуры. Для целей создания парсера под редактор нужно ещё из него выпиливать побочные эффекты.

Вот он

Есть. Язык Common Lisp.

Ты зря недооцениваешь задачу, она не так уж и проста. Есть зависимость от порядка форм в файле, есть eval-when, есть #. Есть расширяемый и не слишком простой формат asd .

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

У меня есть написанный на SWANK/tcl/tk прототип IDE для Common Lisp. Сайт проекта clcon. Снимок экрана.

Обязательно ли собирать новые изделия из говна?

Хотя я соглашусь с вами, можно было бы просто установщик Emacs с нужным набором конфигов сделать.

LispBox ?

Slime </thread>

, аминь.

P.S. не через неделю, а до конца месяца буду делать автоотступы и всё такое.

Собственно

Non-Emacs IDEs can’t hurt.

Я правда не совсем понял зачем тебе tcl, у cl разве не нашлось обвязок для tk?

Во, слова золотые, как твоя корона:

The fact that it’s built on Emacs is a problem, as telling a new user they have to learn Emacs before using SLIME (which is not strictly true) is a significant artificial barrier to entry.

Я правда не совсем понял зачем тебе tcl, у cl разве не нашлось обвязок для tk?

1. Нашёлся хороший tkcon, в котором был REPL, история, пример работы с сокетами, пример вызова редактора, пример гиперссылок в тексте, пример комплишена, комплишен имён файлов. Немало для начала.

2. Если инструмент позволяет хорошо работать напрямую, то зачем ему обвязки? Всё равно все обвязки вокруг tk фактически используют машину tcl. Для работы с ними всё равно нужно быть в курсе устройства этой машины и в любом случае придётся иметь дело с этой машиной. Большинство примеров работы с машиной написаны на tcl. Или на Питоне, а чем мне Питон лучше родного tcl? Метапрограммирование в tcl по гибкости не слабее, чем в лиспе (это уж как минимум). Т.е. нет причины использовать здесь лисп. Не хватает лиспового отладчика, compile-defun и M-. , но пока вместо M-. неплохо обхожусь грепом, compile-defun не нужен, поскольку «compile-all» делается на горячую и занимает доли секунды. Вместо отладчика есть окошко просмотра ошибок с номерами строк и есть ещё idebug с возможностью ставить брекпойнты и смотреть стек. Этого достаточно. trace не осилил, но puts-ами вполне отлаживаюсь.

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

3. Программа, которая будет постоянно плеваться кусочками tcl-ного кода, медленнее, чем программа, которая просто написана на tcl.

4. Нет, полноценных обвязок cl-tk нет. Есть неполноценный ltk под LGPL, это может привести к переходу всего проекта под LGPL, а это не планируется. И есть ещё менее полноценный cl-tk. Но см. п.2.

Нашли? Можно ссылку на объявление.

Например, в нём латинские сочетания клавиш. При переключении в кириллицу они перестают работать.

reverse-input-method поможет. Вот здесь обсуждалось http://www.linux.org.ru/forum/desktop/8850631?cid=8852431[\url]. (комментарий)

можно было бы просто установщик Emacs с нужным набором конфигов сделать

Оно уже есть - lispbox. К тому же, после того как в emacs прикрутили установку пакетов из репозитория, жить стало гораздо легче.

Вот когда в емаксе сделают:

Окна в табах, переключаемые по Ctrl-Tab, меню с подчёркнутыми буквами, видимые букмарки по Ctrl-F2 (стандарт микрософта), список функций/классов в файле рядом с текстом, список недавних файлов в меню «File», поиск через диалоговое окно с галочками или инкрементный, вызываемый клавиатурой.

о чём я писал здесь, и выпустять его под пермиссивной лицензией, и ещё чтобы Ctrl-s работало одинаково независимо от выбранной раскладки клавиатуры во всех модах, тогда я и готов буду вернуться к теме емакса.

Вот здесь обсуждалось

А мне не надо «обсуждалось». Мне надо из коробки. Хотя и на tcl/tk мне приходится самому это пилить...

Окна в табах, переключаемые по Ctrl-Tab, меню с подчёркнутыми буквами, видимые букмарки по Ctrl-F2

OMG зачем всё это если есть helm

список функций/классов в файле рядом с текстом

Есть же speedbar.

чтобы Ctrl-s работало одинаково независимо от выбранной раскладки клавиатуры

ЕМНИП если переключать раcкладку емаксом, то работает, но вообще да, бесит иногда. Впрочем, вон vim'еры постоянно esc жмут и ничего, работают. Ты ещё пожалуйся, что {} без переключения раскладки не набираются.

стандарт микрософта

Ну т.е. ты хочешь MSVS, но только с другим названием и под linux.

А мне не нужен конструктор «собери свой Емакс за 5 лет».

Выбор фич был сделан стрёмно. Приделывание одуванчика приведёт к тому, что проект надолго потеряет возможность запускаться под офтопиком. А там он наверняка более востребован. Надо было сделать быстро устанавливаемую версию под офтопиком, а потом уже ломиться в эту сторону. Но пока продолжаю двигаться в выбранном направлении, дабы не метаться.

По ходу делаю мелочи. Например, сделал тур по уже реализованным фичам, позволяющий увидеть их, не наступая на грабли.

А вот что делать под офтопик я более-менее понимаю.

под оффтопик можно накатать арчбилд под msys2 : pacman -S mingw-w64-x86_64-tk mingw-w64-x86_64-tcl либо pacman -S mingw-w64-i686-tcl mingw-w64-i686-tk и в итоге нормально обновляемые через pacman -Suy пакеты.

арчбилд это почти как ебилды в генту, только на баше.

емакс там в пакетах есть, лиспов и slime ЕМНИП нет.

вот это было бы полезно: одной кнопкой установить пакетным менеджером под винду.

Кстати. Для любителей SLIME. Я собственно и хочу сделать, с функциональной точки зрения, SLIME. Для начала чуть меньше, чем SLIME (для начинающих сойдёт). А потом догнать и перегнать :)

Меня в EMACS не устраивает именно «обёртка». Но обёртка - это дело вкуса.

pacman -S mingw-w64-x86_64-tk

Я не сторонник делать из винды линукс. Это должно быть дело добровольное. Когда в path кладут кучу неведомых команд, это не всем может понравиться. Mingw вроде ещё ничего, но я пока и от него не завишу. Задача для винды сводится к настройке tcl, и сборке образа sbcl, чтобы всё это могло запускаться оттуда, куда пользователь это распакует (как архив).

Когда программа будет иметь реальную потребительскую ценность, можно будет обсуждать любые варианты установки, в т.ч. и более тяжеловесные и интегрированные с чем-нибудь-там-ещё, чем простая распаковка самодостаточного архива в папку.

Кстати, я начал делать интерфейс редактора и понял, что нужно как можно быстрее пересаживаться в эту среду. Проявляются всякие тонкости, на которые можно и не наткнуться. Например, сегодня обнаружил существование ping-pong. Всякого рода баги не всплывут, если не пользоваться средой интенсивно.

А что это означает? Что следующей фичей в обязательном порядке будет tcl-мода. Не сказать, что у нас получится IDE для tcl, потому что я выпилил много кода, дающего возможность взаимодействия со сторонними интерпретаторами tcl. Мне главное - работать с тем интерпретатором, который исполняет код самой IDE. Но при наличии перспектив в этом направлении можно будет и впилить обратно этот код.

В начале проекта мне пророчили фейл по причине использования tcl, а не лиспа. Дескать, tcl-щики не любят лисп, лисперы не любят tcl, ты всех отпугнёшь. Сообщаю. На данный момент порядка 340 кб кода на tcl и 38 кб кода на лиспе собственно в clcon. Но если считать swank (не менее 450 кб) и одуванчик (2500кб), то доля кода на лиспе приближается к 90%. Впрочем, из одуванчика, наверное, будет выкинуто порядка половины того, что в нём на данный момент есть.

Вроде бы я составил план, как синхронизировать одуванчик и tcl-ный виджет text, чтобы интерактивные команды и undo были реализованы на стороне text, а лисповые фишки - на стороне одуванчика. Все отдельные элементы, нужные для воплощения этого плана, реализованы и более-менее проверены, осталось связать их воедино.

Отдельный вопрос будет с раскраской.

С автоотступом полдела сделано - из tk-шного виджета text отправляется команда «сделай автоотступ», в тот же миг text зависает, а одуванчик делает автоотступ в том месте, где в text стоит курсор. Недоделана передача команд редактирования из одуванчика обратно в text (ведь он же вставляет пробелы). Как сделать - вроде понятно. Но программа становится всё сложнее и сложнее. Мне это не нравится.

Автоотступ на вид заработал - всё, что нужно для передачи команд «туда-обратно» есть. Но практически он работает через раз. Пока не могу разобраться. Корень зла состоит в том, что не синхронизируются mark-и между двумя редакторами. Иногда при попытке поставить курсор в одуванчике на то же место, где он стоит в tk, происходит фейл. Вероятно, из-за того, что содержимое буфера редактирования в tk и одуванчике не совпадает.

Вероятно, где-то крупный просчёт в проектировании - какие-то события идут не в том порядке. Но пока не могу методически решить. Действую путём осады - улучшаю среду и инструменты. Например, большое достижение за сегодня - что я научил одуванчик принимать события от tk без того, чтобы нужно было провести над ним мышью. Ну и ещё всякие вторичные баги подправил.

Программа уже в основном падает в clcon-овский отладчик. То и дело недостаёт такой возможности, как «вычислить в кадре стека». Возможно, придётся её допиливать в ближайшие дни.

Вроде заработал автоотступ. Остальное подождёт. Попробую теперь убрать зависимость от xlib.