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

> The same general thinking applies to the nicks-specific buttonizer as
> well, though it being intrinsically special and, for now, internal means
> we can take more liberties in inconveniencing its consumers (which are
> all built-in modules). Thus, I'm proposing we replace the slightly
> unwieldy set of positional params with a single passed-around struct,
> which members of the interface's "advice stack" can modify at will. See
> implementation for details.

Previously, consumers of the new nick-buttonizer interface were given a
look at every single word in a message. But they should only really care
about those with an associated `erc-server-user' object, meaning known
nicks. And while it's true that some might want to create these
associations on the fly, I think they're better off doing so earlier on,
both to help separate concerns and to skip the hassle of determining
whether a candidate is a speaker or a mention.

To that end, I've carved out a couple more access points to influence
how nick buttonizing happens. Both use the same pattern of "local advice
around a function-interface variable," which I've come to regard as the
most predictable and flexible for building new internal APIs. The first
lives in `erc-server-PRIVMSG' and integrates with the old
`erc-format-nick-function', which takes the user object it spits out.
The second runs right before the nick buttonizer but only as a fallback
when the usual means of finding an `erc-server-user' object from a
candidate fails. It's set to `ignore' by default.