[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#59805: 28.2; erc-track: handle faces modified with erc-button-ad
From: |
Nacho Barrientos |
Subject: |
Re: bug#59805: 28.2; erc-track: handle faces modified with erc-button-add-face |
Date: |
Tue, 06 Dec 2022 17:06:18 +0100 |
User-agent: |
mu4e 1.8.9; emacs 28.2 |
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