нафига изобретать ? чем не подходит vim или любой другой с подстветкой синтаксиса ? хотите родить еще один emacs на Форте ?

для особых любителей IDE есть например FTE

Не знаю, как другие, а я - хочу!
Сделать нормальный расширяемый редактор. С факторизованными частями, с естественным использованием плагинов.

Если добавить компилятор и систему исполнения - получится операционная система.

Обычно я использую FAR+Colorer.
Для текстов - Word, мне надо проверку слов и орфографии, особое форматирование и печать.

Редакторы, которые мне попадались - слиииишком большие. И "нелогичные". Приходится искать, где это в меню запрятано то, что я хочу сделать.
Или маленькие и "замкнутые".
Для форт-систем редактор должен использовать либы системы. И показывать хороший стиль программирования.
А то даже в "редакторе с исходниками" черт ногу сломит. А это не по-фортовски!

Хочется, чтобы редактор был частью системы программирования, помогал в работе, а не просто был частью цикла "редактирование- компиляция- запуск".

Графический редактор - это, наверно, отдельная тема.

В данном случае это не редактор графики, а редактор текстов(исходников), использующий возможности графического режима.

В ЕСПД были р-схемы. Это графы, отображаемые не как линии, а обычными АЦПУ(графопостроителей было мало).
Чисто текстовый режим.

Я думал их к Форту приделать, пока не нашел другие решения - Colorless ColorForth и то, что я описал про редактор...

"кнопка запуска дум III" , тогда довайте и контекстный выбор смайликов для падстановки в код сделаем

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

A, ну, тогда надо это дело обзывать "редактором в графическом режиме", оно, разумеется, уже совсем другое.



На Спектруме сам делал такой редактор для схем и разводки плат. И даже разводку на нем сделал, которая пошла в дело.

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

Для плугинов должно быть некое место в структуре редактора. Т.е. надо начинать с продумывания этого дела, в том числе, механизма встраивания плугинов. Я так вижу, что редактор состоит из нескольких блоков, и плугины встраиваются в интерфейсы между блоками. И, собственно, плугины должны "знать" эту структуру или хотя бы то место, куда встраиваются.

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

Блоки редактора:
1. Интерфейс к тексту (TI)

2. Блок редактора.

3. Блок ввода.

4. Вывод на устройство отображения.


хм... надо придумать что-то, чтобы блочные схемы рисовать в форуме

добавлено немного позже

интересен сам принципп плагинов,
их форма
можно ли риализовать плагины в виде фортоподобных скриптов которые просто интерпритируютса в стореным в редактор движком ?
согласен практически это теже макросы но макросы паставленые в ранг основного инструмента расширения.
плюс - "крос платформеность", сохранение и подчеркивание фортности даного редактора
минус - всетаки это медленая реализация (хотя странно, гигерцы растут, а кампьюторы все также тормазят )

по поводу пользовательского интерфейса, тут канечно можно падумать, что там надо
- безусловно поле ввода кода
- кнопки "сохранить" "открыть" "исполнить" и прочие стандартные...
- разного рода дополнительные окошечки и поля, как вариант об известных редактору словах переменых ,
чем больше пишу тем больше понимаю что описываю редактор Quest :\ все мои непридуманые идеи уже сперли

PS менее всего я хотел бы видеть редактор исполненый в высокохудожественом стиле "XP"

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

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

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

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

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

Хех
Под определение такого "редактора" прямо попадает и сам Форт

ну тогда давайте дадим определение тертьего состояния форта,
1 компиляция
2 интерпритация
3 редакция

и появятса слова с призноком только для рижима редактирования

Только смысла в таком что-то не сильно видно
Будет проще, если в режиме редактирования не все слова будут доступны и просто будет выданa обычная ошибка с вопросом...

ну дык это я пашутил

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

вапрос в том какую степень свободы предоставить плагинам, полная свобода это работа практически с нуля,
практический пример: добавить кнопку на панель управления, должен плагин создавать панель управления или просто добавить кнопку к ранее существующей, правилнее будет наверно просто добавить, тогда панель должна существавать заранее, в базовых элементах редактора
возникает вопрос как это будет выглядеть технически, до запуска окна должна проводитса работа по созданию структуры элементов, это какойто "парсер gui" получается

Редактор? Хм… Затея, крайне необходимая, но обреченная на неудачу! Фортеры народ самодостаточный. Каждый сидит себе в своей песочнице,- и больше ниче ему не нада…
Специфика (слабое слово, но сойдет) форта определяет нестрандартность специализированного форт-редактора.
Как фортеру-непрофессионалу мне хочется следующее:
Во-первых требуется отображение состояния стека для каждого слова. Причем совсем не обязательно это должен быть реальный стек – достаточно стековой нотации каждого из слов, приведенной к какой-то стандартной форме.
Во-вторых каждое слово в редакторе должно «раскрываться» - нечто вроде гиперссылок или группировки строк в Excel.
В-третьих необходима возможность предельно простого переключения между версиями одного слова и библиотеками.
В идеале (мечтать не вредно), форт-редактор (и только его - другие языки для этого просто не годятся!) можно сделать графическим и изображать все слова в виде элементов блок-схем. Перетащили мышкой нужную картинку… назначили ей слово… заглянули на всякий случай внутрь слова… проверили состояние стека до и после… поехали!
Но это еще не все. Зачем хранить разные версии слов и библиотек в отдельных файлах и каталогах? Либа - не Class! Поэтому и сидим в FAR’е с Coolorer’ом, что по директориям шариться удобно. А у нас базовый кирпичик – СЛОВО. Так почему положить все библиотеки и свои черновики в место, предназначенное для быстрого поиска – в mySQL.
Нет, не рабочую программу (это отдельный разговор, не сейчас) а заготовки-либы-старые_версии, все что наш редактор будет использовать для создания (текстовых) файлов к соответствующей версии форта. Впрочем, в дальнейшем, можно и компилятор прикрутить.
Итак,- голая идея редактора BF2 (в смысле «Base Forth to» – клеим все! ):

На рисунке – структура базы данных, из которой наш редактор берет слова. Главное (исполняемое) слово лежит на «рабочем столе» (table) – это «книга» (book) с названием на «титульном листе» (title). Его легко продублировать и изменить подключенные слова/библиотеки, исправив значения полей book и page. В «ящиках» (box) мы будем хранить данные. А для слов введем дополнительный иерархический уровень (наподобии каталогов разработчиков в SPF) собрав из отдельных «листов» (block – давно забытое старое!) «страниц» (page), из них - книги (book), и сложив «библиотеки» (library) в «шкафы» (case). Для удобства редактирования длинных слов некоторые «страницы» будут иметь «абзацы» (letter).
NB: Смысл «library» здесь несколько изменился – это не копия library форта!
К огорчению ленивых авторов, им прийдется заполнять поля стековой нотации для «входа» ({s-) и «выхода» (-s}) слова. Редактор же по этим полям покажет нам стек, а по полю (list) – содержимое слова.
В общих чертах все. Возможно я что-то забыл или перепутал…
Дополнительные картинки здесь:
http://tor.net.ua/forthune/bf2.html