[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Noam Postavsky
Subject: bug#33225: [debbugs.el] Don't send control message immediately
Date: Mon, 01 Apr 2019 09:34:17 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.91 (gnu/linux)

Michael Albinus <address@hidden> 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

>> address@hidden
>> address@hidden @kbd{C}
>> address@hidden @tab
>> address@hidden @*
> This shall be {E}


>> address@hidden found
>> address@hidden notfound
>> address@hidden 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

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).

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]