bug#59805: 28.2; erc-track: handle faces modified with erc-button-add-face

Hi J.P.,

On 06/12/22, J.P. said:

> Thanks for submitting this proposal. I have yet to form any opinions
> about it but promise to eventually. In the meantime, I'll mention some
> broadly related observations I happened to make while looking at it
> briefly. Some are likely of less interest to you, but I'll state them
> here anyway for lack of a better venue.

Thanks for taking the time to do this; your insights have been useful
for me to learn new stuff. As I mentioned I'm rather unfamiliar with
ERC's code *grins*.

> Looks like the default value of `erc-track-faces-priority-list' contains
> some composite faces, such as
>
>   (erc-nick-default-face erc-current-nick-face)
>
> So whatever happens, I think we'll have to preserve compatibility for
> people already used to searching for such composites.

I was totally unaware that "face composites" were a thing, so
perhaps my proposal to flatten the return value of `erc-faces-in' does
not make sense anymore.

> In fact, have you tried adding
>
>   (erc-hl-nicks-nick-nacho-face erc-current-nick-face)
>
> to `erc-track-faces-priority-list' while also overriding the function
> `erc-hl-nicks-face-name' with something like this?
>
>   (lambda (nick) (intern (concat "erc-hl-nicks-nick-" nick "-face")))
>
> If that shows any promise, it could probably only ever manifest as a
> user option for a select subset of declared nicks, so as not to inundate
> the global obarray with ERC spam.

This is indeed what I did initially in my configuration, before I
thought about reporting this bug. This approach works, however in my
opinion it's not ideal (for me as user), because:

1) I have to monkeypatch erc-hl-nicks.
2) I have to hardcode the nick-dependant face name to look for. There's
   already a face to identify mentions to the current nick
   (`erc-current-nick-face') so this should not be necessary.

1) could be addressed by submitting a patch for erc-hl-nicks so those
symbols are interned so they could be `equal''ed, as you suggested.

For 2) I don't have an elegant/generic solution to propose, but adding

  (erc-hl-nicks-nick-nacho-face erc-current-nick-face)

to `erc-track-faces-priority-list' can definitely work for me. My
nickname is stable across networks, however I think that the rather
valid use case of being notified no matter what your nick name is cannot
be honoured elegantly when using erc-hl-nicks.

--
 bye
 Nacho
 http://cern.ch/nacho