GNU bug report logs - #72736
31.0.50; ERC 5.6.1: Keep ban lists in sync

Previous Next

Package: emacs;

Reported by: "J.P." <jp <at> neverwas.me>

Date: Tue, 20 Aug 2024 20:12:01 UTC

Severity: normal

Tags: patch

Found in version 31.0.50

Done: "J.P." <jp <at> neverwas.me>

Bug is archived. No further changes may be made.

Full log


Message #11 received at 72736 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 72736 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#72736: 31.0.50; ERC 5.6.1: Keep ban lists in sync
Date: Thu, 05 Sep 2024 14:58:52 -0700
[Message part 1 (text/plain, inline)]
v2. Only update `erc-channel-banlist' if initialized. Redo shared hook
mechanism for buffer truncation.

"J.P." <jp <at> neverwas.me> writes:

> 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))

I've done this in the latest set of patches (attached).

I've also tacked on a reworking of the rather awkward hook mechanism by
which modules can run code prior to a buffer's truncation. This was
previously handled by the abnormal hook `erc--pre-clear-functions',
which was run by both the `truncate' module and the `erc-cmd-CLEAR'
slash command. Part of this overhaul involved deferring most of the code
that formerly ran on `erc-insert-done-hook' to a per-response, ephemeral
`erc-timing-hook' member.

The main reason for this move is to escape the insertion related context
imposed on such hooks by response-handling code further back in the call
stack. We're not inserting anything, so it makes little sense to abuse
such hooks for their side effects, which is a design flaw and a common
antipattern (though an excusable one, seeing as there's no real sensible
alternative). Regardless, deferring to a known call site over a limited
extent via `erc-timer-hook' seems far more predictable and manageable
than relying on `run-at-time' or similar.

[0000-v1-v2.diff (text/x-patch, attachment)]
[0001-5.6.1-Rename-internal-variable-in-erc-fill.patch (text/x-patch, attachment)]
[0002-5.6.1-Store-one-string-per-user-in-erc-spkr-msg-prop.patch (text/x-patch, attachment)]
[0003-5.6.1-Bind-current-erc-response-around-all-handlers.patch (text/x-patch, attachment)]
[0004-5.6.1-Fix-inconsistent-handling-of-ban-lists-in-ERC.patch (text/x-patch, attachment)]
[0005-5.6.1-Fix-overlooked-case-in-erc-get-inserted-msg-be.patch (text/x-patch, attachment)]
[0006-5.6.1-Redo-ERC-truncation-and-CLEAR-hook-mechanism.patch (text/x-patch, attachment)]

This bug report was last modified 229 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.