Alcor <alcor@tilde.club> writes:

> "J.P." <jp@neverwas.me> writes:
>
>> Oof. Looks like `erc-get-fg-color-face' sets `erc-control-default-bg' in
>> its catch-all `cond' case. As you say, this produces:
>>
>>   #("THIS TEXT IS FORMATTED"
>>     0 22 (font-lock-face (erc-control-default-bg bg:erc-color-face4)))
>>
>> And `erc-get-bg-color-face' sets `erc-control-default-fg'. Clearly,
>> whoever's responsible for this outrage should be banished. (Thanks.)
>
> Yes, that's part of the issue. However, `erc-controls-propertize' should
> also avoid adding the default fg/bg to the font lock face if n=99 to
> avoid overriding an existing fg,bg setting if fg=99,bg=x or bg=99,fg=x.

Here's my current understanding of what you're saying. When there's an
existing fg/bg combo in effect for a given span, and the parsing logic
encounters a ^Cx,99 (or a ^C99,x), the 99 shouldn't induce a clobbering
of the corresponding "incumbent" fg (or bg) face with a dedicated (and
superfluous) default face but instead trigger the _removal_ of said
incumbent face. This has the effect of falling through to honor the
relevant attributes of the underlying `erc-default-face', which ships as
a no-op. For example, given

  ^C03,08 hello ^C99,07 world

the "hello " portion should be green on yellow and " world" should be
${default-foreground} (likely black or white) on orange. Likewise, if
"^C99,07" were instead "^C04", then " world" should be red on yellow.
This behavior aligns with that exhibited by Weechat and (I'm hoping)
other popular clients. The revised patch set (attached) attempts to
mimic this in ERC. Corrections or alternatives welcome. Thanks.