Re: Stray/unreferenced timeouts in erc-cmd-IGNORE?

[J.P.]

Alcor <alcor@tilde.club> writes:

> Hi Erc'ers,
>
> in erc.el (erc-cmd-IGNORE), the following lines exist
> (rev. a5fbb652ed3614d6735015551564f32b80e42c53):
>
>         (let ((timeout
>                (erc--read-time-period
>                 "Add a timeout? (Blank for no, or a time spec like 2h): "))
>               (buffer (current-buffer)))
>           (when timeout
>             (run-at-time timeout nil
>                          (lambda ()
>                            (erc--unignore-user user buffer))))
>
> One thing immediately comes to mind: The timeout is unreferenced, and is
> not stored in any (a)list, so it's not possible to cancel it.
>
> If I'm reading the code correctly, it does not seem to check if a
> timeout for unignoring the given nick already exists either. So
> re-ignoring the same nick with a different timeout would create an
> *additional* timeout.

Yes, keeping tabs on these by retaining a handle while they're still
ticking seems like a good idea.

> Is this right? Please do tell if this is a known issue

Off hand, I don't recall anyone ever mentioning it specifically, but the
ignore and lurker family of features contain many rough edges, some of
which are raised and reraised periodically. In fact, among our many
TODOs is migrating everything in the `erc-ignore' and `erc-lurker'
groups to their own module(s) in at least one separate library, while
also overhauling their functionality to prefer leveraging Emacs'
invisibility-spec machinery so that ignored messages are still inserted,
just hidden from the user. There's even an older PoC tackling some of
this mission floating around somewhere, but it lacks test coverage
nailing down the current behavior, which we'd still need to preserve
somehow, e.g., via compatibility switches.

In any case, future plans shouldn't prevent us from improving the
current situation. If that's something you (or someone out there) feels
like taking on, please do.

> and whether I should open a bug for it.

Yes, please open a bug if you don't mind. As to whether the lack of
cancelability constitutes a formal bug in this case, who really knows?
While it's definitely undesirable, I'm not sure we can prioritize fixing
it without an attendant patch. IOW, please don't feel slighted if I mark
it as a wishlist item initially.

Cheers.