[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#72736: 31.0.50; ERC 5.6.1: Keep ban lists in sync
From: |
J.P. |
Subject: |
Re: bug#72736: 31.0.50; ERC 5.6.1: Keep ban lists in sync |
Date: |
Sat, 24 Aug 2024 11:03:45 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
"J.P." <jp@neverwas.me> writes:
> +(cl-defmethod erc--handle-channel-mode (_ (_ (eql ?b)) state arg)
> + ;; Add or remove a ban from `erc-channel-banlist'.
> + (erc--banlist-update state arg))
Both for clarity and compatibility with the current behavior, I think we
should instead keep `erc-channel-banlist' empty (and locally unbound)
until formally initialized for a given channel within an ERC session. An
easy way to do that would be to guard the above like so:
(when erc--channel-banlist-synchronized-p
(erc--banlist-update state arg))
> +
> ;; We could specialize on type C, but that may be too brittle.
> (cl-defmethod erc--handle-channel-mode (_ (_ (eql ?l)) state arg)
> "Update channel user limit, remembering ARG when STATE is non-nil."
As far as re-syncing on reconnect, that's probably better handled by an
actual module (if anyone feels like writing one). We could move all the
ban-list stuff to a new file and maybe offer an alternate display style
for interactive use, perhaps one based on `tabular-list-mode' or
similar.