bug#73443: 29.4; ERC 5.6.1-git: erc-track mode line face color broken with left timestamps

["J.P." <jp@neverwas.me>]

Hi,

tmarjeski@gmail.com writes:

> When setting erc-insert-timestamp-function to 'erc-insert-timestamp-left
> the erc-track channel names in the mode line do not respect the nick
> face color of whoever sent the message. The result is that the face
> color is white or the color of the timestamp face, whereas with
> 'erc-insert-timestamp-right the color is of the nick that sent a
> message.
>
> Reproduction steps:
> 1. emacs -Q
> 2. (setq erc-insert-timestamp-function 'erc-insert-timestamp-left
>          erc-timestamp-format "[%H:%M") ;; possibly unnecessary
>    (erc-track-mode) ;; enable track mode in mode line
> 3. Connect to ERC
> 4. Join a few channels so the names are legible
> 5. Go to scratch or irc server buffer, wait for a message on a channel
> 6. Notice that the channel name is not the color of the nick who sent
> the message

Unfortunately, I've not (yet) been able to reproduce this.

> In GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43,
> cairo version 1.18.0)

Complicating things slightly is this bit from the subject line:

  "29.4; ERC 5.6.1-git"

Those two don't normally jive. Typically, when you install the devel
version from GNU ELPA, ERC reports its version as something like

  "5.6.1snapshot0.20240813.11230"

If straight.el is using its own non-tarball snapshots [1], it'd be nice
to get the actual version string (you mentioned something like this in
the Libera channel). If you're feeling lucky, please try

  (and-let*
      ((straight--default-directory (straight--repos-dir "erc"))
       (ref (straight-vc 'get-commit 'git "erc"))
       (output (straight--process-output "git" "show" "--stat" ref))
       (pat (rx bol (* ?\s) "Sourced from erc version "
                (group (+ (in "0-9.a-z-"))) " on GNU ELPA Devel"))
       ((string-match pat output))
       ((match-string 1 output))))

and share the result (if it doesn't bork your Emacs first).

[1] https://github.com/emacs-straight/erc.git

Also, in your description above, "the color of the nick that sent a
message" appears to suggest you want the `nicks' module loaded (it's not
by default and isn't part of the ERC that ships with Emacs 29.4).
Anyway, perhaps the recipe should contain something like

  (setopt erc-modules (add-to-list 'erc-modules 'nicks))

or similar.

> Major mode: ERC
>
> Minor modes in effect:
>   erc-ring-mode: t
>   erc-nicks-mode: t
    ^~~~~~~~~~~~~~~~~

I realize this list of modes is merely gleaned from the Emacs process
that generated the bug report and not necessarily the one exhibiting the
bug. Nevertheless, I'm compelled to wonder if your straight.el
configuration isn't somehow inadvertently "contaminating" the session
launched from your emacs -Q recipe behind the scenes?

>   erc-scrolltobottom-mode: t
>   erc-spelling-mode: t
>   flyspell-mode: t
>   erc-track-mode: (t erc-nicks--setup-track-integration)
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

BTW, this strange value is definitely a bug (that I believe I can fix).
But it's likely unrelated to your issue, sadly.

> Load-path shadows:
[...]
> /home/trev/.emacs.d/straight/build/erc/erc-fill hides
>   /usr/share/emacs/29.4/lisp/erc/erc-fill
> /home/trev/.emacs.d/straight/build/erc/erc-loaddefs hides
>   /usr/share/emacs/29.4/lisp/erc/erc-loaddefs

If these load paths or ones like it are in fact generated from the
suspected straight.el snapshots mentioned above _and_ are meant to be
present in your -Q recipe's session, please specify something like

  emacs -Q
  -L /home/trev/.emacs.d/straight/build/erc
  -l /home/trev/.emacs.d/straight/build/erc/erc-autoloads.el

if possible. Better still would be a full recipe for a clean install
from scratch. For example:

1. $ mkdir -p /tmp/bug73443/.emacs.d/
2. Put this in /tmp/bug73443/.emacs.d/init.el:

  ;; -*- lexical-binding: t; -*-

  ;; straight.el boilerplate
  (defvar bootstrap-version)
  (let ((bootstrap-file
         (expand-file-name
          "straight/repos/straight.el/bootstrap.el"
          (or (bound-and-true-p straight-base-dir)
              user-emacs-directory)))
        (bootstrap-version 7))
    (unless (file-exists-p bootstrap-file)
      (with-current-buffer
          (url-retrieve-synchronously
           "https://raw.githubusercontent.com/radian-software/straight.el/develop/install.el"
           'silent 'inhibit-cookies)
        (goto-char (point-max))
        (eval-print-last-sexp)))
    (load bootstrap-file nil 'nomessage))

  (straight-use-package 'use-package)
  (setq straight-use-package-by-default t)

  ;; Config for ERC recipe
  (use-package erc
    :defer t
    :config
    (setopt erc-modules
            (seq-union '(nicks scrolltobottom spelling) erc-modules))
    :custom
    (erc-insert-timestamp-function #'erc-insert-timestamp-left))

3. $ HOME=/tmp/bug73443 emacs
4. M-x restart-emacs RET
5. M-x erc-tls RET ... RET

FWIW, using the above setup, I don't notice the behavior described nor
any difference in the mode line with `erc-insert-timestamp-function' set
to 'erc-insert-timestamp-right' or its default. If you're able to
confirm this, then perhaps we can assume there's indeed been some kind
of "contamination," at which point it may be worth adding `use-package'
declarations for some of the other built-in modes and packages present
when the bug occurred. If you're able to narrow it down to an
unfavorable combination, perhaps we can teach ERC to integrate better
with those culprits.

Cheers.