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#68395: 30.0.50; ERC 5.6-git: erc-cmd-GMSG, erc-cmd-AMSG, erc-cmd-GME, erc-cmd-AME Date: Thu, 18 Jan 2024 18:53:21 -0800 Message-ID: <87v87qowym.fsf__37560.7476614945$1705632871$gmane$org@neverwas.me> References: <87h6jjw58t.fsf@dataswamp.org> <871qanp12g.fsf__35629.0631972783$1705037744$gmane$org@neverwas.me> <877ckfw11x.fsf@dataswamp.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29611"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Emanuel Berg , emacs-erc@gnu.org To: 68395@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 19 03:54:23 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 1rQf1S-0007S0-Tx for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 19 Jan 2024 03:54:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rQf19-0006RK-6p; Thu, 18 Jan 2024 21:54:03 -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 1rQf16-0006Qu-Tc for bug-gnu-emacs@gnu.org; Thu, 18 Jan 2024 21:54:00 -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 1rQf16-0005wS-LO for bug-gnu-emacs@gnu.org; Thu, 18 Jan 2024 21:54:00 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rQf18-0007mc-3i for bug-gnu-emacs@gnu.org; Thu, 18 Jan 2024 21:54: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: Fri, 19 Jan 2024 02:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68395 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 68395-submit@debbugs.gnu.org id=B68395.170563281329875 (code B ref 68395); Fri, 19 Jan 2024 02:54:02 +0000 Original-Received: (at 68395) by debbugs.gnu.org; 19 Jan 2024 02:53:33 +0000 Original-Received: from localhost ([127.0.0.1]:57098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQf0e-0007ln-RS for submit@debbugs.gnu.org; Thu, 18 Jan 2024 21:53:33 -0500 Original-Received: from mail-108-mta64.mxroute.com ([136.175.108.64]:34843) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQf0Z-0007la-Ca for 68395@debbugs.gnu.org; Thu, 18 Jan 2024 21:53:31 -0500 Original-Received: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta64.mxroute.com (ZoneMTA) with ESMTPSA id 18d1fa32e360003727.002 for <68395@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 19 Jan 2024 02:53:24 +0000 X-Zone-Loop: 0b3f9d64b2ec25f60343886a97e7a59609c81460b1af X-Originating-IP: [136.175.111.2] 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=w5SKjPDjVPuT3CTRAKUZLm2AHOH1/IwDL+cz2whlf1g=; b=RFAYcMRGRjf8m8u9W7H7ZnydIf chX2wXSLLAtNQyONnVHmJ9wrG5XAi2cXa/bDh08K4p7+aNqV7wZupPoEL6KlN/tfDi2p7FHwaNGZt 53+UnBKRD23v4iB2S05J6lXfCKrRreGK3IgBG93TeYNSF9q4+J6+tXUj/HLeszSk/KYeA9C0mewsf W/o9gtVH6Ze0Dfw1RatEYWUiNZGTbrGQf8SvnB9DToPLr6fdj57MAWWVathfEPWp82jbRq/5geadi 0HgkZj71Od1OhrN8CIvvAUwVyUOmKnLMueNyV+75qqiH43ILR4/xS4PsrYXZQwObdbzBC2VtsQ7Rj JDeC4klA==; In-Reply-To: <877ckfw11x.fsf@dataswamp.org> (Emanuel Berg's message of "Fri, 12 Jan 2024 06:52:42 +0100") 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:278468 Archived-At: Emanuel Berg writes: > J.P. wrote: > >>> Patch >> >> I think debbugs wants the full "Tags: patch". > > It is there, what you cite is just what I wrote in the message > instead of a bug report. AFAICT, instead of a "pseudo header" [1], your bug report included a "real header", which Debbugs appears to have ignored. Before control message (sent by me): Id State Submitter Title 68395 normal Emanuel Berg 30.0.50; ERC 5.6-git ... After: Id State Submitter Title 68395 normal,patch Emanuel Berg 30.0.50; ERC 5.6-git ... I believe you can also trigger detection by prefixing the subject of the email (not the patch itself) with "[PATCH] ". [1] https://debbugs.gnu.org/Reporting.html#pseudoheader >> At some point, you'll need to include a commit message. > > I added a message, if not 'git commit' wouldn't have worked. Git calls the first line of a commit message the "subject," but there's also the "body," which is often needed to comply with a project's guidelines. AFAIK, the githooks(5) provided by Emacs only validate the existence of "* listed/files", but they don't yet check for a nonempty body. Nor do they enforce the ChangeLog-style format demanded by the project. As mentioned in CONTRIBUTE, "scaffolding" tools exist to prepopulate a COMMIT_EDITMSG buffer. And these days folks surely use AI tools for this purpose as well. >>> --- >>> lisp/erc/erc.el | 156 ++++++++++++++++++++++++++++-------------------- >>> 1 file changed, 90 insertions(+), 66 deletions(-) >>> >>> diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el >>> index 478683a77f5..12078f6970d 100644 >>> --- a/lisp/erc/erc.el >>> +++ b/lisp/erc/erc.el >>> @@ -2003,10 +2003,10 @@ erc-get-buffer >>> (defun erc--buffer-p (buf predicate proc) >>> (with-current-buffer buf >>> (and (derived-mode-p 'erc-mode) >>> - (or (not proc) >>> - (eq proc erc-server-process)) >>> - (funcall predicate) >>> - buf))) >>> + (or (not proc) >>> + (eq proc erc-server-process)) >>> + (funcall predicate) >>> + buf))) >> >> I haven't looked at the proposed commands yet, but can you >> remove all these hopefully inadvertent white space changes >> in the meantime, please? > > Ah, you are using tabs in the source, Not sure who "you" refers to here, but the tabs you see all reside in areas that predate modern standards regarding white space. Since ERC is legacy software, "preserving the blame" usually takes precedence over conveniences, like automated indentation, because research expeditions are the norm [2], and useful insights provided by mailing list discussions, change logs, and surviving code comments are sparse. For these same reasons, "new work," which uses spaces exclusively for indentation, should also avoid reflowing surrounding code solely for readability unless the resulting distraction is extreme, in which case reformatting can be performed after code review is complete. And while it's true that Git is smart enough to ignore white space when presenting diffs of blobs it knows about, that doesn't really help for previewing attachments in message-mode buffers. [2] https://en.wikipedia.org/wiki/Software_archaeology > saving the buffer changed them to whitespace. Perhaps you ought to disable that feature when editing files in the Emacs tree. Using a .dir-locals-2.el may help. > J.P. wrote: > >> Both vc and Magit should have tools for helping with this. Assuming >> "[PATCH] `erc-cmd-GMSG' ..." sits on HEAD, you'd do something like this >> in manual Git: >> >> 1. $ git reset --patch @^ >> 2. Mark all offending hunks as "y" in the interactive menu >> 3. $ git restore '*' >> 4. $ git commit --amend >> 5. Provide a commit message that accords with CONTRIBUTE >> >> Or, alternatively: >> >> 1. $ git revert @ >> 2. Reinstate only the intended changes, which I think I've found below >> 3. $ git add -A >> 4. $ git commit --amend >> 5. Replace generated message > > Maybe better to redo the whole thing? > > Since the patches produced after these steps (both methods) > also include data on the whitespace. FWIW, both methods worked for me in a contrived setting. Should you someday need to try the second one again, maybe use emacs -Q or git-add(1) with the "--patch" flag to select only the hunks you intend to share.