Система скрытых тегов в исходниках - как бы такое залудить? Постановка задачи
Нужна система тегов, совместимая с С|С++ (равно как и с любым другим языком), которая была бы удобная в использовани, и не приводила с "засиранию мозгов".
Это позволит перейти к новой парадигме, которую я условно называю "блок кода". Суть в следующем.
Есть некая кучка исходников. Несколько строк....несколько сот мегов. Не важно. Этот блок кода хочется использовать везде. С точки зрения внешнего мира у блока всего 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.ch …t/edreamleo/front.html - понятно, что это больше чем редактор, это по сути, реализация части из описанного мною выше. Но он основан на tkinter - а хочется все-таки родного интерефейса ОСи типа vxWidget хотя бы.
3. Критика описанных выше идей?