[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Draft patch: Supporting buffer-local `erc-hide-*'
From: |
J.P. |
Subject: |
Re: Draft patch: Supporting buffer-local `erc-hide-*' |
Date: |
Fri, 22 Nov 2024 13:07:55 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Alcor <alcor@tilde.club> writes:
> Hi Erc'ers,
>
> I've tried modifying Erc to support buffer-local erc-hide-*
> variables. The idea is to support message type filtering per channel
> buffer, which is useful for "noisy" channels.
It would indeed be nice to have official support for buffer-local
bindings of user options. There's been some spitballing in this area in
recent years involving local modules, possibly in tandem with the
elusive dream of a reborn `erc-settings'. As of yet, though, there's not
really even implicit support, other than for the odd local option, like
`erc-ignore-list'.
> Attached is a patch with an implementation idea, which I have tested out
> for a couple of hours. The approach is as follows:
>
> 1. Extract out a function `erc-buffer-expand' (perhaps a different name
> might be better?) from `erc--route-insertion' that normalizes Erc's
> buffer specification values to lists.
>
> 2. Add a helper `erc-hide-current-message-in-buffer-p' that evaluates
> `erc-hide-current-message-p' in a (with-current-buffer ...) context.
>
> 3. Modify `erc-display-message' to use #1 & #2, ensuring only non-hidden
> messages as per the predicate from #2 get inserted.
>
> Feedback welcome. I'm still a bit dissatisfied with some aspects of the
> patch and am left wondering if there's a way to avoid adding an extra
> argument to `erc--route-insertion'. Testing on a number of IRC channels
> with (setq-local erc-hide-list '("PART" "JOIN" "QUIT")) while comparing
> with the defaults yields good results however, with all specified
> messages being correctly filtered out.
In general, I'd like to reserve more involved changes until after we
migrate the `erc-ignore' group of options, which includes all the "hide"
stuff, to their own module in a separate file. (I've managed to dredge
up a recent convo from Libera touching on this, which I'll send you out
of band.) Anyway, we could always coordinate so everything's done as
part of the same larger initiative. If we're talking 5.6.1 specifically,
I'd probably be open to a bug fix for #68646, if the footprint were
light enough. Otherwise, we should probably save any enhancements until
the migration.
>
> Cheers,
> -A.
>
> PS: Regarding the terminology - "erc-hide-*" feels slightly
> misleading. I'm not familiar with Erc's internals but I have not found a
> way to "unhide" messages, so this feature (as it is) is more of
> "discard" or "drop" compared to the similarly-named functionality in
> Circe, which is reversible.
This has come up before, most recently in regard to Corwin's
erc-hide-line package (IIRC). It's possible to deprecate the "drop"
meaning and redefine "hide" to mean "make invisible", but only as long
as the old behavior is still accessible via some knob. FWIW, ERC does
have an existing facility to hide messages in a reversible fashion (see
`erc-hide-fools' and `erc-match-toggle-hidden-fools'). The same
treatment could be applied to almost any inserted message, I believe.