Re: bug#64301: 30.0.50; ERC 5.6: Make speaker labels easier to work with

[J.P.]

v2. Add `erc-ctcp' text property to inserted CTCP ACTION messages.
Demote `erc-fill-spaced-commands' from a user option to an internal
variable. Dedent action messages with module `fill-wrap'. Combine faces
in `erc-display-message' when called with a list `type' arg. Have
`erc-put-text-property' conditionally combine prop values instead of
clobber. Apply `invisible' property to white space around stamps.


This iteration includes a number of changes, the most important being
one that looks severe but is largely mechanical. It concerns a bug
that's been around forever and, as such, is now part of the foundation.
Basically, the `type' parameter of the function `erc-display-message'
determines a special handler that applies styling to a message. When the
parameter is a list, the function calls each handler in turn, left to
right, which clobbers existing faces instead of combines them. The net
effect (in most cases) is identical to calling the function with the
last member alone. Despite this, it would seem ending up with multiple,
"layered" faces was the authors' original intent based on the ubiquity
of call sites featuring the list variant.

Authoritative intent aside, in the intervening decades, other code was
written that expects the current clobbering behavior. An example of this
exists in the default value of `erc-track-faces-priority-list', which
contains `erc-error-face' alone rather than paired with
`erc-notice-face'. There may indeed be others that will go undetected
should we make this "fix," which I'm still in favor of despite the
attendant risk. Though improved call-site readability is one upside, I'm
more interested in the UX possibilities such layering opens up. Subtle
benefits can already be seen after applying these changes, for example,
in text inserted for outgoing /me commands, which now sport a
combination of `erc-input-face' and `erc-action-face'.

In a bid to mitigate potential breakage, at least internally, I've gone
ahead and mass-replaced all instances of

  (erc-display-message parsed '(notice error) ...)

with

  (erc-display-message parsed 'error ...)

which amounts to 38 incisions in total. Once again, if we leave things
as is, users who've customized `erc-track-faces-priority-list' won't
ever see error-colored text in their mode line, which is a deal breaker.

The other major change involves making time stamps more sensitive to
existing invisible text by combining `stamp'-owned spec members with
existing properties and by extending those propertized areas to include
surrounding white space. Previously, the `stamp' module went to great
lengths to avoid applying stamps to invisible messages entirely.
However, this policy caused uneven output in logs with `left-handed'
stamps and in formerly hidden messages mentioning designated "fools".
It's true that what I'm proposing would mark a complete reversal, but
it's not as drastic as it sounds. To see the effect, do something like

  (setq erc-insert-timestamp-function #'erc-insert-timestamp-left
        erc-timestamp-only-if-changed-flag nil
        erc-text-matched-hook '(erc-log-matches erc-hide-fools)
        erc-fools '("somebot"))

After connecting, say something to trigger "somebot" while ensuring
`erc-toggle-timestamps' still works. Then do

  M-: (remove-from-invisibility-spec 'erc-match) RET

and notice that the revealed text has timestamps in all the right
places. And if you have the `log' module enabled, notice that stamps are
likewise present on all messages.

0000-v1-v2.diff
Description: Text Data

0001-5.6-Respect-existing-invisibility-props-in-erc-stamp.patch
Description: Text Data

0002-5.6-Simplify-erc-button-add-nickname-buttons.patch
Description: Text Data

0003-5.6-Add-text-props-for-CTCPs-and-speakers-in-ERC.patch
Description: Text Data

0004-5.6-Handle-composite-faces-better-in-erc-display-mes.patch
Description: Text Data