all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





  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.