Re: bug#73580: 29.4; ERC 5.6.1-git: erc-nicks does not respect pal and fool faces
Trevor Arjeski <[email protected]> Wed, 02 Oct 2024 10:40:25 +0300
| Newsgroups | gmane.emacs.erc.general |
|---|---|
| Message-ID | <[email protected]> |
"J.P." <[email protected]> writes: Agreed that it's not good to couple nicks and match. > Thanks for the bug report. The good news is I can definitely reproduce > this. :) > > But whether it's a bug and how to go about addressing it is a bit more > involved, I'm afraid. As luck would have it, this issue or something > similar actually comes up every now and again but not so much in the > context of `nicks' (or `erc-highlight-nicks' before it). > > Anyway, as you may have noticed, the `nicks' module formally depends on > the `button' module and a new (5.6+) `button'-provided interface: > `erc-button--modify-nick-function'. IMO, this coupling is an acceptable > trade-off because `nicks' can piggyback on the token scanning that > `button' provides. The `button' module itself runs its code at depth 30 > on `erc-insert-modify-hook', which is earlier than the `match' module's > 50. This means it applies its faces _before_ `match' ever touches > them. I see now. I did notice the depths being different but couldn't really grok what was going on at the moment and went for more of a "hack it till it works" approach. > What probably threw you off in perhaps thinking `match' had a say before > `nicks' was the presence of useless faces from `match' in the default > value of the option `erc-nicks-skip-faces'. That's indeed my bad: they > shouldn't be there at all (and a patch to fix this would be most > welcome). To that end, I'd much prefer we kept `nicks' and `match' as > loosely coupled as possible for the sake of long-term maintainability, > although I'm sure your current proposal is quite effective from a purely > pragmatic POV. I did notice this and tinkered with it, but didn't really find anything significant when removing the pal and fool faces from it. Thanks for the detailed explanation. I did go through with the "traditional" approach of adding 'nick-or-keyword, but sadly gave up. Honestly, the more I looked at ERC, the more I realized that I don't want pals to be highlighted at all. This makes my first patch irrelevant since the whole idea is to use one single face color every time a nick appears (similar to weechat's nick highlighting). The same goes for a fool, who may appear dimmed, but when someone else mentions the fool you will see their nick as the color that erc-nicks assigns. > If you're saying `nicks' _should_ highlight your own > speaker tags (or should optionally do so), please explain. This is again about consistency with seeing your own nick within brackets (<your_nick>) and in messages that other people send (when erc-current-nick-highlight-type is 'nick-or-keyword). Not sure what to do! I think we can just close this bug for now.