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

> In terms of proposals, I think a successful candidate for adoption
> should provide at least two working demos, preferably among the
> following:
>
>   - Bidirectional input and display
>   - Headline style messages w. speaker on a separate line
>   - Text substitution (language translation, encryption, etc.)
>   - Display names (e.g., for bridges, perhaps reversible)
>
> My guess is this feature won't be ready for ERC 5.6, especially without
> explicit interest from others. As such, proposals (from me) may be based
> atop work that includes changes not currently on HEAD, such as those
> from #49860.

In the absence of a coherent proposal for a revamped message preparation
and insertion API, I believe it may be wise to collect counterexamples
exhibiting some of the desperate and ugly measures taken to access the
various components of a message and influence its assembly for display.
The objective here is to emphasize the considerable shortcomings
currently on offer in this regard.

To that end, I've attached an adapted version of a POC from another bug
(#49860) as a working, practical example of the problem. It attempts to
introduce speaker display names for bridge bots by way of a new module.
To be clear, this is not being proposed for inclusion in ERC 5.6 (or any
subsequent version). Rather, its purpose is in keeping with the
aforementioned goal of underscoring the deficiencies of the current
situation. Of particular note is the fourth patch and the terrible
lengths it goes to in order to access and manipulate the content portion
of chat messages before they're fused to their leading "<speaker> "
prefixes.

Folks at home: even if you don't try this patch set, please look at the
module setup code and the interfaces it consumes. And please do post
your own scenarios here. They need not come in the form of patches or
include any working code.

Thanks.