UnigramDev/Unigram/formatted-text-block-dates • e7e25f0 • 2 files, +191/-55
Keep spoilers and copy offsets in step with relative dates

A relative date rewrites itself in place, and three things downstream are
expressed in coordinates that move when it does: the spoiler geometry, the
highlighter ranges that hide the text, and the index map the selection layer
reads. Only the first was maintained, from OriginalOffset plus a delta measured
against the source length - which is the total growth since the first render, so
applying it on every tick, and once per date, compounded. The ranges were a
commented-out block, and nobody had noticed the index map at all.

Geometry is now derived rather than stored: TextStyleSpoiler holds source
offsets and DisplayedRange works out where the spoiler currently sits from the
paragraph's runs, so any number of dates in any order land in the same place.

Rendered space is shifted instead, by the change since the last tick, from the
map segment each date now remembers - which is also what fixes copy in any
message with a relative date, spoiler or not.

Two more from the same root: a spoiler's range took the source length, so a
spoiler wrapping a date was short from the first render - it is now measured
from what was emitted. And the two halves of UpdateSpoilers disagreed about
whether the offset was date-expanded, which deriving per branch settles.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/formatted-text-block-dates • a22e3b4 • 1 files, +226/-0
Add a test plan for both branches

Markdown covers most of it, since ParseMarkdown runs on send. Dates do not have
a markdown syntax, so those come from the composer's formatted date item, and
part C starts by confirming the entity survives the round trip at all - if it
does not, nothing downstream of it is testable that way.

Each item says what wrong looks like, because most of these fail by a couple of
characters rather than by crashing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/formatted-text-block-dates • f51bf97 • 2 files, +247/-30
Send the test messages from a script, and correct two cases

The Bot API does carry the date entity, as date_time with unix_time and
date_time_format. Worth knowing that unknown extra fields are accepted and
ignored, so a wrong field name leaves the format empty and the date renders as
plain text - it looks like the feature is broken rather than the request.

Two cases in the plan could not exist. A spoiler may not overlap a date: the
server splits the spoiler around it rather than rejecting the message. So a date
inside a spoiler is not a state the app can be given, and the stretch branch of
ShiftRanges is unreachable for dates - it stays live only for the marked and
cached highlighters, which the app builds itself.

The split is the better test anyway. T10 now sends a spoiler spanning a date and
gets two covers back, one either side, which have to do different things across
the same tick: the one in front stays, the one behind moves.

The script takes the token and chat as arguments and carries neither.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

#unigram