Задача - протестируй свой рендер

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

блэт ты понимаешь как TextView процессоры рендера устроены?

что ты там блять сравнивать собрался?

лил

для гуев нормально еще e2e относительно, и то не везде

это тебе не web dom

что ты там блять сравнивать собрался?

Исходную викиразметку с выходным буыфером

В Рич тексте

Или чем там?

Исходную викиразметку с выходным буыфером

лыл

щас расплачусь нахуй

выходным буфером?

Это грубо говоря тупо само дерево протестит

Нету выходного буфера?

ну окей, я сделаю тесты рекурсивные для узлов что он их правильно обрабатывает и инлайнит

и что?

Нету выходного буфера?

блэт выходной просто json

в котором по пизде едет все и вся

Как ты из жсона получаешь текст буфер с визуальной хуйней

изза того что "парсер из ада" не умеет в инлайны

У ГТК точно есть язык разметки

он может только выделять шаблоны и определенные куски текста

Или ты как-то по особому это делаешь

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

У ГТК точно есть язык разметки

у label есть, 3 тега, и те по пизде

а я textview юзаю

Т.е. я правильно понимаю у тебя преобразование Wiki ast -> text + span атрибуты?

блэт ты понимаешь как TextView процессоры рендера устроены?

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

Или из чего текст вию вообще рендерит

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

нахуя мне данные обратно в вики код возвращать?

или какой особый смысл тестить структуры выходные

на питоне

Ещё раз

когда мне надо сделать парсер для раста

с другой архитектурой и подходом

Т.е. я правильно понимаю у тебя преобразование Wiki ast -> text + span атрибуты?

.

Всмысле другой архитектурой?

Т.е. я правильно понимаю у тебя преобразование Wiki ast -> text + span атрибуты?

Есть wikitext он превращается сначала в рекурсивную струкутру из узлов привязанных к тексту, потом я делаю инлайнинг - разбиваю строку по типу: [ text_note, tag[text_node, tag, template], template, ..etc ] После чего делаю перебор и вставляю в конец буфера, при этом к конкретному буферу сразу же нельзя поставить пометку (специфика работы textview процессора), и сохраняю текст например тега определенного, потом я ищу этот текст и применяю к нему тег.

Ну вот у тебя есть два места где можно тесты написать

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

ну ваще никак

1) взять wiki -> json ибо это представление и в расте останется, без этого сразу никак

А второе json ast -> в данные твоего инлайнера

ну это можно сказать будет удобно если парсер на расте писать с одной стороны

?

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

ибо тот что сейчас конченый прям по всем фронтам

Ну от аст ты не избпвишься

Точнее незачем

неа

изначальный ast будет в любом случае

я говорю о структуре инлайнера

и способов обработки дерева

мне не нравится что питоновский парсер отдельно куски берет

Яснл

при чем по байтам порой проебывается

Всмысле отдельно куски

Что тесты должны проверить? Что всё парсится так же корректно, как и до преобразования. Что все функции выполняются. А что ещё проверять? В твоём случае проще будет сразу на расте с тестами писать. Сравнивать структуру со структурой в тестах будет очень болезненно. Сравнивать строку "[[заголовок]]" с аналогичной строкой "[[заголовок]]" будет значительно проще, даже если внутри все распарсенные структуры десять раз поменяются, как оно хранится.

тоесть что он дает: вот у тебя текст, ты его парсишь - получаешь wiki узел. И из этого узла ты можешь запросить массивы типов разметок: тоесть Node: get_templates, get_filters, get_tags, и тд, которые тоже являются узлами, и хранят свой кусочек вики текста

в итоге получается абсолютно неудобный инлайнинг

просто дико неудобный

А как ты хочешь

ска я сохраняю ранжи текста, типо range_node = (my_global_text.find(tag_text), len(tag_text))

причем рекурсивно

и потом по этим ранжам начала узлов тегов и тд

я определяю фором обычным какие диапазоны у мест где реально текст

А как ты хочешь

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

Почему ты сам не можешь обойти АСТ и заинлайнить

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

Почему ты сам не можешь обойти АСТ и заинлайнить

въебывание на ранжах и эскейпинге тегов шаблонов и тд

Ну короче, это по любому не часть парсера

с одной стороны да, с другой нет

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

Наложение поверх плейн текста?

Имхо у тебя требования какие-то пиздецовые

Опиши их формально

Чтоб мы посмотрели и сказали где ты не прав

Ну смотри например у меня есть строка типо: === Прощай Мир === '''Жирный тег {{template | с еще одним темплейтом внутри 'курсивчик'}}''' - некий ебаный текст, [тыкни сюда|ссылочка епт] AST это превратит сначала в рекурсивные ноды с разными типами, питухон просто выдаст мне массивы типов шаблонов из этого текста, которые я потом сам должен буду раскрывать рекурсивно в структуру. И потом инлайнер должен будет запоминать ранжи типо: [(25, 65, "template", my_node), etc..] И потом делать разбивку и определять что вот тут между тегами у меня есть обычный текст, и так опять таки фором инлайнить по очереди ранжей псевдорекурсивно. А я хочу чтобы он без рекурсии сразу определял мне основной плейн текст типо: Прощай Мир Жирный тег с еще одним темплейтом внутри курсивчик - некий ебаный текст, тыкни сюда И уже заранее имел глобальный рендж без текста вроде: [(0, 25, "heading"), (25, 45, "text"), etc...] Причем не на последней стадии, и без лишней рекурсии, с двойным поиском текста как это вынуждено сделано сейчас.

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

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