Package: emacs;
Reported by: tmarjeski <at> gmail.com
Date: Mon, 23 Sep 2024 20:06:01 UTC
Severity: normal
Found in version 29.4
Done: "J.P." <jp <at> neverwas.me>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: "J.P." <jp <at> neverwas.me> To: tmarjeski <at> gmail.com Cc: emacs-erc <at> gnu.org, 73443 <at> debbugs.gnu.org Subject: bug#73443: 29.4; ERC 5.6.1-git: erc-track mode line face color broken with left timestamps Date: Mon, 23 Sep 2024 18:22:22 -0700
Hi, tmarjeski <at> 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.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.