Постановка задачи

Нужна система тегов, совместимая с С|С++ (равно как и с любым другим языком), которая была бы удобная в использовани, и не приводила с "засиранию мозгов".

Это позволит перейти к новой парадигме, которую я условно называю "блок кода". Суть в следующем.

Есть некая кучка исходников. Несколько строк....несколько сот мегов. Не важно. Этот блок кода хочется использовать везде. С точки зрения внешнего мира у блока всего 4 сущности:

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

Сейчас можно сделать очень глубокое конфигурирование такого блока на основе С препроцессора и autotools (automake, autoconf,...). Но этот варинат на практике довольно не прост, если ставить задачу максимальной гибкости. Многочисленные if def доведут до истерики любого, а "многоэтажные" макросы сильно усложняют понимание кода.

Хочется, чтобы блок кода был описан в некоем файле-дескрипторе. Чтобы можно было ипортировать блок в проект, настроить его, и, что важно, прописать связи с другми блоками. Т.е. по сути вначале выполнить "визуальное проектирование" будущей системы, расставить все связи, проанализировать их, а затем скомпилить в реальный код. С автоматическим переименовываием переменных в блоке кода и пр.

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

Известные решения и их критика

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

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

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

Что делать?

Можно сделать систему на основе внешнего описателя тегов (C-tag и иже с ним). Это не сложно, но возникает проблема при редактировании исходника.

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

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

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

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

По сути, речь идет о создании специального фильтра для редактора. Я это мыслю так.

Есть обычный C код. С расцветкой. Разные цвета на общем фоне.

Есть сущности, отмеченные тегами. Места, где теги стоят, выделены цветом фона. Выделены не сильно, дабы не мозолить глаза.

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

Аналогично с каментами.

Выбор редактора

Итак, что же выбрать?

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

VIM - это реально круто, но его встроенный язык после Python напомитает brainfuck, да простят меня vim мастера.

EMACS - за счет Lisp это нереально круто, но уж больно монструозно. Да и лисп мне нафиг по жизни не нужен.

SlickEdit - пролетает по причине !фришности.

SciTe - http://scite.ruteam.ru - вот, пожалуй, и все, что остается. За счет встроенной Lua его програмить куда приятнее.

Вопросы

1. Может кто видел|знает готовую систему таких скрытых тегов?

2. Есть ли хороший редактор, полностью написанный на Python? Пока мне известен только Leo http://webpages.charter.net/edreamleo/front.html - понятно, что это больше чем редактор, это по сути, реализация части из описанного мною выше. Но он основан на tkinter - а хочется все-таки родного интерефейса ОСи типа vxWidget хотя бы.

3. Критика описанных выше идей?

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

Так сказать одно из трех...

Вроде бы еще с середины прошлого века известны и описаны такие приемы как:

1. резидентные библиотеки программ/объектов используемые несколькими потоками управления
2. библиотеки DLL - которые по сути и есть резидентные библиотеки
3. объектно ориентированные решения COM/DCOM - которые тоже по сути реализуются через уже упомянутые библиотеки + теги описателей + механизм преобразования типов

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

Не проще ли отлаженные блоки кода - как с тегами, так и без - прилинковывывать к задаче прямо из объектных файлов или из библиотек?
Это же классическое и хорошо проработанное решение...

Или я не понял Вашей мысли?