Re: bug#68395: 30.0.50; ERC 5.6-git: erc-cmd-GMSG, erc-cmd-AMSG, erc-cmd-GME, erc-cmd-AME

[J.P.]

Emanuel Berg <incal@dataswamp.org> 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.