From: "J.P." <jp@neverwas.me>
To: 72736@debbugs.gnu.org
Cc: emacs-erc@gnu.org
Subject: bug#72736: 31.0.50; ERC 5.6.1: Keep ban lists in sync
Date: Sat, 24 Aug 2024 11:03:45 -0700 [thread overview]
Message-ID: <87msl123y6.fsf__42460.757475213$1724522683$gmane$org@neverwas.me> (raw)
In-Reply-To: <87plq3551s.fsf@neverwas.me> (J. P.'s message of "Tue, 20 Aug 2024 13:10:23 -0700")
"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.
next prev parent reply other threads:[~2024-08-24 18:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-20 20:10 bug#72736: 31.0.50; ERC 5.6.1: Keep ban lists in sync J.P.
2024-08-24 18:03 ` J.P. [this message]
[not found] ` <87msl123y6.fsf@neverwas.me>
2024-09-05 21:58 ` J.P.
[not found] ` <87mskl3gpv.fsf@neverwas.me>
2024-10-01 0:15 ` J.P.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='87msl123y6.fsf__42460.757475213$1724522683$gmane$org@neverwas.me' \
--to=jp@neverwas.me \
--cc=72736@debbugs.gnu.org \
--cc=emacs-erc@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.