From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs 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 Message-ID: <87tte5zvzl.fsf__39036.8956302822$1727140996$gmane$org@neverwas.me> References: <87h6a63zmj.fsf@trevarch.mail-host-address-is-not-set> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29383"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-erc@gnu.org, 73443@debbugs.gnu.org To: tmarjeski@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 24 03:23:08 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ssuGh-0007V3-F3 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 Sep 2024 03:23:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ssuGH-0004wm-TB; Mon, 23 Sep 2024 21:22:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ssuGF-0004wX-Od for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2024 21:22:39 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ssuGF-0001Iw-BZ for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2024 21:22:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=IaIWdrYXE1W1qwbymolY6PFRzg9DLleRQLJHWpyryF8=; b=iG+sIqPZ0GGWKaoJLmvOp/7tSpkzMbQ09i9CZo/3ML76yc2nC2SKp251xdPgSBDRWbgUh+2Vg7r25ZLSNZBd9Xn6tuv/+psrQWyHxA9IEujTJzZrCxcxLqfySxELKvEQZwD6IUHl3VS90ryhbvLtwMPX9eXK6f1YtIJjgemwZcqZyfVkYIauQZ0GhGsEgXHBOTH0SUdiEDwlcTCErs9WCwxDu28jzqaeBKToP90tVPUQVT08NaVhztGAjI/Gw+Wa6rufQC9cZMb7qpGSzW2wBPyCFBtVCJe+7pzlFXXOn4VpFaUCEpuh8vrP8AQIjG9N+8BMUeKVgkk5QoX6BBFutw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ssuGc-0003PN-I5 for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2024 21:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Sep 2024 01:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73443 X-GNU-PR-Package: emacs Original-Received: via spool by 73443-submit@debbugs.gnu.org id=B73443.172714097513086 (code B ref 73443); Tue, 24 Sep 2024 01:23:02 +0000 Original-Received: (at 73443) by debbugs.gnu.org; 24 Sep 2024 01:22:55 +0000 Original-Received: from localhost ([127.0.0.1]:44958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssuGV-0003P0-0J for submit@debbugs.gnu.org; Mon, 23 Sep 2024 21:22:55 -0400 Original-Received: from mail-108-mta180.mxroute.com ([136.175.108.180]:46777) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssuGR-0003Op-Mw for 73443@debbugs.gnu.org; Mon, 23 Sep 2024 21:22:53 -0400 Original-Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta180.mxroute.com (ZoneMTA) with ESMTPSA id 192219f5ea50003e01.001 for <73443@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 24 Sep 2024 01:22:25 +0000 X-Zone-Loop: dc8549bfe345d5b090cbe2c8712138fc40fe7e813ca3 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=IaIWdrYXE1W1qwbymolY6PFRzg9DLleRQLJHWpyryF8=; b=AUfMwYgrvCrcrtSAUVzk7pXxos ulCDvG3fUInZGvEspqHFjFg+uCCyHBoR3oCwMizYh9PcQOKpZkgDDvhLHax3/16DLMcpC7XcX7KLR xDKeHX9c2HfNtYFoHbxC/6X4IiKRPvMLV6DCGaDj/bHmdIwiMu0BJMrogapfN3nZwxE6zPrpBmgtb /+5K0+l4Xqr7vWADcy4nMjO5dgK+cgoq89Chk4PGi0Djc2X+Q4T7pV1pohi9PEpXWGaemULTHLCas Vg7Y0UUbhiIHhyaIPLCoIVPQtZsfeRiTKORd3AzwWe12s/Kz3LMQxfnyb1NCUMWJlFFnCFuX75yKO OmqWLkYQ==; In-Reply-To: <87h6a63zmj.fsf@trevarch.mail-host-address-is-not-set> (tmarjeski@gmail.com's message of "Mon, 23 Sep 2024 23:04:52 +0300") X-Authenticated-Id: masked@neverwas.me X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:292300 Archived-At: 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.