Re: A few questions about debbugs

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

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

Hi Björn,

>> I've assembled a proof-of-concept for debbugs-gnu-search, see appended
>> patch. It is on top of the ELPA git repository, but it might apply also
>> on the last distributed debbugs release (didn't check). Feedback appreciated.
>
> Could you next time create a branch with the patch in debbugs git so
> it's easier to test the patch if already using debbugs from git?

Debbugs lives in the elpa git, as branch. Adding another branch to a
branch seems to be overkill to me.

I've pushed everything to the elps repo (this is much more but the last
patch I've sent, covering almost all debbugs-gnu-* and debbugs-org-*
commands). You can install this WIP as special development elpa
package. Add the following:

--8<---------------cut here---------------start------------->8---
(add-to-list 'package-archives
             '("devel" . "https://elpa.gnu.org/devel/"))
--8<---------------cut here---------------end--------------->8---

After refreshing your package list, you wil see package debbugs
0.40.0.20240812.95045. Install it, and play with it :-)

> To bad Debbugs-gnus-apply-patch only works for Emacs :D
> Applying a patch with Gnus was harder than it should be, I have to
> somehow integrate diff-mode and then magit-apply-patch better in Gnus.
> But that's OT anyway.

You don't need all of this. Emacs has built-in patch support, for
example via Menu Bar -> Tools -> Apply Patch -> To a File

>>    ;; Do the search.
>> -  (debbugs-gnu severities packages archivedp)
>> -  (message "Search finished"))
>> +  (make-thread
>> +   (lambda ()
>> +     (debbugs-gnu severities packages archivedp)
>> +     (message
>> +      (substitute-command-keys
>> +       "Search finished, visit buffer via \\[debbugs-gnu-show-last-result]")))))
>
> I think it would also be an option to have a flag to open the search
> results by default after they are found. For searches that should not
> take long this is the expected behavior especially for new users.

But then we have the problem of interrupting the user, again. A user
doesn't know in advance, how long a search will run.

>> +;;;###autoload
>> +(defun debbugs-gnu-show-last-result ()
>> +  "Switch to buffer with the recent retrieved bugs"
>> +  (interactive)
>> +  (when (ignore-errors (get-buffer debbugs-gnu-current-buffer))
>> +    (pop-to-buffer-same-window debbugs-gnu-current-buffer)))
>
> What's the reason for pop-to-buffer-same-window, shouldn't the user be
> able to choose where the search results are opened? Personally I would
> use display-buffer and than customize if the buffer should be opened in
> the same buffer.

Well, this was discussed in bug#36917. Since I'm not familiar with the
display-buffer machinery, I've simply followed the recommendation. They
say that one could use display-buffer-alist for configuration then.

I've also updated the debbugs-ug manual. There is a new section, saying

--8<---------------cut here---------------start------------->8---
1.1 Asynchronous Work
=====================

The access to the GNU Debbugs server happens via a SOAP interface.
This can be slow, especially, when a large number of bugs must be
retrieved, or an extensive search is applied.  If Emacs is compiled
with threading support, this work is performed by a thread.  During
the bug retrieval, it is still possible to continue the work with
Emacs then.

   After the bug retrieval is finished, a respective message will
appear in the minibuffer.

 -- Command: debbugs-gnu-show-last-result

     This command switches the current buffer to the recent buffer
     containing bug reports.  It is useful to bind this command to a
     function key in your ‘.emacs’ file, like

          (keymap-global-set "<f5>" 'debbugs-gnu-show-last-result)

 -- User Option: debbugs-gnu-use-threads

     The user option ‘debbugs-gnu-use-threads’, when set to ‘nil’,
     disables threaded bug retrieval, and synchronous bug retrieval is
     performed.  Threaded bug retrieval is also suppressed if the
     number of bugs to be retrieved is known in advance, and it is
     smaller than the user option ‘debbugs-gnu-use-threads-lower-limit’.
--8<---------------cut here---------------end--------------->8---

Feedback welcome!

Best regards, Michael.