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

[Nacho Barrientos]

Hi again,

On 06/12/22, Nacho Barrientos said:
> 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.

Actually there's something else that can be done from the erc-hl-nicks
side, which is:

  (setq erc-hl-nicks-skip-nicks '("nacho"))

Which comes again with the problematic of having to hardcode known nicks
but it does the job. If that variable is set as indicated above,
erc-hl-nicks will never create the composite face on the mention and
hence:

  λ> (erc-faces-in (buffer-substring (point) (+ 1 (point))))
  (erc-current-nick-face)

(in the example above, `point' is on a mention to the current nick)

Making erc-track's matching work. The current nickname is coloured
anyway by ERC so if erc-hl-nicks does not act on it should be okay.

This approach is good enough for me so feel free to close the bug if you
don't want to go down this rabbit hole further :)

Thanks again.

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