Re: Draft patch: Supporting buffer-local `erc-hide-*'
"J.P." <[email protected]> Fri, 22 Nov 2024 13:07:55 -0800
| Newsgroups | gmane.emacs.erc.general |
|---|---|
| Message-ID | <[email protected]> |
Alcor <[email protected]> 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.