GNU bug report logs - #73798
31.0.50; ERC 5.7: New extensibility focused match API

Previous Next

Full log

View this message in rfc822 format

From: "J.P." <jp <at> neverwas.me>
To: 73798 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: bug#73798: 31.0.50; ERC 5.7: New extensibility focused match API
Date: Wed, 13 Nov 2024 13:06:49 -0800

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

> v3. Replace `erc-match-types' with `erc-match-functions', an actual
> (abnormal) hook. Update docs as mentioned in previous post.

In the imagined use cases described up thread, it likely won't be
uncommon for a module to manage multiple match types, with multiple
members in `erc-match-functions' and `erc-text-matched-hook'.

Related predicates, handlers, and methods may therefore need to
communicate across matches, for example, to know whether a match has
already occurred for the current message. So it may well make sense to
add another slot to the base type whose value is shared among all
objects during matching and filtering. An alist probably makes the most
sense for this.

If knowledge of prior matches turns out to be desirable and commonplace
enough, we can keep and expose a record of all successful matches.
(Doing this might further justify the current "split" design with its
distinct predicate and handler phases.) One slight challenge here would
be the necessity for some form of indirection to access such a record
(because tacking on a list of prior match objects as a visible "has a"
property of later objects would make printing them somewhat nasty). So,
instead of another slot, we could maybe offer an object-retrieval
utility keyed by constructor function.

Previous Next

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