["J.P"] Re: declarative syntax to ERC show/hide messages by "type"

[J.P.]

Thought this might be of general interest to ERC more broadly. No need
to follow up here, though.

-------------------- Start of forwarded message --------------------
From: F. Jason Park <jp@neverwas.me>
To: Corwin Brust <corwin@bru.st>
Cc: Amin Bandali <bandali@gnu.org>
Subject: Re: declarative syntax to ERC show/hide messages by "type"
Date: Fri, 11 Feb 2022 00:52:17 -0800

Corwin Brust <corwin@bru.st> writes:

>> excuses. Anyway, such an exercise would probably involve examining the
>> function erc-hide-current-message-p (and the options it relies on,
>> namely erc-hide-list and friends) and maybe also the match and netsplit
>> modules. (I think you've already looked into stamp, right?)
>
> A bit, I need to look deeper, and into the other modules you mentioned.

Hmm... I'm a bit hard pressed to recall what I was getting on about
exactly, perhaps something to do with consolidating overlapping
functionality involving message hiding or contextualizing options. As
for the latter, I still feel it might be nice to devise a universal way
of offering more granular, context-aware control over (not just new, but
also existing) ERC options.

>> Whether your module grows to encompasses concerns beyond hiding, a
>> natural expectation might be that some existing hide-related
>> functionality be moved under its purview and some deduping occur as a
>> result, such as the deprecating of erc-*hide-list.
>
> I agree, I'll look into making erc-hide-lines honor erc-*hide-list, indeed.

Actually, it may be cleaner (in a separate initiative/change set) to
preemptively convert `erc-hide-list' into a proper module. It's
currently woven throughout core for no reason and makes the code base
less readable. And if/when this module (hide line) is incorporated, such
a move will have served double duty (as something like burial prep), at
which point some verbiage in the Commentary header can explain as much,
saying that it's been superseded or whatever.

> In any case, dropping support (however much in the future) for
> existing modules and their present functionality isn't something I'd
> like to focus on until there is a stable form of this feature and
> additional feedback from users.

After learning more about responsible stewardship from bandali in the
course of working on other patches, I no longer consider it sane to just
drop support for something straight away but rather, when warranted, to
engage in the ritual process of (molasses-like) deprecation.

> Yeah and.. your reasoning seems sound and correct to me.  So.. as a
> roadmap: yes, but not as an immediate priority. Let me know if this
> doesn't sound right or comes across as line noise?

Cheers. I'd like to get something semi-formal (but flexible) going in
the roadmap department, but I've only ever leaned on enterprisey tools
for such things (which is obviously a no-go here). Guess I'll see what
Savannah has on offer.
-------------------- End of forwarded message --------------------