Announcing ERC 5.6

[J.P.]

This release comes with a few new and revamped features, like nickname
colorizing, adaptive wrapping, and buffer/nick side panels. Here's the
full rundown from etc/ERC-NEWS [1]:

  Changes in ERC 5.6
  ~~~~~~~~~~~~~~~~~~

  * Module 'keep-place' has a more decorative cousin.

    Remember your place in ERC buffers a bit more easily with the help
    of a configurable, visible indicator. Optionally sync the indicator
    to any progress made while you haven't yet caught up to the live
    stream. See options 'erc-keep-place-indicator-style' and friends,
    and try M-x keep-place-indicator-mode to see it in action.

  * Module 'fill' offers an adaptive style based on 'visual-line-mode'.
    This style dynamically wraps messages to a window's width while
    mimicking the "hanging indent" look of 'erc-fill-static'. It also
    provides some movement and editing commands to optionally tame the
    less familiar aspects of 'visual-line' behavior. An interactive
    helper called 'erc-fill-wrap-nudge' makes easy work of adjusting the
    overhang on the fly. Set 'erc-fill-function' to 'erc-fill-wrap' to
    get started.

  * A module for nickname highlighting has joined ERC.

    Automatic nickname coloring has come to ERC core. Users familiar
    with 'erc-hl-nicks', from which this module directly descends, will
    already be familiar with its suite of handy options. By default,
    each nickname in an ERC session receives a unique face with a unique
    (or uniformly dealt) foreground color. Add 'nicks' to 'erc-modules'
    to get started.

  * A unified interactive entry point.

    New users are often dismayed to discover that M-x ERC doesn't
    connect to its default network, Libera.Chat, over TLS. Though
    perhaps a decade overdue, this is no longer the case. Other UX
    improvements in this area aim to make the process of connecting
    interactively slightly more streamlined and less repetitive, even
    for veteran users.

  * Revised buffer-display handling.

    A point of friction for new users and one only just introduced with
    ERC 5.5 has been the lack of visual feedback when first connecting
    via M-x erc or when issuing a "/JOIN" command at the prompt. As
    explained below, in the news for 5.5, the discovery of a security
    issue led to most new ERC buffers being "buried" on creation. On
    further reflection, this was judged to have been an overcorrection
    in the case of interactive invocations, hence the borrowing of an
    old option, 'erc-query-display', and the bestowing of a new alias,
    'erc-interactive-display', which better describes its expanded role
    as a more general buffer-display knob for interactive commands
    ("/QUERY" still among them).

    Accompanying this addition are "display"-suffixed aliases for
    related options 'erc-join-buffer' and 'erc-auto-query', which users
    have reported as being difficult to discover and remember. When the
    latter option (now known as 'erc-receive-query-display') is nil, ERC
    uses 'erc-join-buffer' in its place, much like it does for
    'erc-interactive-display'. The old nil behavior can still be gotten
    via the new compatibility flag 'erc-receive-query-display-defer'.
    The relatively new option 'erc-reconnect-display' has likewise been
    renamed, this time for clarity, to 'erc-auto-reconnect-display'.

    This release also introduces a few subtleties affecting the display
    of new or reassociated buffers. One involves buffers that already
    occupy the selected window. ERC now treats these as deserving of an
    implicit 'bury'. An escape hatch for this and most other baked-in
    behaviors is now available in the form of a new type variant
    recognized by all such options. That is, users can now specify their
    own function to exercise full control over nearly all buffer-display
    related decisions. See the newly expanded doc strings of
    'erc-buffer-display' and friends, as well as Info node '(erc)
    display-buffer', for details.

  * Setting a module's mode variable via Customize earns a warning.

    Trying and failing to activate a module via its minor mode's Custom
    widget has been an age-old annoyance for new users. Previously
    ineffective, this method now actually works, but it also admonishes
    users to edit the 'erc-modules' widget instead.

  * ERC's status-sidebar has gained an accompanying module.

    Users can now add 'bufbar' to 'erc-modules' to achieve the same
    effect as toggling 'erc-status-sidebar-open' manually at the start
    of an IRC session. The module has also been outfitted to show
    channels and queries under their servers by default. To avoid
    confusion, the major mode for the actual sidebar buffer itself,
    'erc-status-sidebar-mode', is no longer available interactively.

  * A new spin on a classic integration in erc-speedbar.

    Add 'nickbar' to 'erc-modules' to spawn a dynamically updating side
    window listing all the users in any target buffer. It's powered by
    the same speedbar.el integration you've always known, except this
    one's optionally accessible from the keyboard, just like any other
    side window. Hit '<RET>' over a nick to spawn a "/QUERY" or a
    "Lastlog" (Occur) session. See 'erc-nickbar-mode' for more.

  * New 'querypoll' module for tracking non-channel query participants.

    ERC has gotten a bit pickier about managing participants in query
    buffers. "Untracked" correspondents no longer appear automatically
    in membership tables, even if you respond or initiate contact.
    Instead, ERC only adds and removes participant data when these same
    users join and leave channels. Anyone uncomfortable with the
    apparent uncertainty this brings can look to the new 'querypoll'
    module, which periodically sends WHO requests to keep track of
    correspondents. Those familiar with the IRCv3 Monitor extension can
    think of this as "fallback code" and a temporary placeholder for the
    real thing. Add 'querypoll' (and 'nickbar') to 'erc-modules' to try
    it out.

  * Option 'erc-timestamp-use-align-to' made more versatile.

    While this option has always offered to right-align stamps via the
    'display' text property, it's now more effective at doing so when
    set to a number indicating an offset from the right edge. Users of
    the 'log' module may want to customize 'erc-log-filter-function' to
    'erc-stamp-prefix-log-filter' to avoid ragged right-hand stamps
    appearing in their saved logs.

  * Awkward entry point 'erc-server-select' improved but deprecated.

    The alternate entry point 'erc-server-select' has mainly served to
    confuse users in more recent years because it requires certain
    options, like 'erc-nick', to be configured ahead of time, and it
    doesn't support TLS. Its main selling point, historically, has been
    interactive completion based on the option 'erc-server-alist', which
    is a table of networks, servers, and ports. But most of the option's
    400-odd entries are sadly defunct or otherwise outdated. And, these
    days, most networks promote a well known load-balancing end point
    over individual servers anyway. Regardless, the command has now been
    improved to prompt for the same slate of parameters sought by
    'erc-tls'. Similarly, 'erc-server-alist' entries now support a fifth
    member in TLS ports (though this option too has been deprecated). If
    you feel these deprecations rash or unwarranted, please file a bug
    report and petition the maintainers for a reprieve.

  * Smarter reconnect handling for users on the move.

    ERC now offers a new, experimental reconnect strategy in the
    function 'erc-server-delayed-check-reconnect', which tests for
    underlying connectivity before attempting to reconnect in earnest.
    See option 'erc-server-reconnect-function' and new local module
    'services-regain' (also experimental) to get started.

  * Module-based keybinding adjustments for major modes.

    To put it another way, simply loading a built-in module's library no
    longer modifies 'erc-mode-map'. Instead, modifications occur during
    module setup. This should not impact most user configs since ERC
    doesn't bother with keys already taken and only removes bindings
    it's previously created. Note that while all affected bindings still
    reside in 'erc-mode-map', future built-in modules will use their own
    minor-mode maps, and new third-party modules should do the same.

  * Option 'erc-timestamp-format-right' deprecated.

    Having to account for this option prevented other ERC modules from
    easily determining what right-sided stamps would look like before
    insertion, which is knowledge needed for certain UI decisions. The
    way ERC has chosen to address this is imperfect and boils down to
    asking users who've customized this option to switch to
    'erc-timestamp-format' instead. If you're affected by this and feel
    that some other solution, like automatic migration, is justified,
    please make that known on the bug list.

  * Module 'command-indicator' revives echoing, replacing 'noncommands'.

    Command-line echoing has returned to ERC after a near decade-long
    hiatus. This means you can elect to have ERC leave a trail of (most)
    slash-command input submitted at the prompt, in a manner resembling
    that of a shell or a REPL. The particulars are likely of little
    interest to most users, but the gist is that this functionality was
    removed in 5.3.x (Emacs 24.5) without mention in this document or a
    change log. Everything's mostly been restored, except that the
    feature is now opt-in. The only real gotcha is that related faces
    and options, like 'erc-command-indicator', have moved to the
    'erc-goodies' library, although their Custom groups remain the same.
    Add 'command-indicator' to 'erc-modules' to get started.

  * Option 'erc-track-faces-normal-list' slightly more influential.

    This option has always been a source of confusion for users, mainly
    because its influence rode heavily on the makeup of faces in a given
    message. Historically, when a buffer's current mode-line face was a
    member of this option's value, ERC would only swap it out for a
    fellow "normal" if it was absent from the message being processed.
    Beginning with this release, ERC now looks to other ranked and, if
    necessary, unranked "normals" instead of sustaining the same face
    between messages. This was done to better honor the stated purpose
    of the option, which is to provide consistent visual feedback when
    buffer activity occurs. If you experience problems with this
    development, see the compatibility flag
    'erc-track-ignore-normal-contenders-p'.

  * 'erc-button-alist' and 'erc-nick-popup-alist' have evolved slightly.

    It's no secret that the 'buttons' module treats potential nicknames
    specially. This is perhaps most evident in its treatment of the
    'nicknames' entry in 'erc-button-alist'. Indeed, to simplify ERC's
    move to next-gen "rich UI" extensions, this special treatment is
    being canonized. From here on out, this entry will no longer appear
    in the option's default value but will instead be applied implicitly
    so long as the option 'erc-button-buttonize-nicks' is non-nil, which
    it is by default. Relatedly, the option 'erc-nick-popup-alist' now
    favors functions, which ERC calls non-interactively, over arbitrary
    s-expressions, which ERC will continue to honor. Although the
    default lineup remains functionally equivalent, its members have all
    been updated accordingly.

  * A slimmed down 'erc-track-faces-priority-list'.

    This option, along with 'erc-track-faces-normal-list', has been
    purged of certain 'button'-related face combinations. Originally
    added in ERC 5.3, these combinations described the effect of
    "buttonizing" atop faces added by the 'match' module, like
    '(erc-nick-default-face erc-pal-face)'. However, since at least
    Emacs 27, 'match' has run before 'button' in
    'erc-insert-modify-hook', meaning such permutations aren't possible.

    More importantly, users who've customized either of these options
    should update them with the new default value of the option
    'erc-button-nickname-face'. Like 'erc-nick-default-face', which it
    replaces, the new 'erc-button-nick-default-face' is also a "real"
    face. Its sole reason for existing is to make it easier for users
    and modules to distinguish between basic buttonized faces and
    'erc-nick-default-face', which is now reserved to mean the base
    "speaker" face.

  * Option 'erc-query-on-unjoined-chan-privmsg' restored and renamed.

    This option was accidentally removed from the default client in ERC
    5.5 and was thus prevented from influencing PRIVMSG routing. It's
    now been restored with a slightly revised role contingent on a few
    assumptions explained in its doc string. For clarity, it has been
    renamed 'erc-ensure-target-buffer-on-privmsg'.

  * A smarter, more responsive prompt.

    ERC's prompt can be told to respond dynamically to incoming and
    outgoing messages by leveraging the familiar function variant of the
    option 'erc-prompt'.  With this release, only predefined functions can
    take full advantage of this new dynamism, but an interface to empower
    third parties with the same possibilities may follow suit.  To get
    started, customize 'erc-prompt' to 'erc-prompt-format', and see the
    option of the same name ('erc-prompt-format') for a rudimentary
    templating facility reminiscent of 'erc-mode-line-format'.

  * Module 'scrolltobottom' now optionally more aggressive.

    Enabling the experimental option 'erc-scrolltobottom-all' makes ERC
    more vigilant about staking down the input area in all ERC windows.
    And the option's 'relaxed' variant makes ERC's prompt stationary
    wherever it happens to reside instead of forcing it to the bottom of
    a window, meaning new input appears above the prompt, scrolling
    existing messages upward to compensate.

  * Subtle changes for two fundamental faces.

    Users of the default theme may notice that 'erc-action-face' and
    'erc-notice-face' now appear slightly less bold. This improves
    button detection and spares users from having to tweak faces (or
    options, like 'erc-notice-highlight-type') just to achieve this
    effect. The change is currently most noticeable in "/ME" messages,
    where 'erc-action-face' appears beneath 'erc-input-face' and
    'erc-my-nick-face'.

  * Fewer nick buttons in QUIT, JOIN, and PART messages.

    Common messages that show a nickname followed by a "userhost" often
    end up with redundant buttons because the nick reappears in or is
    the same as the "~user" portion. ERC now tamps down on this to make
    <TAB>ing around more convenient. To opt out, see the new variable
    'erc-button-highlight-nick-once'.

  * Improved interplay between buffer truncation and message logging.

    While most of these improvements are subtle, some affect everyday
    use. For example, users of the 'truncate' module may notice that
    truncation now happens between messages rather than arbitrary lines.
    And those with the default 'erc-insert-timestamp-left-and-right' for
    their 'erc-insert-timestamp-function' will see date stamps reprinted
    after every "/CLEAR" but omitted from any logs. One notable casualty
    of these changes has been the deprecation of the ancient option
    'erc-truncate-buffer-on-save'. Users of the 'log' module can achieve
    the same effect by issuing a "/CLEAR" at the prompt.

  * The 'truncate' module no longer enables logging automatically.

    Users expecting 'truncate' to perform logging based on the option
    'erc-enable-logging' need to instead add 'log' to 'erc-modules' for
    continued integration. Under the original design, merely loading the
    library 'erc-log' caused 'truncate' to start writing logs, possibly
    against a user's wishes.

  * The function 'erc-echo-timestamp' is now a command.

    The option 'erc-echo-timestamps' (plural) has always enabled the
    contextual printing of timestamps to the echo area when moving
    between messages in an ERC buffer. Similar functionality is now
    available on demand by invoking the newly interactive function
    'erc-echo-timestamp' atop any message. The new companion option
    'erc-echo-timestamp-zone' determines the default timezone when not
    specified with a prefix argument.

  * Option 'erc-remove-parsed-property' deprecated.

    This option's nil behavior serves no practical purpose yet has the
    potential to degrade the user experience by competing for space with
    forthcoming features powered by next generation extensions. Anyone
    with a legitimate use for this option likely also possesses the
    knowledge to rig up a suitable analog with minimal effort. That
    said, the road to removal is long.

  * The 'track' module always ignores date stamps.

    Users of the stamp module who leave 'erc-insert-timestamp-function'
    set to its default of 'erc-insert-timestamp-left-and-right' will
    find that date stamps no longer affect the mode line, even for IRC
    commands not included in 'erc-track-exclude-types'.

  * Option 'erc-warn-about-blank-lines' is more informative.

    Enabled by default, this option now produces more useful feedback
    whenever ERC rejects prompt input containing whitespace-only lines.
    When paired with option 'erc-send-whitespace-lines', ERC echoes a
    tally of blank lines padded and trailing blanks culled.

  * A context-dependent mode segment in header and mode lines.

    The "%m" specifier has traditionally expanded to a lone "+" in
    server and query buffers and a string containing all switch modes
    (plus "limit" and "key" args) in channel buffers. It now becomes a
    string of user modes in server buffers and disappears completely in
    query buffers. In channels, it's grown to include all letters and
    their possibly truncated arguments, with the exception of stateful
    list modes, like "b".

  * In-buffer "status messages" are now a thing.

    The ancient option 'erc-ensure-target-buffer-on-privmsg' has been
    repurposed slightly to express a third state denoted by the symbol
    'status'. It tells ERC to revert to the old default behavior in
    which separate, "pseudo" target buffers for status-prefixed
    conversing co-existed alongside actual target buffers. Instead of
    this awkward arrangement, ERC now acts like other clients by default
    and inserts so-called "status messages" in situ, right between other
    messages. Similar insertion-routing behavior now also applies to
    CTCP ACTIONs directed at status-prefixed channels. Unfortunately,
    outgoing "/msg @#chan hi" messages aren't yet shown in the same
    fashion, but the groundwork has been laid, making such an addition
    almost trivial.

  * An easier way to see channel-membership prefixes on speakers.

    The option 'erc-format-@nick' has been deprecated in favor of the
    new boolean option 'erc-show-speaker-membership-status', a simple
    switch to enable the displaying of status prefixes on the speaker
    nicks of incoming chat messages. Prefixes on your speaker nick for
    outgoing chat messages continue to always be present.

  * Updating user options requires cycling associated minor modes.

    During a live ERC session, you may need to disable and re-enable a
    module's minor mode via 'M-x erc-foo-mode RET' or similar before an
    option's updated value takes effect. This primarily impacts new
    options introduced by this release and existing ones whose behavior
    has changed in some way. At present, ERC does not perform this step
    automatically on your behalf, even if a change was made in a
    'Custom-mode' buffer or via 'setopt'.

  * New broadcast-oriented slash commands /AME, /GME, and /GMSG.

    Also available as the library functions 'erc-cmd-AME',
    'erc-cmd-GME', and 'erc-cmd-GMSG', these new slash commands can
    prove handy in test environments.

  * New face 'erc-information' for local administrative messages.

    Messages not originating from a server have historically been shown
    in 'erc-notice-face', sometimes in combination with
    'erc-error-face'. Neither are well suited for local messages of
    moderate importance. From now on, such messages will appear in a
    more muted color but retain the familiar 'erc-notice-prefix' stars.

  * Miscellaneous UX changes.

    Some minor quality-of-life niceties have finally made their way to
    ERC. For example, fool visibility has become togglable with the new
    command 'erc-match-toggle-hidden-fools'. The 'button' module's
    'erc-button-previous' command now moves to the beginning instead of
    the end of buttons. A new command, 'erc-news', can be invoked to
    visit this very file. And the 'irccontrols' module now supports
    additional colors and special handling for "spoilers" (hidden text).

  * Changes in the library API.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~

    * Some top-level dependencies have been removed.

      The library 'erc-goodies' is no longer loaded by ERC's main
      library. This was done to further cement the move toward a
      unidirectional dependency flow begun in 5.5. Additionally, a few
      barely used and newly introduced dependencies are now lazily
      loaded, which may upset some third-party code. The first of these
      is 'pp' because its 'pp-to-string' is autoloaded in all supported
      ERC versions. Also gone are 'thingatpt', 'time-date', and
      'iso8601'. All were used ultra sparingly, and the latter two have
      only been around for one minor release cycle, so their removal
      hopefully won't cause much churn.

    * Some ERC-applied text properties have changed.

      Chiefly, a new set of metadata-oriented properties, the details of
      which should be considered internal, now occupy the first
      character of all inserted messages, including local notices, date
      stamps, and interactive feedback. These properties will likely
      form the basis for a new message-traversal/insertion/deletion API
      in future versions. Less impactfully, the no-op property
      'rear-sticky' has been removed, and the value of the 'field'
      property for ERC's prompt has changed from 't' to the more useful
      'erc-prompt', although the property of the same name has been
      retained and now has a value of 'hidden' when disconnected.

    * Flattened face lists for buttonized text.

      Previously, when "buttonizing" a new region, ERC would combine
      faces by blindly consing the new onto the existing. In theory,
      this kept a nice record of all modifications to a given region.
      However, it also complicated life for other modules wanting to
      analyze and operate on these regions. Beginning with this release,
      ERC now merges combined faces together when creating buttons,
      although the odd nested list may still crop up here and there.

    * Members of insert- and send-related hooks have been reordered.

      As anyone reading this is no doubt aware, both built-in and
      third-party modules rely on certain hooks for adjusting incoming
      and outgoing messages upon insertion. And some modules only want
      to do so after others have done their damage. Traditionally, this
      has required various hacks and finagling to achieve. And while
      this release makes an effort to load modules in a more consistent
      order, that alone isn't enough to ensure predictability among
      essential members of important hooks.

      Luckily, ERC now leverages a feature introduced in Emacs 27, "hook
      depth," to secure the positions of a few key members of
      'erc-insert-modify-hook' and 'erc-send-modify-hook'. So far, this
      includes the functions 'erc-button-add-buttons',
      'erc-match-message', 'erc-fill', and 'erc-add-timestamp', which
      now appear in that order, when present, at depths beginning at 20
      and ending below 80. Of most interest to module authors is the new
      relative positioning of the first three, which have been rotated
      leftward with respect to their previous places in recent ERC
      versions (fill, button, match ,stamp). A similar designated range
      from -80 to -20 also exists and is home to the function
      'erc-controls-highlight'.

      ERC also provisionally reserves the same depth intervals for
      'erc-insert-pre-hook' and possibly other, similar hooks, but will
      continue to modify non-ERC hooks locally whenever possible,
      especially in new code.

    * A singular entry point for inserting messages.

      Displaying "local" messages, like help text and
      interactive-command feedback, in ERC buffers has never been
      straightforward. As such, ancient patterns, like the pairing of
      preformatted "notice" text with ERC's oldest insertion function,
      'erc-display-line', still appear quite frequently in the wild
      despite having been largely phased out of ERC's own code base in
      2002. That this example has endured makes some sense because it's
      probably seen as less cumbersome than fiddling with the more
      powerful and complicated 'erc-display-message'.

      The latest twist in this tale comes with this release, for which a
      healthy helping of "pre-insertion" business has permanently
      ensconced itself in none other than 'erc-display-message'. While
      this would seem to put antiquated patterns, like the above
      mentioned 'erc-make-notice' combo, at risk of having messages
      ignored or subject to degraded treatment by built-in modules, an
      adaptive measure has been introduced that recasts
      'erc-display-line' as a thin wrapper around 'erc-display-message'.
      And though nothing of the sort has been done for the lower-level
      'erc-display-line-1' (now an obsolete alias for
      'erc-insert-line'), some last-ditch fallback code has been
      introduced to guarantee baseline functionality. As always, if you
      find these developments disturbing, please say so on the tracker.

    * ERC now manages timestamp-related properties a bit differently.

      For starters, the 'cursor-sensor-functions' text property is
      absent by default unless the option 'erc-echo-timestamps' is
      already enabled on module init. And when present, the property's
      value no longer contains unique closures and thus no longer proves
      effective for traversing inserted messages. For now, ERC only
      provides an internal means of visiting messages, but a public
      interface is forthcoming. Also affecting the 'stamp' module is the
      deprecation of the function 'erc-insert-aligned' and its removal
      from the default client's code. In the same library, the function
      'erc-munge-invisibility-spec' has been renamed to
      'erc-stamp--manage-local-options-state' to better reflect its
      purpose. Additionally, the module now merges its 'invisible'
      property with existing ones and includes all white space around
      stamps when doing so.

      This "propertizing" of surrounding white space extends to all
      'stamp'-applied properties, like 'field', in all intervening space
      between message text and timestamps. Technically, this constitutes
      a breaking change from the perspective of detecting a timestamp's
      bounds. However, ERC has always propertized leading space before
      right-sided stamps on the same line as message text but not before
      those folded onto the next line. Such inconsistency made stamp
      detection overly complex and produced uneven results when toggling
      stamp visibility.

    * Invisible message insertions not automatically made 'intangible'.

      Previously, when 'erc-display-message' and friends spotted the
      'invisible' text property with a value of t anywhere in text to be
      inserted, it would apply that property to the entire message,
      along with a t-valued 'intangible' property. Beginning with ERC
      5.6, users expecting this behavior will have to instead perform
      the treatment themselves. To help with the transition, a temporary
      escape hatch has been made available to regain this behavior, but
      its existence is only guaranteed for this one minor version alone.
      See source code in the vicinity of 'erc-insert-line' for more.

    * Date stamps have become independent messages.

      ERC now inserts "date stamps" generated from the option
      'erc-timestamp-format-left' as separate, standalone messages. This
      currently only matters if 'erc-insert-timestamp-function' is set
      to its default value of 'erc-insert-timestamp-left-and-right',
      however plans exist to decouple these features. In any case, ERC's
      near-term UI goals require exposing these stamps to existing code
      designed to operate on complete messages. For example, users
      likely expect date stamps to be togglable with
      'erc-toggle-timestamps' while also being immune to hiding from
      commands like 'erc-match-toggle-hidden-fools'. Before this change,
      meeting such expectations demanded brittle heuristics that checked
      for the presence of these stamps in the leading portion of message
      bodies as well as special casing to act on these areas without
      inflicting collateral damage.

      Despite the rationale, this move admittedly ushers in a heightened
      potential for disruption because third-party members of ERC's
      modification hooks may not take kindly to encountering stamp-only
      messages or the new behavior of
      'erc-timestamp-last-inserted-left', which no longer records the
      final trailing newline in the variable
      'erc-timestamp-format-left'. If these inconveniences prove too
      encumbering to deal with right away, see the escape hatch
      'erc-stamp-prepend-date-stamps-p', which should help ease the
      transition. As for detecting these new stamp-only messages from
      members of 'erc-insert-modify-hook' and friends, see the function
      'erc-stamp-inserting-date-stamp-p'.

    * The role of a module's Custom group is now more clearly defined.

      Associating built-in modules with Custom groups and "provided"
      library features has improved. More specifically, a module's group
      now enjoys the singular purpose of determining where the module's
      minor mode variable lives in the Customize interface. And although
      ERC is now slightly more adept at linking these entities,
      third-parties are still encouraged to keep a module's name aligned
      with its group's as well as the provided feature of its containing
      library, if only for the usual reasons of namespace hygiene and
      discoverability.

    * The function 'erc-open' no longer uses the 'TGT-LIST' parameter.

      ERC has always used the parameter to initialize the local variable
      'erc-default-recipients', which stores a list of routing targets
      with the topmost considered "active." However, since at least ERC
      5.1, a buffer and its active target effectively mate for life,
      making 'TGT-LIST', in practice, a read-only list of a single
      target. And because that target must also appear as the 'CHANNEL'
      parameter, 'TGT-LIST' mainly serves to reinforce 'erc-open's
      reputation of being unruly.

    * ERC supports arbitrary CHANTYPES.

      Specifically, channels can be prefixed with any predesignated
      character, mainly to afford more flexibility to specialty
      services, like bridges to other protocols.

    * 'erc-cmd-HELP' recognizes subcommands.

      Some IRC "slash" commands are hierarchical and require users to
      specify a subcommand to actually carry out anything of
      consequence. Built-in modules can now provide more detailed help
      for a particular subcommand by telling ERC to defer to a
      specialized handler. This facility can be opened up to third
      parties should any one request it.

    * Message-formatting templates in 'notify' renamed.

      All templates beginning with "erc-message-english-notify_" have
      been renamed to begin with "erc-message-english-notify-". For
      example, the variable 'erc-message-english-notify_current' is now
      'erc-message-english-notify_current'. The old names have been
      preserved as obsolete aliases.

    * Longtime quasi modules made proper.

      The 'fill' module is now defined by 'define-erc-module'. The same
      goes for ERC's imenu integration, which has 'imenu' now appearing
      in the default value of 'erc-modules'.

    * Function 'erc-get-user-mode-prefix' renamed.

      This utility has been renamed to
      'erc-get-channel-membership-prefix' to better reflect its role of
      delivering a formatted "status prefix", like "+" (for "voice"),
      and to avoid confusion with user modes, like "+i" (for
      "invisible"). Additionally, its lone parameter is now overloaded
      to accept an 'erc-channel-user' object as well as a string.

    * Channel-membership table 'erc-channel-users' renamed.

      Distinguishing between 'erc-channel-user' objects and values of
      the 'erc-channel-users' (plural) hash-table has been a constant
      source of confusion, even within ERC's own code base. The
      hash-table's values are cons cells whose CDR slot is an
      'erc-channel-user'. To help keep things sane, 'erc-channel-users'
      (plural) is now officially being redubbed 'erc-channel-members'.
      Similarly, the utility function 'erc-get-channel-user' has been
      renamed to 'erc-get-channel-member'. Expect deprecations of the
      old names to follow in a future release.

    * Query participant tables now depend on channel membership.

      ERC has always been inconsistent and difficult to predict in its
      handling of records describing other IRC users. This has made
      simple things like detecting the online status of query peers and
      the presence of one's own user in 'erc-server-users' especially
      unreliable. From now on, ERC resolves to be more sensible and
      conservative in such areas. For example, it now retains its own
      user info, once discovered, for the remainder of a session. It
      also relies solely on channel membership to "drive" query
      participant information. That is, when another IRC user departs
      their last known channel, any queries with them will consider them
      absent, even if they're likely still online. Anyone with
      difficulty adapting to this new paradigm should contact the
      mailing list to inquire about associated compatibility flags,
      which can be made public on request. Also see the related news
      item announcing the module 'querypoll'.

    * The 'erc-channel-user' struct has a changed internally.

      The five boolean slots for membership prefixes have been folded
      ("encoded") into a single integer slot. However, the old
      'setf'-able accessors remain available, and the constructor's
      signature remains unchanged. Since third-party code must be
      recompiled when upgrading ERC anyway, users shouldn't experience
      any churn. The only caveat is that third-party code using the
      literal read-syntax of these objects, for example, in unit tests,
      will have to be updated.

    * Hidden messages contain a preceding rather than trailing newline.

      ERC has traditionally only offered to hide messages involving
      fools, but plans are to make hiding more powerful. Anyone
      depending on the existing behavior should be aware that hidden
      messages now start and end one character earlier, so that hidden
      line endings precede rather than follow accompanying text.
      However, an escape hatch is available in the variable
      'erc-legacy-invisible-bounds-p'. It reinstates the old behavior,
      which is unsupported by newer modules and features.

    * 'erc-display-message' optionally combines faces.

      Users may notice that ERC now inserts some important error
      messages in a combination of 'erc-error-face' and
      'erc-notice-face'. This is merely a consequence of
      'erc-display-message' getting smarter about how it treats face
      properties when its 'type' parameter is a list that starts with t.
      Originally, ERC's authors intended to display both
      server-originating and ERC-generated errors in this style, but
      that intent was never realized. Though now possible, the effect
      has been limited to special errors involving usage and internal
      state. For third-party code, the key takeaway is that more
      'font-lock-face' properties encountered in the wild may be
      combinations of faces rather than lone ones.

    * 'erc-flood-protect' no longer influences input splitting.

      This variable's role has been narrowed to rate limiting only. ERC
      used to suppress protocol line-splitting when its value was nil,
      but that's now handled by setting 'erc-split-line-length' to zero.

    * 'erc-pre-send-functions' visits prompt input post-split.

      ERC now adjusts input lines to fall within allowed length limits
      before showing hook members the result. For compatibility,
      third-party code can request that the final input be adjusted
      again prior to being sent. To facilitate this, the 'erc-input'
      object shared among hook members has gained a 'refoldp' slot. See
      doc string for details.

    * More flexibility in sending and displaying prompt input.

      The abnormal hook 'erc-pre-send-functions' previously married
      outgoing message text to its inserted representation in an ERC
      target buffer. Going forward, users can populate the new slot
      'substxt' with alternate text to insert in place of the 'string'
      slot's contents, which ERC still sends to the server. This
      dichotomy lets users completely avoid the often fiddly
      'erc-send-modify-hook' and friends for use cases like language
      translation and subprotocol encoding.

    * ERC's prompt survives the insertion of user input and messages.

      Previously, ERC's prompt and its input marker disappeared while
      running hooks during message insertion, and the position of its
      "insert marker" (ERC's per-buffer process mark) was inconsistent
      during these spells. To make insertion handling more predictable
      in preparation for incorporating various protocol extensions, the
      prompt and its bounding markers have become perennial fixtures.

      To effect this change, small behavioral differences in message
      insertion have been adopted. Crucially, 'erc-insert-marker' now
      has an "insertion type" of t, and 'erc-display-line-1' now calls
      'insert' instead of 'insert-before-markers. This allows user code
      running on 'erc-insert-modify-hook' and 'erc-insert-post-hook' to
      leave its own markers at the actual insertion point instead of
      resorting to workarounds. Message insertion for outgoing messages,
      in 'erc-display-msg', remains as before. In rare cases, these
      changes may mean third-party code needs tweaking, for example,
      requiring the use of 'insert-before-markers' instead of 'insert'.
      As always, users feeling unduly inconvenienced by these changes
      are encouraged to voice their concerns on the bug list.

    * Introducing new ways to detect ERC buffer types.

      The old standby 'erc-default-target' has served ERC well for over
      two decades. But a lesser known gotcha affecting its use has
      always haunted an unlucky few, that is, the function has always
      returned non-nil in "unjoined" channel buffers (those that the
      client has parted with or been kicked from). While perhaps not
      itself a major footgun, recessive pitfalls rooted in this subtlety
      continue to affect dependent functions, like 'erc-get-buffer'.

      To discourage misuse of 'erc-default-target', ERC 5.6 offers an
      alternative in the function 'erc-target', which is identical to
      the former except for its disregard for "joinedness." As a related
      bonus, the dependent function 'erc-server-buffer-p' is being
      rebranded as 'erc-server-or-unjoined-channel-buffer-p'.
      Unfortunately, this release lacks a similar solution for detecting
      "joinedness" directly, but users can turn to 'xor'-ing
      'erc-default-target' and 'erc-target' as a makeshift kludge.

    * Function 'erc-kill-channel' renamed to 'erc-part-channel-on-kill'.

      This function, which normally emits a 'PART' when ERC kills a
      channel buffer, has been renamed for clarity. Moreover, this and
      all other members of 'erc-kill-channel-hook' can now take comfort
      in knowing that the killing of buffers done on behalf of the
      option 'erc-kill-buffer-on-part' has been made more detectable by
      the flag 'erc-killing-buffer-on-part-p'.

    * Stricter and more predictable channel-mode handling.

      ERC has always processed channel modes using "standardized"
      letters and popular status prefixes. Starting with this release,
      ERC will begin preferring advertised "CHANMODES" when interpreting
      letters and their arguments. To facilitate this transition, the
      functions 'erc-set-modes', 'erc-parse-modes', and
      'erc-update-modes', have all been provisionally deprecated. Expect
      a new, replacement API for handling specific "MODE" types and
      letters in coming releases. If you'd like a say in shaping how
      this transpires, please share your ideas and use cases on the
      tracker.

    * A better way to define message-formatting templates.

      The functions 'erc-define-catalog-entry' and 'erc-define-catalog'
      have been deprecated in favor of
      'erc-define-message-format-catalog', a new macro for defining
      template "catalogs" at the top level of libraries.

    * Interface for determining display names renamed.

      The option 'erc-format-nick-function' has been renamed to
      'erc-speaker-from-channel-member-function' to better reflect its
      actual role. So too has the related function 'erc-format-nick',
      which is now 'erc-determine-speaker-from user'.

    * All default response handlers return nil.

      Actually, this isn't yet true, but ERC is moving in this
      direction. The goal is to guarantee that trailing members of
      response hooks, like 'erc-server-005-functions', have an
      opportunity to run after the default handler. For now, certain
      default handlers that may have previously returned non-nil, like
      'erc-server-PONG' and 'erc-server-904', have been updated to
      return nil in all cases.

    * A template-based approach to formatting inserted chat messages.

      Predicting and influencing how ERC formats messages containing a
      leading "<speaker>" has never been straightforward. The characters
      bracketing the speaker and the faces used for each component have
      always been hard-coded, with 'erc-format-query-as-channel-p' being
      the only knob of any consequence. With this release, ERC begins
      its transition to a unified formatting paradigm that builds upon
      the already familiar "language catalog" templating system. Using a
      separate "speaker catalog" keyed by contextual symbols, like
      'query-privmsg', ERC (and eventually everyone) will more easily be
      able to influence how inserted messages take shape in buffers.

      As a consequence of this transition, the default client no longer
      calls `erc-format-privmessage' to format speaker messages. See
      that function's doc string for help adapting to the new system,
      but please keep in mind that discussions are still ongoing
      regarding its eventual public interface. As usual, anyone
      interested should get involved by writing to the mailing list.

    * New format templates for inserted CTCP ACTION messages.

      In 5.5 and earlier, ERC displayed outgoing CTCP ACTION messages in
      'erc-input-face' alone (before buttonizing). Incoming ACTION
      messages mirrored this, except with 'erc-action-face' throughout.
      Going forward, inserted outgoing "/ME" messages will also
      incorporate 'erc-action-face', only underneath 'erc-input-face',
      with 'erc-my-nick-face' sitting atop both in the leading "speaker"
      nickname portion (again, pre-buttonizing). This new behavior
      sidesteps the traditional format template
      'erc-message-english-ACTION' from the default "language catalog"
      in favor of an entry from the new internal "speaker catalog".
      Users needing to access the old behavior can do so by toggling a
      provided compatibility switch. See source code around the function
      'erc-send-action' for details.

    * Miscellaneous changes.

      In 'erc-button-alist', 'Info-goto-node' has been supplanted by
      plain old 'info', and the "<URL:...>" entry has been removed
      because it was more or less redundant. In all ERC buffers, the
      "<TAB>" key is now bound to a new command, 'erc-tab', that calls
      'completion-at-point' inside the input area and otherwise
      dispatches module-specific commands, like 'erc-button-next'.

Users on Emacs 29 can upgrade with C-u M-x package-install RET. Users on
older versions, please see [2].

Many thanks to the following folks for contributing to this release:

  - The Emacs maintainers
  - Mauro Aranda for fixing many Customize-related gaffes
  - Mattias Engdegård for pointing out a plethora of sloppy mistakes by
    "no one in particular"
  - Alan Mackenzie and Stefan Monnier for highlighting egregious pcase
    abuse (also by no one in particular)
  - Engineer Octavio for the nice write-up on ERC's Tor integration
  - ERC user xoddf2 for shining a spotlight on auto-reconnect problems
  - Yusuf Aslam for reporting a bug in ERC's imenu.el integration
  - Fernando de Morais for finding a regression in /DCC GET options
    parsing
  - Libera user jrm for pointing out a bug in the match module
  - Libera user mekeor for reporting a regression in erc-query-buffer-p
  - Libera user technomancy for the bridge-bot package erc-bridge-nicks.el
  - Osmo Karppinen for reporting an /SQUERY bug
  - ERC user Jake (jforst) for reporting a bug involving .authinfo.gpg
  - David Leatherman and others for the new nicks module
  - Corwin Brust for GitHub liaising, bug discovery, and various patches
  - Emmanuel Berg for bug discovery, including the /MOTD bug, and for the
    new commands /AMSG, /GME, and /AME
  - Daniel Pettersson for fixing /DCC GET options parsing
  - Fadi Moukayed for bug discovery, assiduous testing, and fixing
    spoilers in irccontrols

For anyone else wanting to get involved, please step forward and say hi,
either here on the list or in #erc.

Enjoy the release, people!

J.P.


[1] https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/ERC-NEWS
[2] https://elpa.gnu.org/devel/doc/erc.html#Upgrading