bug#33225: [debbugs.el] Don't send control message immediately

[Noam Postavsky]

Michael Albinus <michael.albinus@gmx.de> writes:
>
>> Regarding making a release, I have in mind next to bring in my commands
>> which produce control messages from git commits (both for attaching
>> proposed patches from an unpushed commit, and closing from a pushed
>> one).  Perhaps you want to wait for that before making a new release?
>> (or perhaps just the opposite, not sure what your release policy is)
>
> My release policy is very simple: gut feeling. I have no pending issue
> to solve, so we could wait for the release.
>
> I'd prefer if you would commit your changes so far, that we have a
> common base, and further patches you'll show are shorter (to review).

Yes, I would open a new bug thread for the feature I mention above,
after this is one is closed and pushed.

>> +        ((member message '("unarchive" "unmerge" "noowner"
>> +                           "notfixed" "notforwarded"))
>> +         (format "%s %d\n" message bugid))
>
> You have (correctly) said, that "notfixed" isn't documented on
> debbugs.gnu.org. So I have checked
> <https://www.debian.org/Bugs/server-control#notfixed>. "notfixed"
> requires also a version number [...]

Huh, indeed.  Not sure how I messed that up.  I even have it correct in
my .emacs.d/, so it seems something went wrong while moving it to
debbugs-gnu.el.

>> +@item
>> +@kindex @kbd{C}
>> +@kbd{C} @tab
>> +@code{debbugs-gnu-make-control-message} @*
>
>
> This shall be {E}

Right.

>> +@item found
>> +@itemx notfound
>> +@itemx fixed
>> +"found|notfound|fixed 12345 25.1"
>
> Please add notfixed.

Done.  Hmm, I just noticed that we have "@itemx fixed" in two places.
So there is a conflict between "fixed" as a tag, and "fixed" as its own
command.  I think the command should precedence (that was already the
case in the code for previous patches, now I've updated the doc as
well).

One last thing I noticed when byte-compiling from emacs -Q, is that I
needed to add a couple of autoloads for the message functions.  And then
I realized that the message-narrow-to-head call should actually be
message-narrow-to-headers, since the latter looks for
mail-header-separator, while the former just looks for a blank line (in
practice, it doesn't make much difference unless the message body
happens to have text that looks like a mail header).

v4-0001-New-command-debbugs-control-make-message-Bug-3322.patch
Description: patch