Re: bug#67767: 30.0.50; ERC 5.6: Add track integration to the nicks module

[J.P.]

"J.P." <jp@neverwas.me> writes:

> ERC's `nicks' module doesn't currently play nice with `track'. Enabling
> it breaks the cycling effect normally occurring among faces in
> `erc-track-faces-normal-list' [1].
>
[...]
>
> [1] Although, what we typically perceive as this effect is somewhat
>     illusory, if not underrealized. See comments preceding the new tests
>     in the first patch.

It's been pointed out that the most recent attempt at improving the
situation, especially with regard to the option `erc-nicks-track-faces',
ended up perpetuating rather unintuitive aspects of the original
behavior in certain common situations. While the particulars are tedious
to lay out, a somewhat relatable example is a speaker with a
`nicks'-owned face speaking immediately after an inserted JOIN message
(displayed in `erc-notice-face'). Based on the doc string of
`erc-nicks-track-faces', you'd think the `track' segment would favor the
`nicks'-owned face, but that's not currently so. The attached patch aims
to rectify this as well as address other, similar surprises.

Another problem with the current "normals" behavior is that it fails to
adequately exhibit the "flickering" effect when `nicks' _isn't_ enabled.
You can see this by connecting using the default configuration. Notice
that the mode-line segment stays on `erc-default-face while users are
conversing so long as they don't mention one another. However, the
"normals" feature was always meant to provide more responsive feedback
to clearly indicate active conversations (including monologuing). The
patch tries to address this by adding the default buttonized speaker
face to the related options `erc-track-faces-priority-list' and
`erc-track-faces-normal-list'. If there's a smarter way, hopefully
someone will speak up.

Thanks.

0001-5.6.1-Fix-prioritize-variant-of-erc-nicks-track-face.patch
Description: Text Data