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

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

тыкс, чота выбрадила мысль, надеюсь не слишком мутно получилось

Вот-вот! Причем настоящий "визуал"!

Ну так вопрос же был "кому чего от него (форт-редактора) надо?"
Я не думаю что вопрос "перезаточки" вызовет какие-то сложности, тем более что это можно учесть в самой реализации редактора.
Собственно идея BF2 - побочная. Первоначально это задумывалось как "база правил". Нужное слово (в SPF) выбиралось из mySQL, собирался к виду : word x y z ; и запускалось по EVALUATE. Но из-за проблем с выполнением третьего запроса (что-то там переполнялось - не помню уже) от идеи пришлось отказаться.
Но, скажите мне, разве не является прогрессом:
1) перенос каталогов с исходниками в базу данных?
2) редактирование (непосредственно в БД) с возможностью быстрого поиска и наглядного просмотра (на одном экране, а не в окошках FAR'а) своих и чужих исходников?
3) быстрое переключение (изменяя значения только одного поля в БД) между разными версиями одного слова?
4) сборка программы мышкой в виде интуитивно понятной блок-схемы?
А также, наконец-то,- реальная отдача от стековой нотации.
Так что эту идею я тогда на всякий случай отложил "под сукно"... Разве сейчас - не этот случай?
Что не было учтено в вышеизложеном, так это различие синтаксиса в версиях форт (еще поле "Forth" ввести дополнительно) и ассемблерные вставки.

Делать, так делать!

И еще - представление слов в редакторе в виде квадратика с именем слова не такая уж страшная вещь, как кажется.
Что там тех блок-схем? Ну, циклы. Ну, ветвления.
Зато вид программы, как "гипертекстовой" блок-схемы. Вау! Фрактал, однако!

Ссылки на BF2 не открываются.

Извиняюсь,- там иногда acWEb стартует раньше DSL.
Копия здесь:
http://clandike.com/ForthUNE/bf2.html
А также, чтобы не делать базу руками:
http://clandike.com/ForthUNE/BF2.sql
И одна попыток работы с базой:
http://clandike.com/ForthUNE/bf2-test.f

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

кстате уже существуют системы построения програм блочнодиаграмными методами, применяютса при програмировании микроконтролеров,
например таких как сематик сименсовский, из среды изограф, там это оправдано система формирует максимально защищеную от ошибок программу, что просто ЖИЗНЕНО важно в промышленых технологических процесах

ладна, позже еще перечитаю bf, подумаю

три человека на форуме и уже две концепции, сложно будет договорится

Так на то и фортеры! Индивидуалисты. В лучшем случае - каждый будет свой проект писать...

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

Нет-нет-нет!
Я же уточнил, что сборка слов и их выполнение по EVALUATE - это отдельный разговор. А если не хочется связываться с графикой, то весьма небольшой набор стандартных блок-схем можно изобразить и псевдографикой. Речь идет именно о редакторе и именно для форта. Почему это надо? Извиняюсь, что повторюсь:
Слова форта, как базовая единица программы, отлично ложатся в предложеную схему (чего не скажешь о других языках). Мы получаем дружественную среду... редактирования ("дружественная среда разработки" подразумевает этапы компиляции, отладки и пр.)
Да, это будет непривычный, уже подзабытый забытый метод разработки программ, но зато какая читаемость исходников! Плюс, естественно, гипертекстовая расширяемость просмотра в глубину слов - до ядра (в случае графической реализации bf2, к ним можно было бы приклеить "базовые" иконки). При этом автоматически получается некая "визуализация" операций со стеком - опять же без привязки к конкретной версии форта, а только за счет чтения стековой нотации из БД (т.е. авторских комментариев).
А подбор версий слов и подклюючаемых либ? С этим недоделком bf2-test.f я штук пять разных вариантов склейки строк перепробовал.
И еще один момент: bf2 - это, собственно, даже не редактор! Редактирование слов происходит в самой mySQL. А bf2 - средство для сборки исходника форт-программы из заранее заготовленных в БД слов/либ.
Ну не знаю. Может я не прав. Каждый опирается на то, чему учился. А у меня в этом плане первый опыт был - блок-схемы и Проминь-2
ЧтениеЯчейка001. ЗаписьЯчейка002. И фишками с дырочками каждый оператор вставляешь в паз на панели ввода.
ЭВМ, однако!
PS Только вот что интересно - тогда это было не программирование, а божественное ощущение торжества чистой логики - КАЙФ!

Я бы разделил так (примерно по лексиконам):

1. Функции для работы с системой - задержки, многозадачность. Без этого в полной системе нельзя, а в простой м.б. заглушки.
Сюда же чтение нажатых клавиш.

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

3. Средства визуализации текста - содержимое буфера показать на экране. Нарисовать видимую часть строки, нарисовать строку дампа. Нарисовать рамку и текущее положение курсора...

4. Таблица "кнопка - ее функция". Таблица компилированная или даже в словаре - от реализации. Это, собственно и есть "ядро" редактора

5. Стандартные диалоги - выбор файла, параметры поиска и т.п.


6. То, что тут называлось "плагины". Функции комбинаций кнопок и просто вспомогательные слова. Это компилировать при загрузке. Можно добавлять в рантайме. Новое слово сразу доступно как ф-ция. Можно сделать функцию у кнопки "запуск слова с именем" для отладки нескольких связанных слов. Для ускорения загрузки можно использовать предварительно откомпиленные части, а новые компилировать поверх.

Система получается простой архитектуры. Все открыто и доступно.
п.3 определяет внешний вид в данной среде - в текстовом, в графическом режиме, хоть по COM-порту и в HTML. Хоть голосом.

При хорошей факторизации будет примером для учебника проектирования.

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

Визуальные среды (а не просто визуальная сборка GUI) имеют свои несомненные плюсы. Визуальная информация человеком обычно обрабатывается быстрее, чем текстовая (по фото узнаешь человека быстрее, чем по его описанию Лучше один раз увидеть.... ).

Хорошо спроектированная среда на форте будет меньше большинства сред, написанных на других языках.
Согласен, визуальность предусматривает некотороый дополнительный объем. Хотя тут мой любимый пример - ColorForth. Добавили визуальность (цвет), упростили компилятор... Там, правда, много чего еще сделали для упрощения, но 64Кб на графическую систему - по-моему, не плохо. И жаловался вот один, что создание кнопочек с тенями а-ля Windows заняло аж... (кажется, меньше 2!!)...Кб!!

Визуальность среды и скорость работы результата - вообще независимые параметры А мышкой ворочать никто не заставляет.
Тем более, что построить GUI лучше с помощью либ ~yz. Вот эти либы "завизуалить" - было бы оччень здорово. И мышатники вздохнули бы спокойно... ...Пока нет лучшего варианта.

Готовые среды обычно спроектированы не очень подходяще к нашему случаю. Слишком много лишнего. Фортовые системы
должны быть не такими!! Так что еще один хороший проект - учебник для следующих. Хотя бы поэтому его надо делать...

Тут еще богословский вопрос - стиль работы.
Чем клацать на клаве пару кил текста (ошибка - возврат, снижение скорости, много повторений сложных комбинаций нажатий), проще блочкИ на экране подвигать.
Особенно, если вся группа видна сразу, они "прилипают" только несколькими местами и не липнут неподходящим образом!

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

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

Двумя руками "ЗА". А еще показывать текущее состояние словарей (и стеков) с возможностью вставки слов методом "перетаскивания", диалоговой компиляции ненайденного слова вместо сообщений "не найдено" (что позволит писать программу почти в "классическом" стиле детализируя в процессе написания)...
В общем превратить написание текста программы и последующую компиляцию в проектирование(даже точнее - выращивание) форт-системы до варианта конечной программы и последующее оформление результатов трассировки твоих действий (если нужны именно тексты программы). Т.е. сделать не текст программы целью работы, а саму программу. А текст уже как ее результат или вспомагательное средство. Примерно как файл ресурсов в Вижуал-средах...

Думаю для начала стоит отделить как в старом SPF2 имена слов от их исполнимой части.

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

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