Re: A few questions about debbugs

[Michael Albinus <michael.albinus@gmx.de>]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

Hi Björn,

>> Replacing soap-invoke by soap-invoke-async is not a problem. What I
>> worry about is the UI. If you invoke debbugs-search, and you do
>> something else in Emacs then, you need a proper way how to present the
>> search results to the user w/o interrupting the work she is doing
>> meanwhile.
>
> How would you not interrupt the word the user is doing? Shouldn't that
> be the point? An option would be to use dispaly buffer with an option to
> not change the cursor focus and spawn the window where the command was
> called if possible.

See the other message from Stefan Monnier.

>> That's not done via the SOAP interface. The debbugs.gnu.org server
>> offers a well known URL how to download the messages related to a bug in
>> mbox format. See the function debbugs-get-mbox in debbugs.el. And this
>> mbox is given to Gnus then, for showing an ephemeral message group.
>
> Is this specific to GNU debbugs server or does it work too if I would
> like to do the same with e.g. the Debian server?

Sure, you can do it with the Debian BTS as well. Given there is the bug
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=123456>, you can
download the respective mbox via <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=123456;mbox=yes>.

> The way you implemented this feature could also be a way to handle
> mainlinglist archives in Gnus better if some such as those using
> mailmain would provide a well known address.
> For others there's at least public-inbox which works after each
> mailing-list has enabled it. But that's OT.

I believe there are packages which use it. Gnus has implemented the
handling of such mbox files under the name "ephemeral group". Check the
Gnus manual for this.

RMAIL offers a similar technique, used in debbugs-gnu.el as well, but
I'm not familiar with the details.

>> Later on, there was the request to have a UI for that package, which is
>> specialized on the debbugs.gnu.org server. This was implemented in
>> debbugs-gnu.el, and this is the reasoun of the string "gnu" in this
>> library. "debbugs-gnu" is just the prefix for all functions and
>> variables there.
>
> OK thanks for explaining. I think for clarification all the Emacs
> specific functions should have a debbugs-gnu-emacs- prefix or something
> a like to indicate their intention.

I don't know what you mean with "Emacs specific functions". If you mean
"functions to be called from Emacs" - all of them are such functions.

If you mean "functions specific for the Emacs project on
debbugs.gnu.org" - these are the functions which handle the git repo. I
don't know whether they could be used for other projects / git
repositories as well; but there haven't been a request so far.

Note, that the Guis project uses its own configuration, collected in
debbugs-guix.el. They use the "debbugs-gnu-guix" or "debbugs-org-guix"
prefixes, respectively.

>> I don't remember why the string "trunk" has been used, and this might
>> indeed predates the time git has been taken for Emacs development.
>
> Is the approach to have more than one source tree? Debbugs mentions
> a trunk and stable tree for a git based workflow a stable and
> master/main branch handling would be more helpful.

Yes, there are functions to merge git commits between different
branches. Honestly, I don't know too much about. This part was written
by Lars Ingebringtsen; I don't use it myself.

Best regards, Michael.