>Really appreciate the thorough testing -- and your patience even more so
>because as much as I'd like to put a bow on this, it turns out (sigh)
>there's one lingering matter yet unresolved.

*Ahem* I apologize for opening this can of worms really. Didn't quite
expect a simple question regarding spoiler rendering to result in this
amount of Erc hackery :)

> [1] https://modern.ircdocs.horse/formatting#reverse-color

Good call. I am aware of this reference (as any IRC tinkerer should
be), and indeed, Erc should handle ^V and ^C99,99 [1], even though
both are "Not universally supported".

I gave the patches another look and did another clean re-apply for an
additional test. All OK (results seen in the attached screenshot).
Implementing ^V using :inverse-video should be okay, although I'm not
sure about the implications on platforms that do not support that (do
any exist? documentation here is sparse, unfortunately). I assume it
will fall back to the hard-coded white-on-black color specification in
that case, which is probably an acceptable compromise.

Cheers,
FM

[1] subtle edge case which shouldn't be formatted as a spoiler, even
though X=Y=99 in ^CX,Y (Again, good catch, thanks for that)

Am Sa., 9. März 2024 um 17:06 Uhr schrieb J.P. <jp@neverwas.me>:
>
> Fadi Moukayed <smfadi@gmail.com> writes:
>
> > That said, I'd like to +1 the changeset and confirm that the proposed
> > changes apply cleanly, and yield the desired result. I tested inputs
> > of the form ^CX,X<text>^C on a temporary private channel – spoilers
> > are formatted and revealed as intended, and no regressions were
> > observed. Very nice. Would be a neat addition/fix for the next Erc
> > release.
>
> Really appreciate the thorough testing -- and your patience even more so
> because as much as I'd like to put a bow on this, it turns out (sigh)
> there's one lingering matter yet unresolved.
>
> Alas, looking more closely at how `erc-controls-propertize' treats
> `erc-inverse-face' (crucially, as a modifying toggle [1]), I've quickly
> come to rue the day I ever thought to suggest otherwise, especially in
> drawing misguided associations with `erc-spoiler-face'. (Indeed, my
> quasi-conflating the two was what led us astray to begin with.) So, if
> not already clear, I now believe we should just treat `erc-spoiler-face'
> as its own concern entirely and not have it inherit from
> `erc-inverse-face'. All this to say: yet another revision attached.
>
> Thanks, and apologies for the head fake.
>
> [1] https://modern.ircdocs.horse/formatting#reverse-color
>
>