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#75014: [PATCH] 30.0.92; ERC 5.6.0.30.1: Add interactive function to clear ERC channels' modified status Date: Sun, 22 Dec 2024 12:23:53 -0800 Message-ID: <87jzbr4gbq.fsf__10249.9357237079$1734899121$gmane$org@neverwas.me> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31284"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 75014@debbugs.gnu.org, emacs-erc@gnu.org To: Alex Bochannek Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 22 21:25:13 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 1tPSVk-0007zK-MR for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 22 Dec 2024 21:25:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPSVc-00055W-Gp; Sun, 22 Dec 2024 15:25:04 -0500 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 1tPSVa-000546-J2 for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2024 15:25:02 -0500 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 1tPSVa-0006Xu-8o for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2024 15:25:02 -0500 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=/fE4BAOfhyrnIFdHDhOPkX5Yj6U4ofzbb41/jC2zvCE=; b=L3Tg9dYq2ejjxUncokkZXKKl8z6vqfNs3MUPpajQzCjcf7ErXEdkyBL6UmzQ5UcdwWH/iVqj7nyCjY4QAzJKXszry/XJNpant/DsBGqVaO9kiaicsFKIMSrIrU2IeIcRNcrimW5U/A5q5Zc8kkfdJfohVqP9GHexTTmIuF7s+gqEhQdaLorcoCaITDbUNI5rm+3HxRfYWy9m6eIxIi0e2rOmVYvmqdfMpgLMBkVvw+Mipe7aAqfJ7/lGOA0dQpzMXR8anKziJsmnBdmqGaj+l6fWR8jxsLNGpDIj82TB/s1u+f77F444HExf+zsx9h3lrkAWgbaLUNkVZLU+rv/gWw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tPSVa-0007sl-36 for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2024 15:25:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Dec 2024 20:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75014 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 75014-submit@debbugs.gnu.org id=B75014.173489904330208 (code B ref 75014); Sun, 22 Dec 2024 20:25:02 +0000 Original-Received: (at 75014) by debbugs.gnu.org; 22 Dec 2024 20:24:03 +0000 Original-Received: from localhost ([127.0.0.1]:52086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPSUc-0007qu-8u for submit@debbugs.gnu.org; Sun, 22 Dec 2024 15:24:02 -0500 Original-Received: from mail-108-mta244.mxroute.com ([136.175.108.244]:38853) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPSUZ-0007qb-Cp for 75014@debbugs.gnu.org; Sun, 22 Dec 2024 15:24:00 -0500 Original-Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta244.mxroute.com (ZoneMTA) with ESMTPSA id 193f00a7528000310e.002 for <75014@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sun, 22 Dec 2024 20:23:57 +0000 X-Zone-Loop: f8b8e6cf4d4358fd94bda84082450bdb13f5fd631c09 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=/fE4BAOfhyrnIFdHDhOPkX5Yj6U4ofzbb41/jC2zvCE=; b=Ln9eoTU0i6OgT6n6q+ude5quwG 8gE8qBGgOjYK5yRl7eps0s0xgWiCpIHKmior5F60JqbSYsVY/nv0pnT2jGGaIkrcITYletIyn6mYm FtYhlBp9byKSY87dnzAUWrh8UHNibQ8WH5DYnkui1vwNbFdkFDXf+CLZ12no188/UnE/1lfgJsIgQ a3HjA8OSqjCQIV8IdXnESQ1/YgUItVh/gFI/kLNdvmhacxMZBIz/hYDHYvHE4FwHwvAzj+YKpDblB rZsulDd0M/KswdfgakxK66C2+Ek/E9p5SEtG5OCy69mD1psms4xAvOOmjLbm878SuQMBrfRx543ou Qf2yaetw==; In-Reply-To: (Alex Bochannek's message of "Sat, 21 Dec 2024 12:10:02 -0800") 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:297626 Archived-At: Hi Alex, Alex Bochannek writes: > This small function is intended as an easy way to mark all channels as > "read." This is useful when returning to an ERC session with multiple > modified channels that are not displayed in a window. Their status is > indicated in the mode line and in the ERC status sidebar, both of which > this function clears. Thanks for the patch. It seems quite useful. Administrative note: this change should probably go in ERC 5.7 instead of the upcoming 5.6.1 because, AFAIK, new features in point releases should only address unfinished (and ideally pressing) business from the current release or at least have some tenuous connection to a feature introduced there. That said, this command is pretty basic, so maybe we can squeeze it in without anyone complaining (although we should probably still mention it in etc/ERC-NEWS). > > If this is a common enough task, it makes sense to bind this function to > a key sequence, e.g.: > > (keymap-global-set "C-c e c" 'erc-modified-channels-clear) FTR, I'd rather ERC avoid modifying the global keymap (not to say that's what you were suggesting here). However, if people really need a predefined binding, I suppose we could maybe add something like this to `erc-track-minor-mode-map'. As for the keys themselves, I've been told there's a tacit convention these days to avoid "C-c {alnum}" because such keys are quasi reserved for a user's own config and that we should instead favor "C-c {modifier-sequence}-{alnum}" or a binding outside the "C-c" prefix space. (Not sure how widely followed this practice is, though.) A safer, perhaps more cowardly approach might be to just recommend a binding in the command's doc string. > Note: I am not familiar with the ERC code base, so if calling the > function something else makes more sense (I originally called it > `erc-reset-modified-channels') I have no objection to it. As it happens, ERC hails from a time before prefixing a library's symbols with its provided feature and/or group prefix was widely adopted. For better or worse, we tend to abide by this convention nowadays in new code, even though it may hamper discoverability at times. IOW, we should probably ensure the name begins with "erc-track-". Beyond that, I think it makes sense for related symbols within a library to share a common prefix. But since doing so often affects readability by contravening natural spoken syntax, e.g., "modified-channels-clear" vs. "clear-modified-channels," I tend to reserve such rigid alignment for "internal" symbols (those with two hyphens). I mention this because abandoning the association with `erc-modified-channels-alist' means there's no need to retain "channels" in the name, which may be more faithful to reality, since the command affects mode-line indicators for query and server buffers as well. As for "reset" vs. "clear," I have no real preference, but "clear" maybe sounds more definitive because "reset" might make someone wonder "reset to what"? (Or not.) > From 65cbc68d2fcdff8654df53d8d9a0f4c7aeb12529 Mon Sep 17 00:00:00 2001 > From: Alex Bochannek > Date: Sat, 21 Dec 2024 11:39:08 -0800 > Subject: [PATCH] Add interactive function to clear ERC channels' modified status > status > > --- > lisp/erc/erc-track.el | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/lisp/erc/erc-track.el b/lisp/erc/erc-track.el > index 97fb7e726bd..8d6f804a42b 100644 > --- a/lisp/erc/erc-track.el > +++ b/lisp/erc/erc-track.el > @@ -900,6 +900,13 @@ erc-modified-channels-remove-buffer > (when (called-interactively-p 'interactive) > (erc-modified-channels-display))) > > +(defun erc-modified-channels-clear () > + "Remove all buffers from `erc-modified-channels-alist'." Should we also mention that this clears the mode line segment, or maybe that's already obvious enough? > + (interactive) > + (setq erc-modified-channels-alist nil) > + (when (called-interactively-p 'interactive) > + (erc-modified-channels-display))) > + Perhaps we should just remove the conditional `when' construct and run `erc-modified-channels-display' unguarded, the assumption being that users doing this in Lisp code can set `erc-modified-channels-alist' to nil as needed. Otherwise, if keeping the `when', should we heed the scary admonition in the doc string for `called-interactively-p' and accommodate keyboard macros as well, or is there a reason to exclude them? > (defun erc-track-find-face (faces) > "Return the face to use in the mode line." > (declare (obsolete erc-track-select-mode-line-face "28.1")) > -- > 2.39.5 (Apple Git-154) Thanks, J.P.