| сразу надо было, но чо уж там… |
[Feb. 21st, 2022|07:38 am] |
занятие жутко скучное, но вытащил все кейбинды из обработчиков в одну большую красивую таблицу. сразу приделал к ним поле со справкой, и акшоны чтобы текстовой строкой. ну да, это готовая механика для чтения кейбиндов из файла. потом сделаю, наверное. в принципе, кейбинды даже можно добавлять и удалять на лету, API есть. фронтэнд, например, докидывает кучку своих глобальных кейбиндов к стандартным.
конечно, этому самое место в скриптах, но я всё ещё хочу, чтобы редактор можно было использовать не таская за ним обязательный набор скриптов. и вообще при минимальных усилиях собрать без скриптового движка.
в целом — я доволен. можно сказать, что это tech beta/preview. там ещё дофига надо полировать, конечно, но редактор вполне юзабелен. что особенно приятно — он ни разу не упал и не испортил мне текст.
таймлайн проекта почти идеальный: около месяца до догфудинга, потом недели три доводка, и ещё где-то месяц остаётся на ленивое допиливание, пока энтузиазм совсем не угас. примерно неделю сэкономил на скриптах и регулярках, взяв за основу существующие библиотеки (хотя я всё равно и то, и другое довольно сильно переделал). остальное пришлось пилить совсем с нуля.
для одептов tdd и прочей подобной бесполезной хуйни скажу, что единственная часть кода, которую я гонял fuzzy-тестами несколько суток (literally) — это реализация дерева, поскольку всё остальное зависит от стабильности именно этого кода. это окупилось. покрывать тестами остальные части совершенно излишне: непродуктивная трата времени и короткого периода энтузиазма. главное — чтобы редактор не падал и не портил текст; остальное выловится в, извините мой французский, процессе эксплуатации.
проект вышел вполне себе модульным.
основная часть — libsxed: реализация деревьев, лога изменений и буфера текста. юзабельна сама по себе.
сбоку пристёгнута libsynt, которая заведует парзингом стилей и файлов синтаксиса, и, собственно, онлайн-движком раскраски. использует только memman из libsxed (который легко заменяется на что угодно другое).
сверху на этом сидит libsfrm: реализация, собственно, фреймов редактирования. текстовых, попапов, минибуферов. ожидает от фронтэнда небольшой набор колбэков, умеет рендерить себя в нечто типа досового экрана — прямоугольный массив уникодных символов и атрибутов. там же живёт простой тайловый wm. зависит от libsrex (см. ниже), libsynt и libsxed (очевидно).
за интерфейс с иксами отвечает backx11. эта часть читает ввод и вызывает keypress handler из libsfrm, а также рисует экранный буфер. ну, и прочие интерфейсные мелочи. также тут живут скрипты, libsfrm ни про какое скриптование знать не знает. потенциально это можно заменить на любой другой фронтэнд.
совсем отдельно лежат libnasal и libsrex. первая — скриптовый движок, вторая — потоковый матчер регулярок. эти вообще полностью самодостаточны.
реализация wm пока тупая как полено, и не понимает, что фрэймы, которые не видно, не надо просить отрендерится. это немного амортизируется тем, что фрэймы помечают себя грязными только когда в них что-то меняется: тогда рендерится «грязный» фрэйм, и все остальные за ним. обычно «грязным» помечается только самый верхний, так что лишней работы не происходит. но это, конечно, надо будет оптимизировать.
реализация экранного буфера хранит копию того, что фронтэнд в последний раз отрисовал в окне. когда фронтэнду надо обновить окно (если это не запрос от системы), то он сравнивает текущее состояние и сохранённую копию, рисует только то, что изменилось, и приводит копию в актуальный вид. таким образом неважно, кто, сколько и что менял в экранном буфере: отрисуются только реальные изменения.
в целом, структурой проекта я более-менее доволен. конечно, всегда можно лучше и Ещё Более Идеально… но не всегда нужно. |
|
|
![[info]](http://lj.rossia.org/img/userinfo.gif){kind=small}