Re: bug#60936: 30.0.50; ERC >5.5: Add erc-fill style based on visual-line-mode

[J.P.]

Changes related to this feature introduced a number of meta-data
oriented text properties that I think, in retrospect, should have been
double-hyphenated to dissuade users from depending on them. Also, a
couple of properties, like `erc-stamp-type', are superfluous, and can be
removed. The first of the attached patches should take care of this.

There's also (IMO) a rather obvious need for an `erc--spkr' property to
aid modules in quickly distinguishing between inserted messages based on
their speaker (nick). For example, a module that detects continued
messages that should be displayed as a single unit might otherwise have
to keep a local backlog or parse inserted messages at runtime. The
second of the attached patches tries to address this.

Lastly, in "designing" the makeup of these properties, I chose to assign
a constant `msg' value for the required `erc--msg' property to all
speaker-owned messages, like those originating from PRIVMSG and NOTICE
commands. The idea was to allow modules to distinguish between speaker
messages and other types. However, making `erc--msg' a union of `msg'
and `format-spec' "catalog" keys (and `erc-display-message' TYPE
parameters) meant coercing keys for speaker messages to `msg', thereby
discarding what now looks to be valuable information (especially in
light of bug#67677). Thus, I'm proposing we remove `msg' as an
advertised `erc--msg' value and instead rely on `erc--spkr' to convey
speaker associations. See bug#67677 for more.

0003-5.6-Double-hyphenate-internal-ERC-5.6-text-props.patch
Description: Text Data

0004-5.6-Add-erc-spkr-text-property-to-chat-messages.patch
Description: Text Data