UnigramDev/Unigram/formatted-text-block-dates • 42d021b • 1 files, +9/-0
Note that a spoiler cannot contain a date

Found while building the test set: the server splits a spoiler around a date
rather than letting them overlap. So the branch that stretches a spoiler around
a growing date is unreachable for dates, and stays live only for the marked and
cached highlighters, which the app builds itself.

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

UnigramDev/Unigram/formatted-text-block-dates • 090790a • 2 files, +45/-13
Anchor the dates in seconds, since the formatter counts seconds

I had read RelativeDate, which falls back to "just now", rather than
RelativeDateAgo, which is the one InAgo calls and which ends in
Declension(SecondsAgo, value). So the text does tick per second, and the width
changes at 2s, 10s, 60s, 2min, 10min and an hour.

Anchoring at eight seconds gives three width changes inside two minutes instead
of one, with the counter visibly running in between.

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

UnigramDev/Unigram/formatted-text-block-dates • 98d5640 • 3 files, +49/-8
Release the relative dates without waiting for Unloaded

ClearBlocks drops its blocks and leaves teardown to the Unloaded event, and
FrameworkElementEx only raises OnUnloaded for an element it saw Loaded on. A
block subscribes from SetText, which runs from OnApplyTemplate, which runs on
the first measure - before Loaded. Dropped in between, it never releases, and
what it holds is a registration in the thread-static RelativeDateService: the
block, its paragraph and its runs pinned for the session, still being ticked.

The other half needs no assumption about when Loaded arrives. The service is
keyed by the Run, and Runs come from the shared pool, so one registration that
outlives its block made that Run unsubscribable for good - every later block
that dequeued it had its date silently never update. Subscribe replaces the
entry now instead of skipping, since a Run being resubscribed always means the
old registration is dead.

Runs still return to the pool through OnUnloaded alone. A missed pool return
costs an allocation rather than a pinned graph, and giving Clear a second path
into the pool wants the recycling audit rather than a guess.

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

#unigram